ci: Add Renovate configuration - #72
Conversation
|
Warning Review limit reached
Next review available in: 35 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThe change adds a Estimated code review effort: 2 (Simple) | ~10 minutes Mergeability Score: 🟡 Moderate · up to The Renovate setup can generate dependency updates that fail repository checks, while configuration validation is skipped in CI and may validate the wrong scope. The PR should not merge until these bounded CI-enforcement issues are corrected or explicitly accepted by the owner. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
`renovate-config-validator` rejects the whole file:
packageRules[0]: packageRules cannot combine both matchUpdateTypes
and rangeStrategy
`rangeStrategy` is a pre-lookup option — Renovate needs it before it has
resolved which updates exist, so it cannot be gated on an update type
that only exists after the lookup. A config error is fatal: Renovate
opens a Config Validation issue and skips the repository, so nothing in
here took effect.
Dropping `matchUpdateTypes` is also what the rule wants. It described
itself as eagerly bumping "on every version release" while listing only
minor and major, so a patch release of flagsmith-go-client stayed
disabled by the `security:only-security-updates` preset. Unfiltered, the
rule re-enables every update type, which is the stated intent — and it
matches the equivalent rule in Flagsmith/flagsmith, which carries
`rangeStrategy` with no update-type filter.
beep boop
`matchPackageNames` entries are minimatch patterns tested against the dependency name, and for the gomod manager that name is the full module path — `github.com/Flagsmith/flagsmith-go-client/v5`. A bare `flagsmith-go-client` has no wildcard, so it was an exact-string pattern that matched nothing: the rule never fired and the eager bump never happened. The bare name is what Flagsmith/flagsmith uses, but there the manager is pep621, where the dependency name really is the bare package. The glob keeps matching across a major bump. Pinning `/v5` would work today and then silently stop matching at v6 — losing the eager bump at exactly the release the rule exists to pick up, and losing it quietly, since an unmatched pattern is not an error. The brace also keeps the pattern from reaching past the module: it matches the bare path and any `/vN` suffix, but not a neighbour like `flagsmith-go-client-extra`. beep boop
`go` is not a manager. Renovate's only Go module manager is `gomod`; the closest thing to `go` is the datasource of the same name, which is what `matchManagers` does not take. Renovate does not validate the contents of `matchManagers` against the manager list, so this failed the quiet way: the rule matched nothing and dependency PRs arrived unlabelled, with no error to explain why. beep boop
The flagsmith-go-client rule opts into major updates, and a Go major is a new module path. Renovate only edits go.mod by default, so a v5 -> v6 bump would leave the sole importer, internal/cmd/evaluate.go, on flagsmith-go-client/v5 and the PR would not build. `gomodUpdateImportPaths` moves the imports with the requirement, and implies gomodTidy, which the lint job's `go mod tidy -diff` insists on. The PR still needs reading — a major usually carries API changes past the import path — but it arrives buildable rather than broken on arrival. beep boop
The config landed with a fatal error in it, which is the failure mode worth a hook: Renovate answers an invalid file by opening an issue and skipping the repository, so the config silently does nothing and the next dependency PR that fails to arrive is the only symptom. Checked against the file as it was first committed — the validator exits 1 on the matchUpdateTypes/rangeStrategy conflict. Pre-push rather than pre-commit, matching go-test: renovate.json changes rarely and the hook installs Renovate to run. Also skipped on pre-commit.ci, as every pre-push hook here is. Follows Flagsmith/flagsmith, which added the same hook in #7657. beep boop
`cli` is not a label in this repository — `dependencies` is the only one of the pair defined. The component labels it came from belong to Flagsmith/flagsmith, where `api`, `mcp` and `front-end` say which part of a monorepo a dependency PR touches. Here every PR is the CLI, so the label distinguishes nothing even once created. beep boop
There was a problem hiding this comment.
Actionable comments posted: 3
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 4a3a6be0-61df-42dc-8a94-0cb5792cb0c7
📒 Files selected for processing (2)
.pre-commit-config.yamlrenovate.json
The lint job runs `go mod tidy -diff` on every pull request, so a Renovate
branch that leaves go.mod or go.sum untidy fails CI.
`gomodUpdateImportPaths` alone does not cover this. Renovate gates the
implied tidy on the update being major:
isGoModTidyRequired = ... || (config.updateType === 'major' &&
isImportPathUpdateRequired)
and `isImportPathUpdateRequired` is itself `gomodUpdateImportPaths &&
updateType === 'major'`. So the tidy I claimed in 56fa9ab was implied
only for majors — every minor and patch branch ran `go get` alone. Those
are the common case here: the eager flagsmith-go-client bumps and the
security patches the rest of the config exists to raise.
Naming `gomodTidy` explicitly makes the tidy unconditional.
beep boop
Given a file to check, `renovate-config-validator` assumes it is a self-hosted global config; `--no-global` is how you say otherwise. The hook was reporting `Validating renovate.json as global config` and grading this file against the wrong schema — repo and global config accept different options, so a mismatch could pass here and still be rejected by the bot. Re-checked both ways: the original file still fails on the matchUpdateTypes/rangeStrategy conflict, and the current one passes, now as `Validating renovate.json as repo config`. beep boop
b1a69c4 left the check local-only: pre-commit.ci was told to skip it, and no workflow runs it, so it only ever fired for someone who had installed the pre-push hook. Dropping it from `ci.skip` is not enough on its own. pre-commit.ci runs the pre-commit stage, so a hook staged `pre-push` stays skipped whatever `ci.skip` says. Both had to go. Moving off pre-push costs nothing on ordinary commits: the hook carries its own `files` pattern for renovate config files, so it reports "no files to check" and skips unless renovate.json is in the commit. Verified at the new stage — it still fails the original file and passes this one. beep boop
b84cb2c tried to enforce this on pre-commit.ci and broke the build: build of renovatebot/pre-commit-hooks:renovate@44.28.0 for node@lts exceeds tier max size 250MiB: 402.6MiB The hook cannot run there at any stage, so `ci.skip` and `stages: pre-push` both go back, and GitHub Actions takes the check instead. prek runs the hook straight from .pre-commit-config.yaml, which keeps the pinned rev in one place — an `npx renovate-config-validator` step would have been a second version to hold in step with the hook, the problem the golangci-lint pin already has. Only this hook, not the rest of `ci.skip`: golangci-lint, go mod tidy and go test already have their own steps, and go test's runs across three operating systems that one prek invocation would narrow to Linux. Verified with the invocation the job uses: passes on this file, exits 1 on the file as first committed, and reports `Validating renovate.json as repo config`, so --no-global survives the trip through prek. beep boop
2 participants
No description provided.