Issue with build numbers on automated builds

Not strictly a problem with Octopus, but something that caused us an issue.

We set up a build server to auto-build on check-in for our project. The version of the app is set as 1.2.3.* - so the last item is the build number. When we commit a change the build is triggered and then the package is sent to Octopus.

The problem is that the build numbers are not reliably sequential, as our build server has two agents, and they each have their own build number sequence. This was the result in Octous

   15.1.4.27821	01 October 2015 15:28	26.3 MB
   15.1.3.33600	30 September 2015 18:40	26.3 MB
   15.1.3.31227	30 September 2015 17:21	26.3 MB
   15.1.3.28748	30 September 2015 15:58	26.3 MB
   15.1.3.27234	01 October 2015 15:08	26.3 MB
   15.1.3.25904	01 October 2015 14:24	26.4 MB
   15.1.3.25311	01 October 2015 14:04	26.3 MB
   15.1.3.24552	30 September 2015 13:39	26.3 MB

As you can see, the build numbers didn’t run sequentially. We had to bump the app version to make it bypass this.

Hi,

Thanks for reaching out. Yeah I’m afraid this falls under the build-server realm. Back when I used TFS, I remember having to tweak my builds a bit so the last part of the build number was YYDDMMSS (or something like that) to make sure they were always incremental. Then I switched to TeamCity which has a built-in incremental feature and everything was easier.

You could let Octopus automatically increase the release number by not specifying one when you create it, but its not something recommendable. The best scenario is to have the NuGet package match the version of the build, and then create a new release that automatically takes the same version as the NuGet package (or as the Build in case you have packages with different versions).

Regards,

Dalmiro

Thanks for the reply - I’m checking on StackOverflow to see if we can find a solution for this. For now I’ve disabled one build agent so the numbers should be sequential.

Hi Howard,

It’s probably also worth reviewing how wildcards in AssemblyVersion work:

https://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute(v=vs.110).aspx

You can specify all the values or you can accept the default build number, revision number, or both by using an asterisk (). For example, [assembly:AssemblyVersion(“2.3.25.1”)] indicates 2 as the major version, 3 as the minor version, 25 as the build number, and 1 as the revision number. A version number such as [assembly:AssemblyVersion("1.2.")] specifies 1 as the major version, 2 as the minor version, and accepts the default build and revision numbers. A version number such as [assembly:AssemblyVersion(“1.2.15.*”)] specifies 1 as the major version, 2 as the minor version, 15 as the build number, and accepts the default revision number. The default build number increments daily. The default revision number is the number of seconds since midnight local time (without taking into account time zone adjustments for daylight saving time), divided by 2.

In short, you can never rely on “1.2.3." to increment, since it will reset each day. You’d need to use "1.2.” to have any hope that any two builds would be sequential. Hope this helps!

Paul

Thanks Paul - I’ve amended the versioning to the format 1.2.* format and it looks to be working even with parallel builds.