[Anthill-dev] [Anthill] RE: Should "Versioned Build" try to increment the version?

[Robert Dobbins]

Chad, 

The  "versioned builds" do not need to update the versioned file and versioned builds does not do any tagging at this time.  

The reason it was left in tact was to provide the  least amount of change to the existing codebase as possible to accomplish the goal (versioned builds).  Since the real problem is the update (checkin) of the versioned file it would seem to be a better approach to simply bypass that one portion of the process.  I haven't tried your patch as yet but it appears from what you sent that the projectProperties.PROJECT_VERSION nor the project registry would be updated.  If this is the case, there is the potential that the wrong version could be reported on the main page if you were building anything other than the last version.  There may be a cleaner approach to this by simply bypassing the Version Adapter's setCurrentVersion method call.

==================================================================================================
Hi,

I just made a patch which will prevent a "Versioned Build" from performing any version incrementing or tagging. It works for me, all existing build logs and artifacts are overwritten without problem. It is a simple change to BuildManager - if there is a preferred way to submit this patch, please let me know. 

P.S. This section of the code is getting kind of "smelly" with nested conditionals 4 levels deep, but I figured I'd leave the refactoring risk to someone else :)

======= BuildManager.java, based off revision 1.27 ===============starting at line 109:log.info("step 2) is project up to date?");if (def.versionedBuildFlag) {// if we are making a versioned build, don't increment theversion file// or perform any taggingif (def.getForceBuildFlag() || requiresBuild(def, radapter)){log.info("Step 3) Build Project - Versioned Build: ");runBuild(def);if (properties.isPublishRunPolicyAlways() ||!def.getErrorFlag()) {log.info("Step 4) Publish Project: ");publish(def);}}} else {....... 83 lines .......}}catch (Throwable e) {....====================================

Thanks,

Chad



-----Original Message-----

From: Chad Woolley [mailto:chad_woolley at choicehotels.com]

Sent: Monday, July 28, 2003 2:42 PM

To: Anthill Mailing List

Subject: Should "Versioned Build" try to increment the version?



Hi,

I am running the latest from the HEAD, and I am having some problems with

the new "Versioned Build" functionality with CVS.



Here's my scenario:

1. I have made a release branch for a build (build # 39) that is going to QA

2. There were some fixes made on this branch

3. I manually edited the "version.txt" file to contain "masterbuild.39-1"

4. I then tagged all the files on the branch as "qa_39-1"

5. I went to anthill, selected "Versioned Build", and entered "qa_39-1" as

the "Label to Build"



Anthill then gave the following error in the log:

12:26:28:360 [Thread - AnthillBuildDaemon] INFO

com.urbancode.anthill.adapter.ProfileRepositoryAdapter - Post file edi

t on file: masterbuild\version.txt

12:26:28:370 [Thread - AnthillBuildDaemon] INFO

com.urbancode.anthill.util.Execute - [unlock] cmd /x/c cd /d d:\anthil

l\choicehotels\work\MASTERBUILD && cvs -d

:pserver:anthill at 143.192.18.41:/usr/local/cvsroot commit -m

Committed_by_Anthi

ll masterbuild\version.txt

12:26:28:741 [Thread - AnthillBuildDaemon] ERROR

com.urbancode.anthill.BuildManager - ProfileAdapter unlock failed: cvs

server: sticky tag `qa_39-1' for file `masterbuild/version.txt' is not a

branch

cvs [server aborted]: correct above errors first!





My question is: Should a "Versioned Build" be attempting to increment the

version? I seems to me like it should not. If I am specifying a certain

tag to build, then I would think anthill should just build that tag for me,

and not attempt to increment any the version.file in

UrbanCodeVersionAdapter. At least in my scenario, it does not make sense.

I want to have complete control over the changes on the branch, and don't

want the version.file being modified. I realize this would involve

overwriting existing build logs and files if the build is run multiple tags,

but that would seem like the logical thing to do if you perform multiple

builds of the same tag.

In other words, if you are building based on a given tag, you are

"recreating" the app based on the point in time specified by the tag. I

would think this should be done regardless of which branch or revisions the

tag is on. It doesn't make sense to make a modification (of version.file)

to the tip of some branch or HEAD when you were just trying to recreate a

past version.

I'd propose that we disable the incrementing of version.file if a "Versioned

Build" is being performed. Does this present any difficult technical

issues, such as overwriting existing build logs/artifacts if the same tag is

built multiple times?

Thanks,

Chad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.urbancode.com/pipermail/anthill-dev/attachments/20030729/d5cb4597/attachment.htm