General: Pin GitHub Actions to commit SHAs instead of mutable tags - #2633
Open
az108 wants to merge 2 commits into
Open
General: Pin GitHub Actions to commit SHAs instead of mutable tags#2633az108 wants to merge 2 commits into
General: Pin GitHub Actions to commit SHAs instead of mutable tags#2633az108 wants to merge 2 commits into
Conversation
Every action was referenced by a version tag such as @v6. Tags are mutable and maintainers move them, so each workflow run could execute different code than the last with nothing recorded in the repository. Reference the commit SHA instead and keep the human-readable version in a trailing comment. The two ls1intum reusable workflows stay on @main: they are first-party and intended to track the organisation standard. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Up to standards ✅🟢 Issues
|
…ull requests SHA pins never drift, but they also never pick up fixes on their own, and nothing in the repository proposed those bumps. Dependabot understands the SHA plus version-comment convention and updates both, so action upgrades arrive as a reviewable weekly pull request rather than silently. Scoped to the github-actions ecosystem only. npm and Gradle stay on the existing manual dependency-update pull requests. Exempt Dependabot from the PR title check: its titles come from a template whose capitalisation is decided by its own heuristic, so the rule would fail on every generated pull request. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
|
There hasn't been any activity on this pull request recently. Therefore, this pull request has been automatically marked as stale and will be closed if no further activity occurs within seven days. Thank you for your contributions. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Checklist
General
Motivation and Context
We pin every npm and Gradle dependency to an exact version, so nothing in the application changes without a commit. CI was the exception: every action was referenced by a version tag such as
@v6or@v5.Tags are mutable. Maintainers routinely force-move a major tag onto new commits, which means a workflow run could execute different code than the previous run with nothing recorded in this repository, no review, and no way to tell from the diff. That is exactly the implicit auto-update we avoid everywhere else, and it applies to the steps that hold registry credentials and deploy keys.
It is also the standard supply-chain hardening step for Actions: a compromised or hijacked action repository can repoint a tag and immediately run in our pipelines.
Description
Replaced every mutable tag reference with the commit SHA it currently resolves to, keeping the human-readable version in a trailing comment so the file stays readable and reviewable:
Covers 21 references across 13 workflow files. No versions were changed — every SHA is the commit the tag already pointed at, so CI behaviour is identical.
Two references were already SHA-pinned; they only gained a version comment:
treosh/lighthouse-ci-action→# v12.6.2ashley-taylor/junit-report-annotations-action→# untagged master commit, 2023-02-22(no tag points at that commit)Deliberately left on
@main: the threels1intum/.github/...reusable workflows. Those are first-party and are meant to track the organisation standard, so pinning them would defeat their purpose.Keeping the pins current
Pinning trades one risk for another: SHAs never drift, but they also never pick up security fixes on their own, and nothing in the repository would propose those bumps. So this PR also adds
.github/dependabot.yml.Dependabot understands the
@<sha> # <version>convention and updates both the SHA and the comment, which is what makes SHA pinning sustainable rather than a slow drift into stale actions. Configured as:github-actionsecosystem only. npm and Gradle stay on the existing manual dependency-update PRs, so this adds no noise there.dependencies, and titled with the`General`:prefix so it matches our convention.One related change in
pr-check.yml: thevalidate-pr-titlejob now skips Dependabot. Its titles come from a template, and whether it writes "Bump" or "bump" is decided by its own heuristic, so the[A-Z]rule in our regex cannot be relied on and would fail every generated PR. The repo already exempts Dependabot from the JUnit annotation step, so this follows existing precedent. The rule is unchanged for human PRs.Steps for Testing
This is a CI-only change with no application impact; the PR's own checks exercise it.
Checkout) and confirm it resolves the pinned SHA.github-actionsecosystem as enabled and last-checked.Review Progress
Code Review
Manual Tests