Adding Version Numbers to Bitbucket Downloads Files (Tags?)

[Ming Han Chung]

Hello,

Currently we have a manual step in pipelines that bundles the app and uploads it to the repo's download folder. We want to be able to add the version number of the package to the actual filename but haven't figure out a good way to do this.

So far i tried using the $BITBUCKET_TAG variable but annoyingly enough the system won't pull it if it's a build tripped off by anything other than a TAG workflow. Is there any way i can just do this in a custom workflow?

[Daniil Penkin]

Hello @Ming Han Chung,

BITBUCKET_TAG variable is indeed set only in the builds triggered by tags created in the repository. It wouldn't make sense in other builds: what value would you expect it to have?

There're other variables that you might find useful for versioning (on their own or combined together). I can think of BITBUCKET_BUILD_NUMBER and BITBUCKET_COMMIT which are present in any Pipelines build. You can also embed some custom conditional version number calculation that supports BITBUCKET_TAG as well as other variables if tag is not present.

If you want a more sophisticated versions (e.g. semantic versioning) you need to make use of some third party tools and workflows to configure it. Bitbucket doesn't enforce any versioning system.

Hope this helps. Let me know if you have any questions.

Cheers,
Daniil

[Ming Han Chung]

• Tags are often used as version numbers.
• The download section of the repo is a place to put the latest version / build of a product. 
• Kicking off the build and upload is something you can do in pipelines and talked about here Deploy build artifacts to downloads 
• Custom steps are a thing

Why doesn't it make sense? What if for some reason or another you want to regenerate the build / upload with the same version number? If you used the Tag kicked off build path you wouldn't be able to do it again due to the fact that you can only use a tag once. 

Also what does this mean?

"You can also embed some custom conditional version number calculation that supports BITBUCKET_TAG as well as other variables if tag is not present."

[Daniil Penkin]

I agree with all arguments. However, if a build is triggered for a commit that doesn't have a tag, what should be in BITBUCKET_TAG? What if the commit has multiple tags?

If you manually trigger the pipeline that uploads a version only on commits that do have a tag, you can use git command in your script to get that tag, something like this (note that the output might be a list):

git tag -l --points-at HEAD

Pipeline variable BITBUCKET_TAG is only set when the build is triggered by the tag, and it is always a single value.

Also what does this mean?

"You can also embed some custom conditional version number calculation that supports BITBUCKET_TAG as well as other variables if tag is not present."

I mean something like this in your script:

...
script:
  - if [ -z "$BITBUCKET_TAG" ]; then export VERSION=commit-$BITBUCKET_COMMIT; else export VERSION=$BITBUCKET_TAG; fi
  - echo "This is version: $VERSION"

You can also set specific pipeline for tags and for manual triggers and then reuse the common bits by introducing YML anchors instead of using the logic similar to my example.

Cheers,
Daniil

[Ming Han Chung]

Thanks for the examples.

• For no tags, it should do what it does now. Not show anything.
• If two tags, what does it do now in a tag kicked off branch? Just do the same.

[Daniil Penkin]

No worries :)

If two tags, what does it do now in a tag kicked off branch? Just do the same.

I believe two separate builds will be triggered, one for each tag.