Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

How to change the build number

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?

1 answer

0 votes

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:

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.

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.ADO.pngJenkins.pngTC.png

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:

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.

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?

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?

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



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.

Like Daniel Santos likes this

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!

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events