ci: Check if any PRs in the merge queue affect a release #7114

Mrtenz · 2025-11-11T11:12:28Z

Explanation

This adds the merge_group target and adds a check for releases, so we can safely enable the merge queue.

The release check will check for any differences on main or in the merge queue compared to the release branch. If any conflicts are detected, the release will be rejected from the merge queue, and will need to be updated with the latest changes first.

References

Checklist

I've updated the test suite for new or updated code as appropriate
I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

Note

Adds a composite action and workflow job to block release PRs (including merge queue) when releasing packages that conflict with upstream changes.

CI/Workflows:
- Enable merge_group trigger in .github/workflows/main.yml.
- Add check-release job for PRs/merge groups using MetaMask/action-is-release to detect releases and invoking ./.github/actions/check-release; included in all-jobs-complete needs.
New composite action:
- ./.github/actions/check-release/action.yml compares package versions at MERGE_BASE vs HEAD to find released packages, checks files changed between before..MERGE_BASE, and fails with an error if changes touch those package directories.

^{Written by Cursor Bugbot for commit 2f0340c. This will update automatically on new commits. Configure here.}

Mrtenz · 2025-11-12T13:52:08Z

.github/workflows/main.yml

+    needs: check-workflows
+    runs-on: ubuntu-latest
+    steps:
+      - name: Check if the commit or pull request is a release


I considered reusing the is-release job below, but it adds a little bit of complexity around the conditionals, and we don't need the extra options below for merged commits.

Nit: We could maybe skip this for push events? Just because it wouldn't be relevant anymore for push, and this might make it a bit more clear why we have to similarly-named jobs

We could skip the individual steps on push, but not the job itself, since that would cause all-jobs-complete to be skipped.

Mrtenz · 2025-11-12T13:53:02Z

.github/workflows/main.yml

+        uses: MetaMask/action-is-release@d063725cd15ee145d7e795a2e77db31a3e3f2c92
+        with:
+          commit-starts-with: 'Release [version],Release v[version],Release/[version],Release/v[version],Release `[version]`'
+          commit-message: ${{ github.event.pull_request.title }}


This is used so we can determine if an unmerged pull request is a release pull request. github.event.pull_request.title is not defined for other events (push and merge_group), so doesn't affect those.

Mrtenz · 2025-11-12T13:53:29Z

.github/workflows/main.yml

+        with:
+          commit-starts-with: 'Release [version],Release v[version],Release/[version],Release/v[version],Release `[version]`'
+          commit-message: ${{ github.event.pull_request.title }}
+          before: ${{ github.event.pull_request.base.sha || github.event.merge_group.base_sha || github.event.before }}


github.event.before is only defined on push, not on pull_request or merge_group, so I had to add this.

base.sha doesn't seem correct here.

In the action-is-release action, we used github.event.before to get the diff of what changed in a given commit, to check whether the version number had changed. For the push event, the diff betweeen github.event.before and the current commit would only include changes from that push event.

Whereas base.sha refers to the commit on the base branch that the PR was originally branched from. It does not get updated when the branch is updated with a merge commit. That means if a core release goes out while a PR is open, github.event.pull_request.base.sha..HEAD will include a version bump from the unrelated core release on main.

Instead I think we need the merge-base here, between the base branch and the current commit

Either that, or get the merge-base in action-is-release instead

Mrtenz · 2025-11-12T13:54:49Z

.github/workflows/main.yml

    needs: check-workflows
    uses: ./.github/workflows/lint-build-test.yml

+  check-release:


I didn't add a conditional here, but only to the step below. This way we can add check-release as dependency to all-jobs-complete. Otherwise, if check-release (the job) is skipped, all-jobs-complete would be skipped too.

Mrtenz · 2025-11-12T13:57:10Z

.github/actions/check-release/action.yml

+        done
+
+        # Get all files changed ahead of this PR.
+        git diff --name-only "$BEFORE..$(git merge-base HEAD refs/remotes/origin/main)" > changed-files.txt


From my understanding, git merge-base HEAD refs/remotes/origin/main finds the common ancestor between HEAD (i.e., the current commit), and origin/main. We can then diff $BEFORE with that to find any differences on main not included in the current branch.

