Skip to content

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.1

and 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/workflows for 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-actions ecosystem 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.

Last updated on