Repository Tag task tagging the wrong commit

[Heiko Oehring]

Hi folks,

I am currently working on automated release creation using Bitbucket and Bamboo. Unfortunately the tagging creates some headaches

The setup is as follows:

1. Clone the repository from Bitbucket
2. Increase a version number (contained in a checked-in file)
3. Commit the updated version number file (script with git commit invocation)
4. Push commit using the Bamboo Repository Push task
5. Create a tag from the version number and push it to the repository using Bamboo's Repository Tag task
6. Execute tests and so on

All of this works fine in a demo setup. When a commit #1 is pushed the plan runs and creates a commit #2 which is also nicely tagged.

However when I try the same thing with the production repository something strange happens:

Commit #1 is pushed by a user. A commit #2 is created with the proper updated version number and it is also pushed. But then the tag is created on commit #1 instead of #2.

Does anyone have an idea where this behavior could come from and how to fix it?

Thanks!

[Heiko Oehring]

I finally managed to get this working. A bit complex, but here is how:

• I created a separate plan which is only there to create the tag (the commit is still done in the original plan). It is not a child plan of the original one, but completely separate.
• The second plan gets only triggered if the commit message is the one created by the version numbering tool (via a regex)
• For this of course I had to create another linked repository. It uses the same Bitbucket repository, but with the different change detection configuration described above)

The effect is that the second plan now is triggered by the commit using the version number and then uses this commit as a base for tagging.

Maybe this will help someone running into a similar issue.

[Richard White _TechTime_]

I haven't run into this exact issue before, but I have run into issues with the git repo the agent is working with not being fully up to date, and I wonder if this is related.

I would investigate if there is some difference in the linked repository settings between the demo and production repositories.

I would particularly look and see if:
"Enable repository caching on agents" is disabled for both production and demo repositories.

[Heiko Oehring]

Hello Richard,

thanks for your answer! I checked the repo settings and they are actually identical.

Also, I performed some other experiments:

• Check out the source code again after pushing the commit - didn't help as Bamboo explicitly checks out again the same commit the plan was triggered on.
• Move the tag creating to a separate stage - same as before
• Move the tag creation to a child plan - same as before
• Create the tag via direct git commands - doesn't work due to the caching mechanism of Bamboo. The remote that I can push on is not mine, but the one in the repo cache. So in the end the tags don't show up on the real remote.

The last experiment brought me to the idea that I could manipulate the remote and enter mine as target. However this might cause havoc if other plans would access the same repo.

Honestly the fact that the push task does not update the checked out version (I assume this is stored in the plan variable) seems to be a bug to me.

[Richard White _TechTime_]

Interesting, it does seem like it could be a bug.

In terms of a workaround, you could always add an additional remote with a unique name, so that it does not affect other builds using the same repo.

[Heiko Oehring]

True. But I am afraid this might mess things up if multiple plans use the same repo from the cache. There could be weird inconsistencies.