Repository Tag task tagging the wrong commit

Question

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:

* Clone the repository from Bitbucket
* Increase a version number (contained in a checked-in file)
* Commit the updated version number file (script with git commit invocation)
* Push commit using the Bamboo Repository Push task
* Create a tag from the version number and push it to the repository using Bamboo's Repository Tag task
* 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_5ryo2j · Answer

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.

Heiko Oehring_5ryo2j · Answer

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.

Richard White _TechTime_ · Answer

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.