Is it possible to get a "builds since last change" number during tasks

[Daniel Sonck]

I've set-up several plans that have dependencies on each other. I already have these dependencies in bamboo to cause rebuilds whenever something else gets rebuilt. The plans build a linux package directly usable by my deploy environments. I publish these internally to a repository.

The problem comes from the fact that I have the version deduced from git tags and distance to last tag, but each rebuild will not alter this version. While it's possible to include the current build time as an extra version component, it would be much cleaner to be able to have an incrementing counter that resets whenever a new base commit is picked. The time would just grow larger.

Is it possible to get a counter which indicates how many builds have been ran on the same commit?

[Daniel Santos]

Hi @Daniel Sonck

We can't get this information from Bamboo because this information is not stored. When we have a rebuild the DB details of the old build are reset with the new information. There is no counter of rebuilds.

We usually assume that a build should have the same result if the same commit reference is built. Of course, if the build configuration changes, or if a second/third repository used in the same plan has changed, then we will have a new result. Considering that you have other repos, you would still have other revisions registered in the rebuild.

I'm not really sure how I could help you with this one. I think I need more details to check if I'll be able to come with a different approach to tackle this. Please share more information on why you need this information to succeed... maybe a different pipeline design could solve it?!

[Daniel Sonck]

Hi @Daniel Santos I figured I'd reply for others in case they come across this question. I eventually settled on using a date derived version for development builds (which was the primary issue, releases always have an appropriate tag and are expected to build against released dependencies). As I look back, I believe it's more of a shortcoming of using the native package manager and my build system. I've also seen that it's rather brittle as it will always take the latest version of the dependencies, making rebuilds non deterministic.

I plan to migrate this project to a different language (go) which is able to pull in code referenced by version from git which would force me to bump up the library dependencies in the repository, causing new versions based on git describe. This migration also partly because I've been looking into kubernetes as platform for the applications, instead of a bare linux machine and I'm liking it so far.

The old (pre-linux-package) situation actually worked with git submodules which also solves the versioning issue and not require the plan build triggering of bamboo as all dependencies are locked in git and a new commit must be made to update it.

So for any others: First see if you can lock your dependencies in the commit, forcing you to add commits to update dependencies and hence upgrade the version generated. If not, then try to find some way to do it as it will help with deterministic builds.

[Daniel Santos]

Hi @Daniel Sonck

Thank you so much for coming back here to share your findings. This is the spirit of a collaborative environment, I'm pretty sure your ideas and experience will help others facing a similar scenario.

Thank you Daniel!