You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I am currently working on automated release creation using Bitbucket and Bamboo. Unfortunately the tagging creates some headaches
The setup is as follows:
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?
I finally managed to get this working. A bit complex, but here is how:
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.
thanks for your answer! I checked the repo settings and they are actually identical.
Also, I performed some other experiments:
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.