Adding Version Numbers to Bitbucket Downloads Files (Tags?)

Question

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 · Answer

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.

Ming Han Chung_t7k0xc · Answer

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 · Answer

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