ci: standardize actions/checkout to v5 across all workflows#623
ci: standardize actions/checkout to v5 across all workflows#623Devansh-567 wants to merge 2 commits into
Conversation
Signed-off-by: Devansh-567 <devansh.jay.singh@gmail.com>
| name: Validate that all files have copyright and license info | ||
| steps: | ||
| - uses: actions/checkout@v6 | ||
| - uses: actions/checkout@v5 |
There was a problem hiding this comment.
Could you explain why you are downgrading this from v6 --> v5? Are there any downgrade implications? I assume it's just for consistency
There was a problem hiding this comment.
Could you explain why you are downgrading this from v6 --> v5? Are there any downgrade implications? I assume it's just for consistency
Yes 😊, this is purely for consistency, not because v6 has a known issue.
On downgrade implications: I checked the actions/checkout release notes between v5 and v6, and there's no breaking change or behavior difference relevant to this workflow's verify-licenses job (it's a straightforward checkout, no special inputs like persist-credentials, sparse-checkout, or ref handling that changed between versions). So functionally this job will behave identically on v5.
The reasoning for picking v5 as the repo-wide standard rather than bumping everything to v6 (or v7):
v5 is already proven in this repo (rust-build.yml, google-rpc-status-synced.yml use it today), so standardizing on it means every workflow converges on a version that's already known to work here, rather than introducing a new version through this PR.
v6/v7 aren't broken or risky, but since none of the workflows need anything from those newer releases, there was no upside to bumping up to v6 across the board versus consolidating down to the version already validated in-repo.
There was a problem hiding this comment.
Can we make all the workflow versions go to v6 instead? I feel like a downgrade isn't necessary if v6 isn't risky
There was a problem hiding this comment.
Agreed that it seems a bit odd to intentionally downgrade the version already in use by a prominent part of the CI checks for the repo.
There was a problem hiding this comment.
So if we are going to the trouble to update some of the Github action versions, is there a reason to avoid upgrading them all to v6 while we are at it? Maybe that will not work for some reason, but I am curious to know.
There was a problem hiding this comment.
+1, why are we not upgrading to v6 for all of them. Similarly, the PR description and title no longer match what is happening in this PR if one is v6
Signed-off-by: Devansh Singh <devansh.jay.singh@gmail.com>
3 participants
Summary
This repo's GitHub Actions workflows pinned
actions/checkoutto several different major versions inconsistently:@v3-any-branch-uploads.yml,main-branch-uploads.yml,tag-uploads.yml(x2),codegen.yml,spec.yml(asciidoc-lint, build-spec jobs)@v4-bazel-build.yml@v5-rust-build.yml,google-rpc-status-synced.yml@v6-spec.yml(verify-licenses job)This PR standardizes all
actions/checkoutreferences to a single version:@v5.Why v5
rust-build.yml,google-rpc-status-synced.yml), so it's a proven baseline rather than an untested jump.v7(GA'd June 17, 2026), which introduces new default behavior forpull_request_target/workflow_runcheckouts. None of this repo's workflows use those triggers, so it wouldn't have caused issues either way, butv5avoids being an early adopter of a days-old major version in CI.Changes
Purely mechanical version bumps, no other changes:
any-branch-uploads.yml:v3->v5bazel-build.yml:v4->v5codegen.yml:v3->v5main-branch-uploads.yml:v3->v5spec.yml:v6->v5(verify-licenses),v3->v5(asciidoc-lint),v3->v5(build-spec)tag-uploads.yml:v3->v5(x2)rust-build.ymlandgoogle-rpc-status-synced.ymlare unchanged as they already usedv5.