Repository navigation
CI: resolve dependencies from the manifest, cache them, test the floor - #55
Merged
Merged
Conversation
CI pinned versions into composer.json before running the suite. `composer require --no-update` EDITS the file -- verified: `^13.0` becomes `13.*` -- so every run tested a manifest the package does not ship. Nothing broke, because the forced constraint happened to agree with the declared one; it would have broken silently the first time either changed, and widening a package to `^13.0 || ^14.0` would never have been tested at all. The matrix keys feeding those pins are gone with them. Several were already inert: `testbench` and `carbon` were declared in the matrix and referenced by no step, so they pinned nothing and always resolved from composer.json. Also here, all measured rather than assumed: - A composer cache. Most workflows re-downloaded every dependency on every run, which is the largest avoidable draw on the Actions budget. - The cache drops laranail/* archives before installing. Those resolve through a single MOVING v0.1.0 tag, so composer's dist cache is keyed on a name whose contents change underneath it -- without the eviction a restored archive is silently stale, which is the failure this org has already hit once. - fail-fast off where it was on. "8.5 fails too" and "only 8.5 fails" are different bugs, and fail-fast hides which one a run found. - No coverage driver where nothing consumed the report. pcov instruments every file on every run; generating a report nobody reads is time billed for nothing. Untouched wherever an upload or a --min gate uses it. - paths-ignore '*.md' -> '**.md'. The root-only glob never matched docs/**, so documentation-only changes ran the full suite.
The matrix only ever resolved prefer-stable, so nothing installed the minimum versions composer.json advertises. A floor can be wrong for months that way: the constraint says a consumer may use the old release, and no run ever proved it. Adding the leg is the only thing that checks the claim. Paired with --prefer-stable deliberately. Bare `composer update --prefer-lowest` resolves the lowest UNSTABLE release of every dependency, which fails for a reason that has nothing to do with this package. Verified on a scratch project: --prefer-lowest --prefer-stable installs psr/log 3.0.0 where plain --prefer-stable installs 3.0.2, and composer accepts the flag twice, so the one-line form needs no branch. Not applied where it would mean nothing: three packages install from a lock with `composer install`, where there is no resolution to steer, and tenancy-boilerplate is an application whose tracked lock is the point. Four packages already carry a single floor cell in `include`, which is the cheaper shape and is left alone.
laranail/.github has shipped a reusable tests workflow for months and one package of fifty-one called it. That is why a single defect -- pinning the Laravel version into composer.json before the suite ran -- had to be fixed in twenty-two places, and why prefer-lowest had to be added in twenty-seven. Everything this file used to spell out now lives in one definition: the PHP matrix, the composer cache and the laranail archive eviction it needs, the prefer-lowest leg, fail-fast, the timeout. What stays here is what is genuinely this package's own -- its PHP versions, its extensions, its test command -- passed as inputs. REQUIRES the corrected laranail/.github tests.yml. The version dated 2026-08-28 defaults laravel-versions to ["13.*"] and runs `composer require illuminate/contracts` before the suite, which is the pin this change exists to remove, and it has no laranail cache eviction, so adopting it unfixed would serve stale archives from the moving v0.1.0 tag. Land that first.
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.
Three changes, each measured across the family rather than assumed.
Resolve dependencies from the manifest. CI pinned versions into
composer.jsonbefore running the suite.composer require --no-updateedits the file — verified,^13.0becomes13.*— so every run tested a manifest the package does not ship. Nothing was broken today, because the forced constraint agreed with the declared one; it breaks silently the first time they diverge, and widening to^13.0 || ^14.0would never have been tested. The matrix keys that fed those pins are gone with them; several (testbench,carbon) were already inert, declared in the matrix and referenced by no step.Cache composer dependencies, with
laranail/*archives dropped before install. That eviction is not optional: those packages resolve through a single movingv0.1.0tag, so the dist cache is keyed on a name whose contents change underneath it, and a restored archive is silently stale.Test against the floor. The matrix only ever resolved
prefer-stable, so nothing installed the minimumcomposer.jsonadvertises. Paired with--prefer-stable, because bare--prefer-lowestresolves the lowest unstable release and fails for unrelated reasons.Where this branch also adopts
laranail/.github, it requires the corrected reusable workflow to land first — the current one defaultslaravel-versionsto["13.*"](the pin) and has no laranail cache eviction.