# DevOps: Dependabot now supports pre-commit hooks — how to automate hook drift without breaking repo hygiene - Link: https://thestackobserver.com/devops-dependabot-now-supports-pre-commit-hooks-how-to-automate-hook-drift-without-breaking-repo-hygiene/ - Published: 2026-03-11T08:14:04-04:00 - Author: Stackxx GitHub adding native Dependabot support for `pre-commit` hooks is one of those updates that looks smaller than it is. On paper, Dependabot can now parse `.pre-commit-config. yaml`, check hook repositories for new tags or revisions, and open pull requests that update the `rev` field. In practice, that means a chunk of repo hygiene work just moved from tribal maintenance into a governed dependency workflow. That matters because pre-commit hooks often sit in an awkward operational gap. Teams rely on them for formatting, linting, secret checks, and policy enforcement, but they age quietly. Someone pins a hook six months ago, nobody wants to touch it before a release cut, and eventually the repo is running old checks while everyone assumes the guardrails are current. ## Why this change matters Pre-commit has become the glue layer for local developer safeguards. It is often where teams enforce: * formatters such as `black`, `prettier`, or `gofmt`-adjacent wrappers * linters and static checks * YAML and Terraform validation * basic secret detection before code ever leaves a laptop * repo-specific policy checks The irony is that these controls are themselves dependencies. They need upgrades, release notes review, compatibility testing, and rollback plans. Before this update, many teams handled them manually or not at all. ## What GitHub actually shipped According to GitHub’s changelog, Dependabot now supports a `pre-commit` package ecosystem. It can track hook revisions pinned by tag or commit SHA, preserve YAML formatting, skip local and meta repositories, support grouped updates, and include changelog or release note context when those upstream projects expose it. That last part is underrated. Hook updates are often annoying precisely because they are low-drama until they are not. A formatter upgrade can reflow half a repository. A linter update can add newly failing rules. Review context is what keeps these changes from feeling random. ## Goal Bring pre-commit hook maintenance into the same repeatable review path you already use for application dependencies, while keeping noise low enough that developers do not learn to ignore the pull requests. ## Prereqs * A repository using `pre-commit` with a checked-in `.pre-commit-config.yaml` * Dependabot version updates enabled via `.github/dependabot.yml` * CI that runs the same hooks the repo expects developers to run locally * At least one human owner for repo hygiene changes, otherwise these PRs will rot like the manual process they replaced ## Steps **1) Add a dedicated Dependabot update entry.** ```wp-block-code version: 2 updates: - package-ecosystem: "pre-commit" directory: "/" schedule: interval: "weekly" ``` **2) Group low-risk hook updates when you can.** If your repo has many hygiene hooks, grouped updates reduce PR spam and make maintenance feel intentional instead of chaotic. ```wp-block-code version: 2 updates: - package-ecosystem: "pre-commit" directory: "/" schedule: interval: "weekly" groups: repo-hygiene: patterns: - "*" ``` **3) Make CI execute the hooks.** The failure mode to avoid is “Dependabot updated the file, but nobody validated the resulting behavior.” If a hook update breaks line endings, formatting, or policy checks, CI should say so immediately. **4) Decide on cadence by repo class.** Security-sensitive platform repos may want daily checks. Stable product repos with heavy formatting churn may prefer weekly. There is no virtue in maximum freshness if it creates review blindness. **5) Treat hook updates like toolchain changes.** Ask whether the new hook release changes output, semantics, or policy posture. For formatters, expect mass diffs. For scanners, expect new findings. For custom hooks, expect the occasional broken assumption. ## Where platform teams should be opinionated | Decision | Recommended default | Why | | Schedule | Weekly | Fresh enough without constant formatter churn | | Grouping | Enable for low-risk hook sets | Reduces review fatigue | | Automerge | No, unless hooks are extremely low impact | Hook updates can rewrite code or change findings | | CI gate | Required | Prevents silent breakage from new hook behavior | ## Common pitfalls * **Confusing freshness with safety.** New hook versions can be safer, but they can also add stricter checks that block active branches. * **Letting grouped PRs get too large.** One PR for eight hook jumps is manageable. One PR for thirty repo-tooling changes is a chore. * **Skipping branch policy alignment.** If developers cannot reproduce CI hook behavior locally, these PRs create confusion instead of trust. * **Ignoring SHA-pinned hooks.** The new support handles SHA-based revisions, which is good for provenance-minded teams, but you still need to read upstream release context. ## Verify * Create or update `.github/dependabot.yml` with a `pre-commit` entry. * Confirm Dependabot opens a PR that changes only the intended `rev` values and related inline comments. * Run `pre-commit run --all-files` locally or in CI against the updated branch. * Check whether changelog/release notes surfaced enough context to judge risk before merging. The larger point is simple: repo hygiene tools are part of your supply chain whether you formalize them or not. GitHub just made it easier to formalize them. Teams should take the hint. --- ## Sources * [GitHub Changelog: Dependabot now supports pre-commit hooks](https://github.blog/changelog/2026-03-10-dependabot-now-supports-pre-commit-hooks/) * [GitHub Docs: configuring Dependabot version updates](https://docs.github.com/en/code-security/how-tos/secure-your-supply-chain/secure-your-dependencies/configuring-dependabot-version-updates) * [pre-commit documentation](https://pre-commit.com/)