In our branching strategy, depending on when a bug is fixed, it might require one, two or three merges. We don't want to close a bug until the fix is verified in all of the required branches.
One solution is to clone the Jira, one for each commit. Is that what most folks do, or am I missing a cleaner way to track this?
I think there are several different possibilities here. When you say "verified" do you mean tested? Or just merged to that branch...
Where is the list of branches that each fix must go through defined...? Is that a decision on an issue by issue basis? Or can that be inferred from the branch naming convention that we had talked about before?
A better solution than cloning in my opinion would be to use a subtask per branch. You could add a trigger to the subtask workflow, so that it automatically gets moved into the right state when merged, eg "Ready for test". Then QA know what's on their todo list. Of course, just merging isn't the same as having a build ready for testing.
Do all changes eventually end up in master? If so maybe it's enough to add a condition/validator to your workflow that checks the fix is in master.
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot