Skip to content

Work around potential issues in CI/CD workflows caused by changing target branches #294

@MichaelSims

Description

@MichaelSims

Problem:

  1. A stack is pushed: main <- A <- B <- C
  2. Part of the stack is merged: main (A) <- B <- C. B's base ref is updated from A to main
  3. 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.
  4. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions