Remote Trigger and bamboo.repository.revision.number variable

[Erik Anderson]

I setup a build plan trigger following these instructions. The build triggers ok but the trigger reason shown in summary contains an unrecognizable number:

 #13 Changes by last, first <@mycompany.com> 54d8a264c2e8b32a63b980c81e6f1e964c9125e9

That value is derived from bamboo.repository.revision.number variable set during a build:

command	12-May-2023 13:28:24	Substituting variable: ${bamboo.repository.revision.number} with 54d8a264c2e8b32a63b980c81e6f1e964c9125e9

How does bamboo determine the value? 

Is it part of the trigger data sent from git host (gitlab) which would make it their question to answer?

[Eduardo Alvarenga · Accepted solution]

Hello @Erik Anderson

Once Bamboo receives a build trigger from GitLab, it initialises a Change detection process that will compare its local revision of the local git repository with the one from the remote VCS. If they differ, Bamboo will understand a new commit awaits a build and will trigger it.

The ${bamboo.repository.revision.number} is the Git revision that comes from the remote repository and is added as a variable.

The GitLab trigger configuration steps will instruct you to add that revision as a label to ease the identification and match a build to a specific commit.

More information here:

• Repository triggers the build when changes are committed 

Thank you,

Eduardo Alvarenga
Atlassian Support APAC

--please don't forget to Accept the answer if the reply is helpful-- 

[Erik Anderson]

Thanks Eduardo, 

See reply under Scott Geertgens answer for additional details

[Scott Geertgens · Accepted solution]

This looks to actually be a commit hash representing the commit on which the build was based. If this isn't the _correct_ commit hash, check that you don't have a reference to both BitBucket and GitLab in the same build as it will likely tie back to the BitBucket commit as priority.

[Erik Anderson]

That's what happened, I had 2 repositories in the plan configuration (bitbucket, gitlab) but was only referencing 1 (gitlab) in the pipeline checkout.  The change that triggered the build was from gitlab but the hash used to label the build was from bitbucket (maybe because it was the first one in the configuration).  After I removed bitbucket, it began using gitlab hash for labelling.