A lot of functionality in Bamboo relies on it's sequential Build numbers. Implementing this change would require a major development effort for an arguably small improvement. Additionally, with DVCS becoming more popular, revision numbers will become less relevant as a reference.

As a workaround we could make the revision number more prominent in the Bamboo interface. However, if you would like to go one step further, it wouldn't be too hard to write a plugin using Web Resources[1] and the Build Result Service[2] to substitute the build number with the revision number using JavaScript.

Since we are unlikely to implement this feature, I will close this ticket. Please let me know if you have any questions, comments or concerns.

Cheers,
Jens

[1] http://confluence.atlassian.com/display/BAMBOO/Web+Resources
[2] http://confluence.atlassian.com/display/BAMBOO/Build+Results+Services

This would definitely be useful for us too, is it on the planning board?

Any plans to look at this in an upcoming release?

Edwin,

Are you only going to look at the source code revision number with this JIRA? Dante's original description mentions the revision number and the application version number. As I'm interested in the application version number (proposing to use labels), I'm wondering if I should create a new feature request.

Hi guys,

Thanks for all the suggestions and comments.

Firstly to clarify, the revision number is available already on the Bamboo UI when you are viewing a build result.

Looking at this issue, as Mark has mentioned, we don't believe it is feasible to use the revision number as the underlying build number/key. What we do think will make much more sense is to make that much more prominent on the UI, rather than just visible in the build results screen.

Currently, I think there are a few areas that the revision number can show up in:

• Dashboard (All plans tab)
• Build history
• Plan summary charts - tooltips

Will that work?

Cheers,
Edwin

Cheers,
Edwin

How about extending the use of labels?

• First, can some of the restrictions on characters that can be used in labels be lifted? I'd like to use (.) in my labels, so my label matches my application version. For example, my build version might be 8.0.2.1, but I currently have to label it as 8_0_2_1.

• Next, either allow me some flexibility on how the plan dashboard results are displayed or allow the display of labels. For example, I currently have build results that look like this:

These builds all refer to the same label, 8_0_2_1, but from the current dashboard it's not easy to see this. If you had a table similar to how CruiseControl shows build results, it would help quite a bit, say like this:

You could either force the layout of the plan results (to make this easier to implement) or introduce a concept similar to JIRA's Issue Navigator where you can customize the columns that are displayed for plan results.

• Finally, modify mouse over logic in charts to include the label.

Currently mouse over a build in a chart shows something like this:
Build: 219 - Successful - 41 minutes

If you could modify like this, it would really help:
Build: 219 (8.0.2.1) - Successful - 41 minutes

Our custom build process creates a new perforce changelist and uses that as the build number. Guaranteed to be unique, ordered, and says that all code changes with revision < the build number is included. Seems like same solution could be applied to Bamboo to optionally provide more meaningful build numbers.

I would love if there was just a comment, that way I dont really care if bamboo wants to keep track of it's own numbers – since I will just ignore them and look at the subversion/perforce changelist number.

So on the All Plans page, there would be something like:
XXX Continuous > XXX-CI-34 (P4 229593)

And same thing in each place there is a reference to XXX-CI-34 in the interface.

IMHO this is good enough, and does not require Atlassian to do a lot of changes in the "logic" of the builds, just with the GUI.

The way I'd love to see this implemented is by having an option, say in the Builder tab, for Build Number Scheme. The default scheme would be the current integer-based scheme. However, Atlassian could provide additional schemes, say for Perforce and Subversion builds. These schemes would have well-defined, documented rules for how the next build number is assigned.

In addition, it would be great if a custom numbering scheme could be defined. The custom numbering scheme would define a starting build number and a rule for how to increment the number for a manual build. Perhaps this could be implemented by allowing users to implement an Atlassian-defined Java class and creating their own methods for nextBuild() and previousBuild(). Ideally, this class would allow access to the metadata for the previous build because the next build number may be dependent on values used in the prior build. If the user selected a custom scheme, they'd provide the name of a jar file that they previously copied to the WEB-INF/lib directory.

Any alphanumeric value (including symbols) for build number should be allowed.

This would provide the flexibility necessary to support any numbering scheme. Atlassian could add to the list of supported schemes over time, while still allowing users to create their own schemes.

In addition, and this should probably be defined in a separate JIRA, it would be nice to have a separate Build Action, in addition to Run Build, named Run Build With Parameters. If selecting this option, the user would have the ability to specify a specific the build number, and, potentially, some other property values.

Manual builds should still used the latest change list number that is included in the build.

Multiple builds at the same changelist number rarely happen, except in the case of a failed build. In this situation something like Dante's suggestion would work well I think. Our current setup in cruisecontrol doesn't even assign a number to an unsuccessful build.

If we were to manually kick a build for at a changelist that already has a build for it, we would have two builds with the same number. This hasn't been a problem though, since we've never had a need to do that. - why kick a new build when one has already completed?