Description
Workflow files likely reference actions like actions/checkout@v4 by floating tag. Pinning to a specific commit SHA (with a comment noting the version) is a supply-chain hardening best practice that prevents a compromised or force-pushed tag from silently changing CI behavior.
This is part of the CI/CD configuration under .github/workflows/, the automated gate that enforces every other guarantee this project claims to have, from ABI/contract consistency to documentation linting to coverage reporting. CONTRIBUTING.md lists specific required status checks that every PR must pass before merging, which means a gap in CI configuration doesn't just fail to catch a class of bug, it actively lets that class of bug merge to main with a green checkmark that reviewers reasonably trust.
Because CI is the one piece of the project every single contributor interacts with on every single PR, inefficiencies or blind spots here have an outsized multiplier effect: a slow or overly broad workflow wastes a small amount of time on every PR forever, and a missing check is a permanently open door for exactly the class of regression it should have caught.
Requirements and context
Suggested execution
- Fork the repo and create a branch
git checkout -b chore/pin-github-actions-sha
- Implement changes
- Update every workflow file under
.github/workflows/
- Test and commit
- Confirm CI still passes on a test branch after pinning
Example commit message
chore: pin GitHub Actions to commit SHAs
Guidelines
- Assignment required before starting
- PR description must include:
Closes #[issue_id]
- Keep PR description professional and detailed
Description
Workflow files likely reference actions like
actions/checkout@v4by floating tag. Pinning to a specific commit SHA (with a comment noting the version) is a supply-chain hardening best practice that prevents a compromised or force-pushed tag from silently changing CI behavior.This is part of the CI/CD configuration under
.github/workflows/, the automated gate that enforces every other guarantee this project claims to have, from ABI/contract consistency to documentation linting to coverage reporting.CONTRIBUTING.mdlists specific required status checks that every PR must pass before merging, which means a gap in CI configuration doesn't just fail to catch a class of bug, it actively lets that class of bug merge tomainwith a green checkmark that reviewers reasonably trust.Because CI is the one piece of the project every single contributor interacts with on every single PR, inefficiencies or blind spots here have an outsized multiplier effect: a slow or overly broad workflow wastes a small amount of time on every PR forever, and a missing check is a permanently open door for exactly the class of regression it should have caught.
Requirements and context
@vNtags with the corresponding commit SHA across.github/workflows/*.ymlSuggested execution
.github/workflows/Example commit message
chore: pin GitHub Actions to commit SHAsGuidelines
Closes #[issue_id]