Skip to content

Conversation

@bfops
Copy link
Collaborator

@bfops bfops commented Oct 27, 2025

Description of Changes

Add cancel-in-progress to our GitHub workflows.

API and ABI breaking changes

None

Expected complexity level and risk

1

Testing

  • Pushing new commits to this PR causes cancels of previous CI runs

@bfops bfops requested a review from jdetter October 27, 2025 17:44
@bfops bfops added release-any To be landed in any release window no runtime change This change does not affect the final binaries labels Oct 27, 2025
Copy link
Collaborator

@jdetter jdetter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One question on this but no objections to merging 👍 I haven't tested this myself.

@bfops bfops added this pull request to the merge queue Oct 27, 2025
Merged via the queue into master with commit 9ad5e70 Oct 27, 2025
51 of 83 checks passed
@bfops bfops deleted the bfops/cancel-in-progress branch October 28, 2025 16:54
@bfops bfops mentioned this pull request Nov 4, 2025
2 tasks
github-merge-queue bot pushed a commit that referenced this pull request Nov 5, 2025
# Description of Changes

The merge queue was (partly) getting borked because we were putting all
non-PR CI events into the same concurrency group, which meant they all
non-PR CI jobs would run sequentially instead of running in parallel.
This sometimes caused _painfully_ long delays in the merge queue.

This was due to my misunderstanding in
#3501 (comment),
where I didn't realize that `cancel-in-progress: false` would cause
everything to queue up.

Now, for non-PR events, we append the commit SHA to the concurrency
group. For merge queue events, this should be the SHA of the ephemeral
merge commit that GH creates, so it will never conflict. For push events
or manual workflow dispatch events, the SHA should be a sane way to
recognize/cancel redundant events.

# API and ABI breaking changes

None. CI-only change.

# Expected complexity level and risk

1

# Testing

- [x] PR CI passes on this PR
- [x] PR CI is still canceled on this PR if a new commit is pushed

Unfortunately it's hard to test the behavior for non-PR events without
merging and seeing if it works.

---------

Co-authored-by: Zeke Foppa <bfops@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

no runtime change This change does not affect the final binaries release-any To be landed in any release window

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants