Internal actions/* references use floating tags, undermining SHA-pinned invocations

[Fanzzzd]

Problem

Pinning uses: alibaba/open-code-review@<commit> does not currently freeze what runs. In the v1.8.10 action, the internal actions use floating tags — actions/checkout@v7, actions/setup-node@v7, actions/upload-artifact@v4, actions/github-script@v9 — so the composite's implementation can change underneath a consumer's SHA pin without any change to their workflow. Consumers have no way to pin these references themselves, which makes the official action hard to use as a required review gate under SHA-pinning policies and encourages vendoring it.

Suggestion

• Pin the internal actions/* references to full commit SHAs with a # vX.Y.Z trailing comment.
• Show a fully SHA-pinned invocation in the GitHub Actions example.
• Add a consistency check so a floating tag cannot reappear in action.yml.

→ Implemented in #836.

---

Scope note: this issue originally also covered the ocr_version: latest default. That is a separate design decision with an active discussion, now tracked in #839 so this issue can close with the part already agreed.

[stay-foolish-forever]

Hi @Fanzzzd, thank you so much for the thoughtful analysis and for taking the time to write this up in such detail — this is exactly the kind of feedback that helps the project mature. You've clearly done your homework on the reproducibility story, and we really appreciate it.

On the internal actions/* references, we completely agree with you. Those are Action-internal implementation details that consumers have no way to pin themselves, so any SHA-pin of alibaba/open-code-review is genuinely undermined by them today. Moving them to full commit SHAs (ideally with a # vX.Y.Z trailing comment for readability), updating the README example to demonstrate a fully SHA-pinned invocation, and adding a release-time consistency check all sound right to us.

On the ocr_version default, we'd like to gently share a slightly different perspective and hear your thoughts. The Action already exposes ocr_version as an explicit input, so teams with strict supply-chain requirements can pin the CLI version today with with: ocr_version: 1.8.10. OCR is under active development, and most consumers rely on the default to pick up bug fixes and new detectors automatically. Flipping the default from latest to a release-aligned pin would mean many workflows silently stall on older CLI versions unless users remember to bump ocr_version on every release, which we're a little wary of. Our current thinking is to keep latest as the default and instead make the pinning path more discoverable in the README — for example an explicit "if you SHA-pin actions, please also pin ocr_version" note in a reproducibility section. That said, we're very open to being convinced otherwise if you see angles we're missing.

We'd very much welcome a PR from you to close this gap in the Action. You clearly have the full context, and it would land much faster in your hands than in ours. Feel free to open a draft PR whenever it's convenient, and we'll prioritize the review. Thanks again for caring enough about the project to raise this!

[Fanzzzd]

Hi @stay-foolish-forever — thanks for the reply and for inviting a PR.

Status today

The Action is an orchestrator; the CLI is installed separately:

npm install -g "@alibaba-group/open-code-review@${OCR_VERSION}"  # default: latest

Official path is effectively @main + nested actions/*@vN + ocr_version: latest. Pinning only the Action does not freeze review behavior.

Change	What unpinned callers see
Breaking Action change lands on main	Next run breaks; no tag to review
Nested actions/*@vN moves	Behavior changes under a trusted outer pin
npm latest ships a CLI break	Review fails or posts differently; Action SHA pin does not help
Need “same as last week”	Cannot reproduce

Strict mode today needs dual pin:

uses: alibaba/open-code-review@<full-sha>
with:
  ocr_version: 1.8.10

Examples from popular actions

Pattern	Examples
Exact tool version by default + nested full SHA	trivy-action (e.g. default v0.73.0; nested uses: …@<sha> # vX.Y.Z); latest is opt-in
Major float: patch/minor auto-follow, breaking needs new major	uses: …@v4; CodeQL recommends @v4
Semver constraint, not unbounded latest	goreleaser-action default ~> v2; golangci docs always set version: vX.Y
One pin locks wrapper + tool	checkov / scorecard / super-linter (exact image tag)
Default latest	more common for pure installers (setup-helm), weaker for a product runner

Suggestions

1. PR1 (as you welcomed): pin nested actions/* to full SHAs (# vX.Y.Z), README dual-pin example, release-time consistency check
2. Defaults: Action v1.8.10 → default ocr_version: 1.8.10; keep latest as explicit opt-in
3. Floating major @v1: compatible fixes auto-follow; breaking changes require @v2
4. Docs — three tiers: convenience (@main + latest), recommended (@v1 / release tag + aligned CLI), strict (Action SHA + exact ocr_version)

Happy to open PR1 first as scoped. Thanks again.

[Fanzzzd]

PR1 as scoped is up: #836 — nested actions/* pinned to full SHAs with # vX.Y.Z comments (each SHA cross-checked against its version tag), a verify-action-pins.sh consistency check wired into CI, and a "Reproducible pinning" section in the GitHub Actions example README documenting the dual pin. The ocr_version default question stays here as discussed.

[Fanzzzd]

Housekeeping: split the ocr_version default question out to #839 (with both positions from this thread summarized there), and narrowed this issue to the floating-tag gap we already agree on — so #836 can close it cleanly. The discussion on the default continues in #839.