Dependency automation and a PR template - #24
Conversation
Dependabot over Renovate: 25 dependencies and one maintainer do not justify installing a third-party GitHub App with write access. Dependabot's grouping covers the need with no added trust surface and no infrastructure. Grouping is ordered first-match-wins so that things which must move together do (React + its types, drizzle-orm + drizzle-kit), tooling churn batches into one CI run, and MAJORS of the runtime dependencies — next, zod, pg, pg-boss, jose, tsx, typescript — match no group and so arrive as individual PRs. Steady state is roughly one to three PRs a week rather than twenty. `applies-to` is left unset, so this governs version updates only: security updates stay ungrouped and immediate. @types/node majors are ignored. They track Node majors, which this repo pins in three files that scripts/check-node-version.sh forces to agree; types ahead of the runtime pass typecheck and fail at execution instead. The docker ecosystem is deliberately absent — reasoning in the file. The PR template asks only for what CI cannot check: hand-run verification, deploy ordering (secrets before the deploy, migration safety), and unprompted findings. No CODEOWNERS: see the PR description.
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 30 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. 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 ignored due to path filters (1)
📒 Files selected for processing (8)
📝 WalkthroughWalkthroughThe pull request adds weekly Dependabot configuration for npm and GitHub Actions. It also adds a pull request template with contributor guidance, verification details, deployment notes, and reviewer flags. ChangesDependency update automation
Pull request process
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Comment |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/pull_request_template.md:
- Line 27: Update the fly.toml change bullet in the pull request template to use
the grammatically correct article “a” instead of “an,” without changing the rest
of the wording.
- Around line 11-17: Update the verification-output guidance in the pull request
template to explicitly require contributors to redact secrets, credentials,
tokens, cookies, and personal data before quoting live-service or manual-test
output. Preserve the existing instruction to provide actual quoted output and
allow “Nothing beyond CI” for routine changes.
- Around line 1-7: Add a level-one heading before the opening HTML comment in
the pull request template, using a concise title such as “Pull request,” so it
becomes the document’s first content heading and precedes “## What changed and
why.”
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 984a3c1a-8480-4e0d-9271-e31a1844b4d1
📒 Files selected for processing (2)
.github/dependabot.yml.github/pull_request_template.md
| deploy that reads it, not with it) | ||
| * a generated drizzle migration, and whether it is safe to run against live | ||
| data while the old code is still serving | ||
| * an fly.toml change: process groups, checks, sizing, release_command |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Correct the article before fly.toml.
Change an fly.toml change to a fly.toml change.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/pull_request_template.md at line 27, Update the fly.toml change
bullet in the pull request template to use the grammatically correct article “a”
instead of “an,” without changing the rest of the wording.
Node 22 entered Maintenance LTS on 2025-10-21; 24 is the current Active LTS line (maintenance 2026-10-20, end-of-life 2028-04-30). Production should run Active LTS, so all three pins that scripts/check-node-version.sh forces to agree move together: Dockerfile (both stages), .nvmrc, and package.json engines. @types/node moves to ^24 in the same commit so the types match the runtime rather than describing APIs it does not have. The Node 22.9 --env-file-if-exists rationale is preserved in .npmrc, the Dockerfile, and docs/ops.md — the floor is now well above it, but that is still why engine-strict is load-bearing for the release command. Also corrects the two hard-coded majors in the dependabot.yml comments added by the preceding commit, which is why this is stacked on tooling-deps.
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
Stage 4. Two files, both in
.github/. No source changes.Dependabot, not Renovate
Renovate is the more capable tool — dependency dashboard, automerge, lockfile maintenance, scheduling windows. None of that pays for itself here:
groupsin 2023, which is what this config uses.If dependency PRs later become a real time sink, the next step is automerge for patch updates — reachable from Dependabot with a small workflow using
dependabot/fetch-metadataandgh pr merge --auto. Not built here; it is a trust decision about CI, not a config detail.How the grouping is shaped
Dependabot assigns a dependency to the first group whose patterns match, so specific groups are ordered before the catch-all. Verified by simulating the rules against the actual dependency list:
reactdrizzlelintingtestingtypesminor-and-patchThe intent: things that must move together do, tooling churn batches into one CI run, and the changes worth reading a changelog for arrive alone. A
zodmajor gets its own PR because zod schemas are this app's config source of truth; a Next major because it drags React with it.Actions are one group — they're all first-party
actions/*and bump majors in step.Security updates are unaffected.
applies-todefaults toversion-updates, so advisories still arrive as individual PRs immediately rather than waiting for Monday.Two deliberate omissions
package-ecosystem: docker. The Dockerfile pins the floating tagnode:22-alpine, not a digest, so the only PR Dependabot could ever raise is a major tag change tonode:24-alpine— editing the Dockerfile alone.scripts/check-node-version.shrequires Dockerfile,.nvmrcandenginesto agree, so that PR fails CI by construction and can never merge as-is. Automating one third of a four-file change is noise.@types/nodemajors are ignored, for the same invariant. Types ahead of the runtime are the dangerous direction:npm run typecheckpasses on APIs Node 22 does not have, and the failure moves to execution. Minors and patches still flow.No CODEOWNERS
Plainly: it does not earn its keep here.
guarzois the only collaborator, so a CODEOWNERS file would assign every review to the one person who already gets it. It only changes behaviour when paired with "Require review from Code Owners" branch protection — and on a single-owner repo that blocks every PR permanently, since you cannot approve your own. Worth revisiting the day a second maintainer appears.The PR template does earn its keep
Not as a checklist of commands — CI runs typecheck, lint, format, build, unit and e2e on every PR, and the checks tab is more trustworthy than a ticked box. It asks for the three things CI structurally cannot know:
SYNC_MODEand other secrets must be set before the deploy that reads them, and drizzle migrations run asrelease_commandVerification
prettier --checkclean on both files · repo-wideformat:checkclean ·lint0 errors, 4 pre-existingno-img-elementwarnings ·actionlintclean · YAML parses and the group rules were simulated againstpackage.jsonto confirm the table above.dependabot.ymlis validated by GitHub on push, not locally — the Insights → Dependency graph → Dependabot tab will show a parse error if one exists.Summary by CodeRabbit
Chores
Documentation