Pinning Your AI Reviewer: Safe Versioning for GitHub Actions

When your AI code reviewer is a GitHub Action, which version you pin to quietly decides whether your reviews stay stable, get the latest fixes, or break unexpectedly. The safe default for most teams is a floating major tag — like @v1 — which gives you every bug fix and improvement within a major version without surprise breaking changes. Pin to an exact semver (@v1.2.3) when you need fully reproducible CI, and use @main only if you actively want the bleeding edge. The one rule that saves real pain: never leave a stale, outdated pin in place, and never pin to a deprecated major. This post covers the trade-offs so you can choose deliberately instead of by accident.

Key Takeaways

• A floating major tag (@v1) is the best default: you get fixes and improvements within the major version, no breaking surprises.
• Pin exact semver (@v1.2.3) for fully reproducible builds; pin @main only for the latest, possibly-unstable changes.
• Avoid deprecated majors (e.g. an old @v0) — they often fail as the ecosystem moves on.
• The reusable-workflow reference is pinned the same way: uses: antongulin/robin/.github/workflows/review.yml@v1.

How GitHub Action Pinning Works

A GitHub Action is referenced in your workflow with a uses: line that ends in a git ref — a tag, branch, or commit. That ref decides exactly which version of the Action’s code runs. The same mechanism applies whether you call an Action directly (uses: owner/action@ref) or call a reusable workflow (uses: owner/repo/.github/workflows/file.yml@ref).

Most well-maintained Actions publish a few kinds of refs, and the choice between them is a stability-vs-freshness trade-off. Using Robin as a concrete example, the documented options map cleanly onto the general pattern.

The Pinning Options, Ranked by Use Case

Floating major tag — @v1 (recommended default)

A floating major tag points at the latest release within a major version and is updated on each release. Pin @v1 and you automatically get every bug fix and improvement in the 1.x line, while being protected from breaking changes — those would ship under a new major (v2). For the large majority of teams, this is the right default: current, but stable.

uses: antongulin/robin/.github/workflows/review.yml@v1

Exact semver — @v1.2.3 (maximum reproducibility)

Pinning an exact released version freezes the Action completely. The same workflow run produces the same Action code every time, which matters when you need fully reproducible CI or you’re change-controlling everything that touches your pipeline. The trade-off: you don’t get fixes until you bump the pin yourself, so you take on the upgrade cadence manually.

@main — the bleeding edge

Pointing at the default branch gives you the very latest changes, including ones not yet in a tagged release. Use this only if you actively want to track development — it can change under you without a release, which is the opposite of what most production pipelines want.

Avoid stale or deprecated majors

The pin that bites teams is the forgotten one. An old major that’s no longer maintained (for Robin, that’s @v0 — explicitly marked “do not use”) tends to fail as dependencies and platforms move on. A stale exact pin can also rot — quietly missing security fixes for months. Whatever you choose, make upgrading the major a deliberate, periodic decision, not something you discover when CI breaks.

A Sensible Policy

For most teams reviewing real PRs, the policy that balances stability and freshness:

1. Default to the floating major tag (@v1) so you get fixes automatically without breaking changes.
2. Pin exact semver only where you have a hard reproducibility or change-control requirement.
3. Reserve @main for a test repo where you want to preview upcoming changes, not your main pipeline.
4. Review your pins periodically — schedule a check each quarter to bump majors deliberately and retire any deprecated refs.
5. Pin the same way across repos so the version story is consistent and auditable.

In our experience maintaining Robin, nearly all the “it suddenly stopped working” reports trace back to one of two things: a pin to a deprecated major that finally aged out, or an @main pin that picked up a change the team didn’t expect. The floating major tag avoids both, which is why it’s the recommended default.

Frequently Asked Questions

Should I pin my AI reviewer to a specific version or a floating tag?

For most teams, a floating major tag (like @v1) is best: you get fixes and improvements within the major version automatically, without breaking changes. Pin an exact semver only when you need fully reproducible CI and are willing to bump it manually.

Is pinning to @main a bad idea?

For production pipelines, usually yes — @main can change without a release, so your reviewer’s behavior can shift unexpectedly. It’s fine in a test repository where you want to preview upcoming changes, but most teams want the stability of a floating major or exact tag in their real workflows.

Why avoid old major versions like @v0?

Deprecated majors stop receiving fixes and tend to break as the surrounding ecosystem (runner images, dependencies, APIs) moves forward. Robin’s docs explicitly flag @v0 as “do not use.” Keep your major pin current and retire deprecated ones deliberately.

Where to Go From Here

Getting versioning right is a small decision with an outsized impact on how reliable your reviews stay. The Robin documentation lists the exact supported tags and the recommended pin, including the reusable-workflow reference. If you’re still choosing a reviewer to pin in the first place, the AI code review tools page maps the options. Once your pin policy is set, it’s one of those things you can leave alone for a long time — provided you didn’t pin to a deprecated major.