<echo>##teamcity[buildNumber '${newreleasenumber}']</echo>

Hi,    We are formatting the buildnumber w.x.y.z  ( the Z part) to keep it at 3 digits long.   So a 1 in the teamcity counter will actually be .001

The NAnt script that does this formating for us returns the formatted build number to teamcity using the following.

        <echo>##teamcity[buildNumber '${newreleasenumber}']</echo>


Now we are using the new multiple build runners to

a.  format the build counter number
b.  perform the build and add in the full build number to the assemblyInfo
c. commit the resulting binaries to subversion in the form of   ProductName-1.00.00.001

We used to have this in version 4.5 as 3 seperate builds where step b had as its build counter format %dep.bt63.system.build.number% (63 being the build done in step A)

This worked and the formatted build number was fine for steps b and c when they were seperate builds.

Now that we have them as build steps in teamcity 6.0,  this doesnt work any longer.   I am trying to pass in the following on steps b and c

"-D:build.version=%system.build.number%"

but that doesnt seem to work.

Any ideas?

7 comments
Comment actions Permalink

Hi Lance

This bug is fixed in upcomming version 6.5 as TW-15499.

Thanks
Michael

0
Comment actions Permalink

Hi MIchael,  Thanks for the info.  Is there any chance that there is a patch for 6.0?  We just installed 6.0 and will have many builds before we were to install 6.5

Thanks.

0
Comment actions Permalink

Hello Lance,

Unfortunately the fix will not be available in 6.0. Please wait till next 6.5 EAP and upgrade.

Kind regards,
Marina

0
Comment actions Permalink

Hi,   Are they any alternatives?  I am not able to set my build numbers properly causing my db update automation to now work properly.

the reason for this is  without the proper build number formatting.. and in the build number sequence  .001, .002, .003, .004, .005, .006, .007, .008, .009, .010, .011, .012  we would typically update db schema from build .001 to .002 and then from .002 to .003 etc based on .002 being a higher number than .001, etc  also build .010 and .011 are higher than .009.

If we cant format the number then we have .1, .2, .3, .4, .5, .6, .7,.8,.9,.10, .11, .12

In this case .2 is higher than .1 but when we get to .10 it is not higer than .2 and the update sequence has a problem.

This is a big problem for us if we update dbs out of sequence.

0
Comment actions Permalink

Lance,

Until 6.5 there is no automatic way to tranfer changed build number from one step to another. A build level workaround would be to save the value in an external file in the first build step and then read it from there in the next step.
Plugin-level solution can provide property that uses the formatting that you need - see the comment.

As a side note the logic that thinks that 10 is less then 2 seems to use wrong comparator and it might require updating in the forst place.

0
Comment actions Permalink

Has this been fixed in 6.5.2?

0
Comment actions Permalink

Yes, it has been fixed in version 6.5

0

Please sign in to leave a comment.