Run make tests + make phpstan with the turbo extension inside docker-library PHP images - #6182
Merged
Conversation
…library PHP images The docker-library php images build the official tarballs without regenerating the parser, so their runtime can differ from the builds the .so artifacts are compiled against — the T_* token-numbering split (phpstan/phpstan#15037) being the canonical incident. The turbo-token-numbering probes verified exactly that one failure mode; the next incompatibility of this kind will not announce itself in a probe written for the last one. Replace the probe job with turbo-docker-run: load the freshly built extension into docker-library images — 8.3.21/8.3.22 pinned (one release of each known bison numbering), 8.4/8.5 floating on the minor tag so future patch releases are picked up automatically — and run the same make tests + make phpstan as turbo-run. Verified against the pre-fix token bug: 2462 of 21065 tests fail and self-analysis crashes on the Bison 3.0.4 image, both green on the matched one and with the fixed extension. The token-id probe stays as a fast-fail first step for the one-line diagnosis. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EpvCn4kVHSaS5aaiaaRhEm
…dropping parses A run with the turbo comment-loss bug (phpstan/phpstan#15037) cached PHPDoc-less name-scope maps under ftm- keys. The entries validate only by file content hashes and the phpdoc-parser version, so an upgrade to the fixed extension keeps trusting them — analysis stays broken (missing generics, mass false positives) until the tmpDir is wiped by hand, and clear-result-cache does not help. Rotate the variable cache key to v6 so every installation rebuilds the maps once. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EpvCn4kVHSaS5aaiaaRhEm
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.
Follow-up to #6180. The token-numbering probes added there verified exactly one failure mode; this generalizes the CI so the next docker-library incompatibility is caught without anyone writing a probe for it first — and fixes a nasty persistence the bug left behind in user caches.
Verified: the general path catches the bug
With the pre-fix extension (built from
b184aaecac, compiled against a Bison-3.8.2-numbered PHP), inside docker-library images:php:8.3.21(matched numbering)php:8.3.22(Bison 3.0.4)make phpstanWith the fixed extension, all legs are green, including
php:8.3.22,php:8.4.24andphp:8.5.9.Workflow change
turbo-token-numberingis replaced byturbo-docker-run: each leg loads the freshly built gnu-x86_64.sointo a docker-library image and runsmake phpstanor the paratest suite (mirroringturbo-run, which covers the same scripts on setup-php builds). The 8.3 images are pinned to one release of each known bison numbering; 8.4/8.5 float on the minor tag on purpose, so a future patch release with a surprising build is tested on the next run without a workflow change. The token-id probe stays as a fast-fail first step — a numbering mismatch names itself in one line instead of thousands of test failures.Environment specifics baked into the job, all hit while reproducing locally:
--shm-size=1g(the arena SIGBUSes a parallel worker at docker's default 64M/dev/shm),memory_limit=-1via a bind-mounted conf.d ini (the images ship no php.ini and the 128M default kills the test bootstrap), vendor installed on the runner host and paratest invoked directly (the images carry neither composer nor unzip).FileTypeMapper cache-key bump (v5 → v6)
While reproducing, it turned out one broken run persistently poisons the analysis cache:
FileTypeMappercaches per-file resolved-PHPDoc name-scope maps validated only by file content hashes and the phpdoc-parser version. A comment-dropping parse writes well-formed but PHPDoc-less maps — and since the file contents didn't change, every later run trusts them: verified locally, a healthy run on the same tree fails identically after one poisoned run, across PHP patch versions, withclear-result-cachepowerless (fingerprint: "class Fiber is not generic" — stub generics resolve through the stub file's ftm entry). The affected releases and 2.2.x-dev share phpdoc-parser 2.3.3, so upgrading to the fixed extension would keep the poison, including for users who worked around the bug withPHPSTAN_TURBO=0after one broken run. Rotating the key tov6-rebuilds the maps once for everyone.🤖 Generated with Claude Code
https://claude.ai/code/session_01EpvCn4kVHSaS5aaiaaRhEm