How to change the build number

[Shawn Sesna]

I have been able to figure out how to change the build number in Azure DevOps, Jenkins, and TeamCity so that it's (ADO format for example) $(MajorVersion).$(MinorVersion).$(Year:yy)$(DayOfYear).$(Date:Hmmss).  How would I accomplish the same thing in Bamboo?

[Daniel Santos]

Hi @Shawn Sesna

I'll need your help to make sure we are on the same page.

When I read the title of your post, I think about the Bamboo number which describes each build. It is the number at the end of a build key: e.g. PROJ-PLAN-76 (build 76). Some times we need to reset this number to meed the project needs. We may need to reset it because we want to use it to define the App build number, as you shared above. 
In case you want to reset this number you can use the following document as a reference:

•  Unable to change the current build number in Bamboo - Atlassian Documentation

Ok, what I shared above is my perception from the title of your question, now I want to talk about the description.

Where do you want that sequence of variables to be available?

• Do you need them to name an artifact of your build?
• Do you need that to name your deployment?

I need to understand where do you need such a name/build description to see if I can help you to build it.

[Shawn Sesna]

Hey there Daniel, thanks for getting back to me!  Apologies for not being clear, I'll see if I can explain better :)

In other build platforms (Azure DevOps, TeamCity, and Jenkins) we can rename the build display to be a version number such as 1.1.351.4.  This version number can get stamped on artifacts such as NuGet packages which can then correspond to release numbers in Octopus Deploy so it's easy to trace a release all the way back to a build.  

I've included some screen shots from the other platforms to help illustrate what I'm trying to do.

[Daniel Santos]

Hi @Shawn Sesna

Thank you very much for the clear enlightening examples.
Bamboo has a similar configuration for release versioning. The build number for Bamboo is just a number from 0 to max(int). What defines a given build is the PROJ-PLAN(or plan branch) + scalar (build number).

A given build can be promoted to a release and releases can have special names defined by multiple variables as you described.

Please take look at this page for more details:

• Naming versions for deployment releases - Atlassian Documentation

If you want to name your build artifacts (not generated by a deployment) with a similar number/code/label, you will need to create a script task and manipulate the variables manually. 

I hope the release naming is what you are looking for.

[Shawn Sesna]

Thanks Daniel!  This might be what I'm looking for, but let me walk you through the process and get your thoughts.  In the other build platforms, I package the application into a NuGet artifact from within the build process itself.  The version number of artifact is the build number so from within Octopus Deploy, I can tie a Release version directly to the build that created it since they'd be the same number.  If I'm following what you're saying, it looks like I would need to create a Deployment in Bamboo and place the Package operations there in order to get a similar version number.  Is this correct?

[Daniel Santos]

You are welcome @Shawn Sesna!

If I'm following what you're saying, it looks like I would need to create a Deployment in Bamboo and place the Package operations there in order to get a similar version number.  Is this correct?

Yes, this is how I see you can get similar behavior. 
To create releases in Bamboo you need to create a deployment project. 
The deployment should be run whenever you have a candidate to be released. The simplified workflow would be:

• There is a candidate build to be released
• Create a release for that build
• Deploy it to your testing environment (QA)
• Deploy it to production

Not every build needs to have a release, but every release is a possible candidate for a given development cycle.

Does that make sense?

[Shawn Sesna]

I was able to come up with a workaround without having to use the Release feature.  I created two project variables 

Major

Minor

I then created a Script task and used PowerShell to write the desired version number to a file

$day = ([datetime] $(Get-Date)).DayOfYear
Add-Content -Path "version.txt" -Value "buildVersion=${bamboo.Major}.${bamboo.Minor}.$(Get-Date -Format "yy")$day.$(Get-Date -format "Hmmss")"

I then used that Inject Variables task to make the variable available to the build.  This allowed me to stamp the NuGet package version with the version number I wanted.

To tie the Octopus Release back to the build that created it, I set the Label to the injected variable.

[Daniel Santos]

This is awesome, I'm glad that you found a way to produce the build number exactly as you wanted it to be.

Thank you very much for sharing your approach. It might help others looking for a similar build format.

Thank you!