ci: pin build tooling to exact versions - #8442
Open
alexisLefebvre wants to merge 1 commit into
Open
Conversation
These tools are installed and executed on the runner, so an unconstrained version runs whatever the registry serves that day. Packagist freezes the reference of a published version, but not of a branch, so the documentation generator is pinned to a commit instead. Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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
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.
What
Every build tool the workflows install on the runner now has an exact version:
soyuka/pmu(21 sites),php-coveralls/php-coveralls(5 sites),laravel/installer,@redocly/cli(was@latest),@quobix/vacuum, andphp-documentation-generator. Project dependencies are untouched — the^8.4/^2.5/x-devconstraints in the test matrices are deliberate and stay as they are.The two versions used more than once live in
env:inci.yml; single-use versions are written inline where they are installed.php-documentation-generatorhas no usable tag — onlyv0.0.1and a beta, while the workflow relies onmain, which the project last pushed in September 2024. It is pinned to that branch's current commit rather than to a tag, so the installed code is fixed without changing which code runs.No pin resolves lower than what CI installs today:
pmudeclares no PHP constraint,php-coverallsaccepts^7.4 || ^8.0,laravel/installerneeds^8.2and its job runs PHP 8.5, and@redocly/cli2.43.3 wants node>=20.19.0 <21against that job'snode-version: '20'. Each Composer spec was resolved withcomposer require --dry-runin a throwawayCOMPOSER_HOMEto confirm it lands on the intended version, including thedev-main#<commit>form.Why
These tools are downloaded and executed on the runner, with the workflow's environment in reach. Unconstrained, they run whatever the registry serves on the day the job starts, so a single hijacked release lands in CI with no change on our side.
Packagist made published versions immutable in July 2026: once a stable version exists, its git reference is frozen and an upstream retag is rejected rather than followed. That makes an exact version genuinely exact, and it is why the documentation generator gets a commit instead — the immutability guarantee explicitly does not cover branch-tracking
dev-*versions, which keep moving with the branch.Worth knowing for review: no Dependabot ecosystem watches installs inside
run:steps, neithercomposer global requirenornpm install -g. These pins will only ever move when somebody moves them by hand.🤖 Generated with Claude Code