Increment a number in Bitbucket pipelines

[Marcus Nordqvist]

I have a netcoreapp1.0 that I build using Bitbucket pipelines and pack with dotnet pack, and push to Octopus deploy as a package MyAssembly.Api.1.0.0-beta-*.nupkg where * is supposed to be a commit number/build number (or any other stable incremented number).

Since the commit identifiers in GIT are UUIDs, I have tried the following commands (see below) to get the commit count, but the resulting commit count is very unreliable and does not work as expected. Locally I get it working just fine and the commit count is incremented for every commit I make to my local repo. Unfortunately, none of the commands work in the pipeline (running in a Docker container). For some reason the commit count stays the same or even decreases sometimes.

I read somewhere that it has to do with "shallow/unshallow" git repo blabla..., and that it might be solved by logging in (to GIT) every time. I do not wish to do this if I can avoid it, and I find it kinda ironic that I would need to login to GIT within Bitbucket itself.

git shortlog | grep -cE '^[ ]+\w+'
git rev-list HEAD --count
git rev-list --all --count
git rev-list --no-merges --count HEAD
git log --pretty=format:'' | wc -l
git log master --pretty=oneline | wc -l

Q: Is there any other way to increment a value and access it as a variable in a pipeline?

[Trevor Raiss]

There is a $BITBUCKET_BUILD_NUMBER environment variable

https://bitbucket.org/blog/bitbucket-pipelines-can-count-builds-numbered

https://bitbucket.org/site/master/issues/12838/build-number-that-increments-on-every

https://confluence.atlassian.com/bitbucket/set-a-new-value-for-the-pipelines-build-number-935380150.html

[Matt Ho]

Our solution to that is a small tool that uses dynamodb to store the build number.  Fits within the dyanmodb free tier (yay!) and is a small binary.

curl -L -o /bin/bitbauble https://bitbucket.org/savaki/bitbauble/downloads/bitbauble0.1.0.linux-amd64
chmod +x /bin/bitbauble

BUILD_NUMBER=$(/bin/bitbauble generate --key my-project-key)

https://bitbucket.org/savaki/bitbauble

[jbarrett]

Thanks Matt!

We've tried all the git options and adding hashes and timestamps etc. without luck. Eventually, those methods don't scale. We require a sequential number to append to our version number to keep things in order - TeamCity does this by default. This looks like a great solution and we will give it a try.

Thanks for sharing. 

You're friends at DealerSocket.

[Stefan Peter]

Sadly I run into the same issue. So currently the only solution seems to be not to use pipelines in bitbucket. :(

[Richard J Armstrong]

It might work to use the unix time

 date +%s

Not perfect but at least should be consecutive.

[Stefan Böther]

I use something like this in my pipeline to get a BUILD_NUMBER , the BUILD_LABEL I set in the bitbucket-pipeline settings.

        script: # Modify the commands below to build your repository.
# Build Number ermitteln 
          - BUILD_NUMBER=`git log --oneline | wc -l`
          - echo "${BUILD_LABEL}.${BUILD_NUMBER}"
# Restore, Build and Test
          - dotnet restore
          - dotnet build ./src/ApiGateway/project.json
          - dotnet test ./test/ApiGatewayTest/project.json -c Debug
# Package produzieren und publizieren 
          - dotnet restore
          - dotnet publish ./src/ApiGateway/project.json -c Release -o ./app --version-suffix=$BUILD_LABEL.$BUILD_NUMBER
          - dotnet pack ./src/ApiGateway/project.json -c Release -o ./artifacts --version-suffix=$BUILD_LABEL.$BUILD_NUMBER 

[Marcus Nordqvist]

But my problem remains, I need a unique BUILD_NUMBER, which is incremented every build or commit. 

Unfortunately, 

BUILD_NUMBER=`git log --oneline | wc -l`

will not work, because the count of the log may remain the same or even decrease in some cases.

[Artem Leonov]

+1, same issue

[arthurtagirov]

Somebody trying using Bitbucket api of pipelines for this?

For example, you can query:

https://api.bitbucket.org/2.0/repositories/{owner}/{repo_slug}/pipelines/ 

and use size field from response as build number. But it was broken when you make more than one pipeline at one moment...