Problem:
- A stack is pushed: main <- A <- B <- C
- Part of the stack is merged: main (A) <- B <- C. B's base ref is updated from
A to main
- For some reason part of the verify workflow for
B is retriggered. It may be because it had not yet ran (rare) or had a transient failure and needs to be re-ran without any code changes made.
- Some workflow actions such as https://github.com/13rac1/block-fixup-merge-action attempt to determine the base ref from the env var
GITHUB_BASE_REF, but this is wrong because it's still pointing to the jaspr branch for A which has been deleted. Why this value is "cached" I'm not clear on.
While this doesn't seem like a jaspr bug specifically, I can see several GH actions not responding well to a PR's base branch being changed while the PR's branch doesn't move. To work around this, consider when retargeting B to rewrite the stack (no code changes, just a bump to the commit date) and do a new push.
Problem:
AtomainBis retriggered. It may be because it had not yet ran (rare) or had a transient failure and needs to be re-ran without any code changes made.GITHUB_BASE_REF, but this is wrong because it's still pointing to the jaspr branch forAwhich has been deleted. Why this value is "cached" I'm not clear on.While this doesn't seem like a jaspr bug specifically, I can see several GH actions not responding well to a PR's base branch being changed while the PR's branch doesn't move. To work around this, consider when retargeting
Bto rewrite the stack (no code changes, just a bump to the commit date) and do a new push.