Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,467,463
Community Members
 
Community Events
177
Community Groups

Repository Tag task tagging the wrong commit

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!

2 answers

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.

0 votes

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.

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.

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.

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.

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events