renovate: rebaseWhen=conflicted + split prettier/jshint + ungroup major Actions - #8
Merged
Merged
Conversation
…or Actions - rebaseWhen: conflicted (drop :rebaseStalePrs): stop force-rebasing every open branch on each merge to main. Safe because branch protection is strict:false. The old behind-base-branch behavior orphaned manual commits pushed onto Renovate branches and re-ran CI repo-wide on every merge. - Split prettier + jshint out of the eslint 'linting' group: they release independently, so grouping let either gate the other's soak window. - Major GitHub Actions bumps get individual PRs (groupName:null) for independent review; minor/patch stay grouped to cut noise.
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
1 participant
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.
Why
Three Renovate-policy frictions surfaced while working the open dependency PRs in
jellyrock/jellyrock:1.
rebaseWhen: conflicted(was:rebaseStalePrs=behind-base-branch):rebaseStalePrsforce-rebases every open Renovate branch whenevermainmoves. On a busy repo this is a rebase storm — each merge re-triggers full CI on every open branch and orphans any manual commit pushed onto a Renovate branch. This bit live: merging one PR force-rebased an open major-bump branch and orphaned a hand-applied migration commit (had to cherry-pick it back).Branch protection on the repos is
strict: false(branches need not be up-to-date to merge), so there's no protection reason to keep every branch current.conflictedrebases only on a genuine conflict.Tradeoff (documented in the README): Renovate flags
conflictedas not-ideal with automerge, for two reasons — (a) two independent updates could merge without being tested together; (b) automerge stalls if PRs must be up-to-date. (b) is moot here (strict:false); (a) is low-risk for independent dep bumps and caught by push-triggered CI onmain. For a PR where you want a fresh pre-merge integration test (a major), tick Renovate's rebase checkbox on demand.2. Split
prettier+jshintout of thelintinggroupeslint is version-coupled to its plugins → keep grouped. prettier and jshint release independently, so bundling their soak windows let a fresh release of one gate the others. (Concrete case: a
lintinggroup PR carried an eslint minor and a prettier bump; the prettier change needed a reformat, holding up the eslint minor.)3. Major GitHub Actions bumps get individual PRs
Routine minor/patch Action bumps stay grouped (noise reduction); majors split out (
groupName: null) for independent review — a major can change runner requirements or default behavior a green build won't surface. (A recent grouped Actions-major PR bundledcheckout v7+cache v6; checkout v7 had a breaking fork-PR-checkout change that warranted its own review.)Changes
renovate/default.json: drop:rebaseStalePrs, addrebaseWhen: conflicted; removeprettier/jshintfrom thelintinggroup (new label-only rule); add a github-actionsmajor→groupName: nullrule.renovate/README.md: rewrite the matching policy bullets + the rebase tradeoff.Rollout
Per the README's own guidance, worth a Renovate dry-run on one consuming repo before merge. Cascades to all jellyrock repos on the next scan.