Mrtenz · 2025-11-12T14:01:02Z

.github/actions/check-release/action.yml

This is an action rather than a workflow to support the uses syntax in a step, rather than as a job. It's related to this comment.

.github/actions/check-release/action.yml

Gudahtt · 2025-11-12T15:56:06Z

.github/actions/check-release/action.yml

+
+        # Get all packages being released in this PR
+        for package in "${PACKAGES[@]}"; do
+          MAIN_VERSION=$(git show "refs/remotes/origin/main:$package" | jq -r .version)


This comparison doesn't seem quite right. We're using origin/main as the "before the current commit" comparison point, but there might be more changes in-between origin/main and the current commit. e.g. if there is a release PR queued before the current one

cursor · 2025-11-12T16:01:39Z

.github/workflows/main.yml

+        if: github.event_name != 'push' && steps.is-release.outputs.IS_RELEASE == 'true'
+        uses: ./.github/actions/check-release
+        with:
+          before: ${{ github.event.pull_request.base.sha || github.event.merge_group.base_sha }}


Bug: Merge Queue Conflict Blind Spot

Using github.event.pull_request.base.sha or github.event.merge_group.base_sha as the before parameter doesn't capture changes from other PRs in the merge queue. These values represent the base branch commit when the PR was created, not the current state including queued changes. This means the release conflict check won't detect conflicts with other PRs ahead in the merge queue, defeating the purpose of checking merge queue conflicts.

Cursor didn't explain this super well, but, I think this comment is at least partially accurate.

If you didn't use any merge commits, base.sha is exactly what we want here I think (at least for the pull_request event, not 100% sure on merge_group), but merges break that assumption.

Essentially what we want to compare in check-release is the previous merge base with the current merge base. We want to compare a merge base for both sides of the comparison.

For the merge_group event, would base.sha refer to the previous commit in the queue itself? Even the merge-base of base.sha might not refer to the correct commit if that's the case.

We might need to consider something like.... grab the PR number from the merge-queue branch name, fetch the branch for that PR, then get the merge-base of that branch.

I found a discussion where someone talked about how to get the PR number from the merge queue branch name: https://github.com/orgs/community/discussions/120203
(in service of a different goal, of skipping the queue for PRs that were already up-to-date, which also would be pretty neat)

.github/actions/check-release/action.yml

.github/workflows/main.yml

Mrtenz commented Nov 12, 2025

View reviewed changes

Mrtenz marked this pull request as ready for review November 12, 2025 14:40

Mrtenz requested a review from a team as a code owner November 12, 2025 14:40

Mrtenz added 4 commits November 12, 2025 15:40

Check if any PRs in the merge queue affect a release

6858bbc

Improve safety and check for changes in main too

3518f99

Fix shellcheck errors

5167c81

Move script to separate action and run for PRs

56f08cb

Mrtenz force-pushed the mrtenz/merge-queue-release-validation branch from d677951 to 56f08cb Compare November 12, 2025 14:40

cursor bot reviewed Nov 12, 2025

View reviewed changes

.github/actions/check-release/action.yml Outdated Show resolved Hide resolved

Gudahtt reviewed Nov 12, 2025

View reviewed changes

Use merge base to check if current commit or PR is a release

5aee098

cursor bot reviewed Nov 12, 2025

View reviewed changes

Use merge base for checking main version

2f0340c

cursor bot reviewed Nov 12, 2025

View reviewed changes

.github/workflows/main.yml Show resolved Hide resolved

Uh oh!

ci: Check if any PRs in the merge queue affect a release #7114

Are you sure you want to change the base?

ci: Check if any PRs in the merge queue affect a release #7114

Conversation

Mrtenz commented Nov 11, 2025 • edited by cursor bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Explanation

References

Checklist

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gudahtt Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gudahtt Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cursor bot Nov 12, 2025

Choose a reason for hiding this comment

Bug: Merge Queue Conflict Blind Spot

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Gudahtt Nov 12, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Mrtenz commented Nov 11, 2025 •

edited by cursor bot

Loading

Gudahtt Nov 12, 2025 •

edited

Loading

Gudahtt Nov 12, 2025 •

edited

Loading

Gudahtt Nov 12, 2025 •

edited

Loading