fix: repair pull requests again after a rebase - #10451
Merged
Merged
Conversation
cryptodev-2s
enabled auto-merge
September 24, 2026 17:50
mcmire
reviewed
Sep 24, 2026
mcmire
reviewed
Sep 24, 2026
Co-authored-by: Elliot Winkler <elliot.winkler@gmail.com>
1 of 4 tasks
FrederikBolding
pushed a commit
that referenced
this pull request
Sep 28, 2026
## Explanation `@ethersproject` has 11 packages here and they all ship from one repository at one version, so the 5.8.0 release produced #10478, #10481, #10482, #10483 and #10484, each bumping the same manifests and writing into the same changelogs. They cannot be merged independently without conflicting. `config:recommended` already pulls in `group:monorepos`, but that works off Renovate's own monorepo data, which has no `ethers` entry, nor most of ours. So instead of listing scopes, this groups by the repository a package is published from, which is the thing that actually decides whether releases move together. `groupName` supports templating and `sourceRepoSlug` is available, so it is one rule for every dependency. That is also more accurate than grouping by npm scope. `@noble` would have been wrong as a scope group, since `noble-hashes`, `noble-curves` and `noble-ciphers` are three separate repositories, and this splits them correctly without being told. Two exclusions: - `@types`, because DefinitelyTyped is a single repository holding 21 unrelated libraries. The two that do belong with something else, `@types/jest` and `@types/react`, are already paired with their runtime packages by `group:jestPlusTypes` and `group:react`. - `@metamask`, because grouping it would touch most of the monorepo in one pull request. The `{{#if}}` fallback is load bearing rather than decoration. A package with no `sourceUrl` gets an empty `groupName`, and `hasGroupName` only tests for `null`, so without it every such package would collapse into one nameless group. Validated with `renovate-config-validator --strict`. Renovate will supersede the five open `@ethersproject` pull requests with a single grouped one on the next run. ## References Follows #10451. Part of WPC-1161. ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [x] 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them
pull Bot
pushed a commit
to Reality2byte/core
that referenced
this pull request
Sep 28, 2026
## Explanation `@ethersproject` has 11 packages here and they all ship from one repository at one version, so the 5.8.0 release produced MetaMask#10478, MetaMask#10481, MetaMask#10482, MetaMask#10483 and MetaMask#10484, each bumping the same manifests and writing into the same changelogs. They cannot be merged independently without conflicting. `config:recommended` already pulls in `group:monorepos`, but that works off Renovate's own monorepo data, which has no `ethers` entry, nor most of ours. So instead of listing scopes, this groups by the repository a package is published from, which is the thing that actually decides whether releases move together. `groupName` supports templating and `sourceRepoSlug` is available, so it is one rule for every dependency. That is also more accurate than grouping by npm scope. `@noble` would have been wrong as a scope group, since `noble-hashes`, `noble-curves` and `noble-ciphers` are three separate repositories, and this splits them correctly without being told. Two exclusions: - `@types`, because DefinitelyTyped is a single repository holding 21 unrelated libraries. The two that do belong with something else, `@types/jest` and `@types/react`, are already paired with their runtime packages by `group:jestPlusTypes` and `group:react`. - `@metamask`, because grouping it would touch most of the monorepo in one pull request. The `{{#if}}` fallback is load bearing rather than decoration. A package with no `sourceUrl` gets an empty `groupName`, and `hasGroupName` only tests for `null`, so without it every such package would collapse into one nameless group. Validated with `renovate-config-validator --strict`. Renovate will supersede the five open `@ethersproject` pull requests with a single grouped one on the next run. ## References Follows MetaMask#10451. Part of WPC-1161. ## Checklist - [ ] I've updated the test suite for new or updated code as appropriate - [x] 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation
Renovate rebases wipe the repair commits, and the workflow only ran on
openedandreopened, so the only way to get them back was closing and reopening the pull request. It listens tosynchronizenow.The
checkjob stops it reacting to its own push, since the repair commits undergithub-actions[bot].Manual testing
Push to an open Renovate pull request, confirm the repair runs once and the run from its own push stops at
check.References
Follows #10334. Part of WPC-1161.
Checklist
Note
Low Risk
Changes are limited to a Dependabot/Renovate repair GitHub Actions workflow; no application runtime or auth logic is touched.
Overview
Renovate rebases drop the workflow’s repair commits, but the job only ran on
opened/reopened, so repairs could only be restored by closing and reopening the PR. The workflow now also triggers onsynchronize, so new pushes and rebases can trigger repair again.To avoid a loop when the repair job pushes to the branch, a
checkjob inspects the PR head commit author via the GitHub API and skipsrepairwhen the last commit is already fromgithub-actions[bot].repairis gated onneeded == 'true'.Shared repair commit identity moves to workflow
env(used by both the author check and git config), andconcurrencyper PR cancels stale in-flight runs when the branch moves again.Reviewed by Cursor Bugbot for commit 798f702. Bugbot is set up for automated code reviews on this repo. Configure here.