Jira integration and stack merges don't trigger task transitions

[jameskyle]

Ok, totally not a core spr issue, but I figure there's a lot of Jira users impacted by this.

The way that spr merges a stack, with mergemethod: squash at least, is the commits are squashed into a single commit.

Say I have a 3 commit stack:

• PROJ-123 adds feature 1
• PROJ-124 adds feature 2
• PROJ-125 adds feature 3

These are properly detected by the integration and are visible in your Jira issue. Jira will transition them from the backlog to "In Progress" as expected (or whatever your workflow config is)

But when you merge the stack, it firsts creates a squashed diff with all commits commits, so the new single squashed PR becomes something like

PROJ-123 adds feature 1

* PROJ-123 adds feature 1

commit-id: 123456

* PROJ-124 adds feature 2

commit-d: 123457

* PROJ-125 adds feature 3

commit-id: 123458

And the merged PR's are closed. This results in the connected issue not transitioning and the linked PR marked as "Declined"

So these have to be manually transitioned and it can muck with various ticket / PR tracking metrics as well.

One idea I've had is merging each commit individually in the stack one at a time. This might prevent the closing of the PR? I'll test next round.

But generally, I'm curious if there's any way spr could handle this gracefully, e.g. a flag that specifies each commit should be merged individually. Or what others are doing to work around the behavior.

[jameskyle]

I've tested and a work around is to merge the stack one PR at a time with --count 1.

[ejoffe]

This sounds like another unfortunate side effect of merging the whole stack in a single PR. As you mentioned merging stacks one at a time is a workaround. The issue with merging one pr at a time automatically is that there are race conditions with GitHub and also the checks for each PR have to rerun after every merge. So far I have not found a better way to achieve an atomic merge of all the commits in an automated fashion. Until a better approach is found, this is something you have to deal with.