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

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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.

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
Community showcase
Published in Bamboo

Bamboo 7.2 is here!

I'm happy to announce that Bamboo 7.2 has been released and it’s overflowing with awesome new features. This will be the last major Server release before the launch of Bamboo DC. Bamboo logs We...

534 views 6 7
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you