Keeping Actions Updated With Dependabot
Pinning SHA is a trade against automatic updates for a fixed, verifiable commit — and flagged that trade-off as something to solve, not just live with. This chapter solves it: Dependabot can watch every SHA-pinned action in your workflows and open a pull request the moment a newer version ships, so staying current becomes a PR you review instead of a lookup you have to remember to do by hand.
What Dependabot Actually Does Here
Dependabot version updates work by ecosystem — npm, pip, Docker, and so on — and GitHub Actions is one of them. Point it at github-actions, and it scans your .github/workflows directory (and any action.yml/action.yaml at your repo root) for every uses: line, checks each referenced action’s repository for newer releases, and opens a pull request when it finds one.
Dependabot specifically understands the SHA-plus-comment convention you’ve been using. When it sees a line like this:
uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1and a newer release exists, it doesn’t just bump the SHA and leave a stale comment behind — it updates both together, so the pinned commit and its human-readable version stay in sync. You end up reviewing a PR that looks like this:
- uses: actions/checkout@93cb6efe18208431cddfb8368fd83d5badbf9bfd # v5.0.1
+ uses: actions/checkout@1af3b93b6815bc44a9784bd300feb67ff0d1eeb3 # v6.0.0
That’s the entire workflow this chapter sets up: Dependabot notices, opens the PR, you look at the diff and the linked release notes, and you merge or don’t.
Note
Dependabot only recognizes actions referenced with the standard owner/repo@ref syntax — it won’t track a locally defined composite action in ./.github/actions/, and it can’t resolve a pinned SHA that isn’t associated with any tag at all (in that case it just tracks the latest commit on the action’s default branch instead, which is a weaker signal but still better than nothing).
Enabling It
Dependabot version updates are configured with a single file: .github/dependabot.yml, committed to your repository like any other file. Create it with this content:
version: 2
updates:
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"Three fields, each doing something specific:
package-ecosystem: "github-actions"tells Dependabot which ecosystem this block covers — this is what activates the action-scanning behavior described above.directory: "/"is set to your repository root regardless of where your workflow files actually live; Dependabot always looks in.github/workflowsfor this ecosystem specifically, so this doesn’t need to point at that folder directly.schedule.interval: "weekly"sets how often Dependabot checks for new versions."daily"is also valid if you’d rather see updates sooner at the cost of more frequent PRs; for actions specifically, weekly is a reasonable default — action releases don’t usually need same-day attention the way an urgent security patch to a runtime dependency might.
Commit that file to your default branch, and Dependabot takes it from there — no separate setup step, no token to configure. It uses the same GITHUB_TOKEN-based automation GitHub already runs on your behalf.
What A Dependabot PR Actually Looks Like
When an update is available, Dependabot opens a pull request that edits your workflow file directly, with a description summarizing the version bump, and — where available — a link to the action’s release notes and changelog. It’s an ordinary pull request: your usual CI runs against it, you can request changes, and merging it is exactly like merging any other change to a workflow file.
This is worth sitting with for a second, to better understand. A floating tag like @v5 gives you updates with no review step at all — the new code just runs, next trigger. A Dependabot-managed SHA pin gives you the update as a diff, with a changelog attached, that a human looks at before it takes effect. You haven’t given up freshness; you’ve turned an invisible, automatic change into a visible, reviewed one.
A Quick Sanity Check Before Moving On
Two things worth confirming once you’ve added dependabot.yml:
- Check your repository’s Insights → Dependency graph → Dependabot tab (or wait for the first scheduled run) to confirm Dependabot picked up the
github-actionsecosystem and is tracking the actions in your workflows. - If you have actions pinned to a SHA with no version comment, or pinned to a SHA that isn’t tied to any release tag, go back and add the comment — Dependabot’s PR titles and descriptions are far more useful when they can reference a real version number instead of just two raw commit hashes.
With this in place, the SHA-pinning habit from now stops being a maintenance burden and becomes what it was always meant to be: a way to see exactly what changed, every time something does.