Fold PHPCS and PHPStan into one job #179

Merged

thatguygriff merged 6 commits from ci/consolidate-quality-job-and-php-85 into main 2026-08-20 18:55:17 +00:00

Conversation 0 Commits 6 Files Changed 1

+8 -25

thatguygriff commented 2026-08-20 17:30:08 +00:00

Owner

Copy Link

Copy Source

Coding Standards and PHPStan were identical up to their final step, and each paid for its own Setup PHP. That step is the slow, flaky one (#178), so running it twice to reach two short commands was two chances for a run to fall over rather than one. They are now steps in a single Coding Standards & Static Analysis job, and build's needs is updated to match.

The tradeoff: PHPCS failing now stops the job before PHPStan reports, where before the two ran in parallel and both spoke. That seems fair for halving the exposure — fixing a PHPCS failure rarely depends on knowing PHPStan's verdict at the same moment. Easy to revisit if it grates.

Verified in run 526: the consolidated job succeeded.

PHP 8.5 was here and has been held back

8.5 lands on setup-php's php-builder path, same as 8.3, so it pays for ~70 apt -dev packages every run. It timed out in run 526 and passed in 527 on identical code. Merging it would mean intermittent red for a version nothing ships on yet, so it is out until #178 is fixed.

The code itself is fine on 8.5 — verified locally on 8.5.9: 915 tests, PHPStan and PHPCS clean, check-platform-reqs satisfied. It is purely a runner problem. The commit is in this branch's history as bc046ec when the matrix is cheap again.

Tests

• composer test — 915 tests, 2592 assertions, OK
• composer lint — no errors
• composer cs — clean

No changelog entry: CI-only, nothing user-visible.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

`Coding Standards` and `PHPStan` were identical up to their final step, and each paid for its own `Setup PHP`. That step is the slow, flaky one (#178), so running it twice to reach two short commands was two chances for a run to fall over rather than one. They are now steps in a single `Coding Standards & Static Analysis` job, and `build`'s `needs` is updated to match. The tradeoff: PHPCS failing now stops the job before PHPStan reports, where before the two ran in parallel and both spoke. That seems fair for halving the exposure — fixing a PHPCS failure rarely depends on knowing PHPStan's verdict at the same moment. Easy to revisit if it grates. Verified in run 526: the consolidated job succeeded. ## PHP 8.5 was here and has been held back 8.5 lands on setup-php's php-builder path, same as 8.3, so it pays for ~70 apt `-dev` packages every run. It timed out in run 526 and passed in 527 on identical code. Merging it would mean intermittent red for a version nothing ships on yet, so it is out until #178 is fixed. The code itself is fine on 8.5 — verified locally on 8.5.9: 915 tests, PHPStan and PHPCS clean, `check-platform-reqs` satisfied. It is purely a runner problem. The commit is in this branch's history as `bc046ec` when the matrix is cheap again. ## Tests - `composer test` — 915 tests, 2592 assertions, OK - `composer lint` — no errors - `composer cs` — clean No changelog entry: CI-only, nothing user-visible. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff added 1 commit 2026-08-20 17:30:09 +00:00

Fold PHPCS and PHPStan into one job and test PHP 8.5 ... bc046ec2a1

The two jobs were identical up to their final step, each paying for its own
Setup PHP. That step is the flaky one (#178), so running it twice to reach
two short commands was two chances for a run to fall over instead of one.
They are now steps in a single Coding Standards & Static Analysis job.

The one thing given up is that PHPCS failing now stops the job before
PHPStan reports, where before the two ran in parallel and both spoke. That
seemed a fair trade for halving the exposure, and the fix for a PHPCS
failure rarely depends on knowing PHPStan's verdict at the same time.

PHP 8.5 joins the test matrix. composer.json already allows it at >=8.1
and the suite passes on 8.5.9 locally: 915 tests, PHPStan and PHPCS clean,
check-platform-reqs satisfied. 8.4 is deliberately not added, only 8.5.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff referenced this pull request 2026-08-20 17:38:10 +00:00

CI: Setup PHP is slow and flaky for PHP 8.3 only, on arm64 runners #178

thatguygriff added 1 commit 2026-08-20 17:44:58 +00:00

Cache the .debs php-builder installs, to measure whether it helps ... 85c7a01939

Experiment for #178. On self-hosted runners setup-php installs PHP 8.3+
through php-builder, whose install.sh apt-installs ~70 -dev packages
before unpacking the build. The build tarball itself is only 19MB, so
that apt work is the whole cost, not the download.

Ubuntu's image drops the .debs after install, so every job fetches them
from the archive again. This keeps them and restores them through the
cache server, which lives in the cluster, so a WAN download becomes a
local one. The dependency list does not vary by PHP version, so a single
key serves 8.3 and 8.5 and the quality and build jobs alike.

Only the .debs are cached. /var/lib/apt/lists is deliberately left alone,
since a stale index is how apt starts 404ing mid-install, and reducing
flakiness is the entire point.

The Report restored .debs step is temporary instrumentation to show
whether the cache is actually being read. Baseline to beat, from run 526:
8.1 30s, 8.2 53s, 8.3 454s, quality 151s, 8.5 733s and a hard failure.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff added 1 commit 2026-08-20 17:59:49 +00:00

Revert the apt cache experiment: the cache service is switched off ... dd31afcd06

Measured on run 527 and it cannot work. Every actions/cache step on these
runners prints

  Cache action is only supported on GHES version >= 3.5 ... check with
  GHES admin if Actions cache service is enabled or not

and then no-ops. The save step finishes in 0.19-0.31s, which is not a
few hundred megabytes of .debs going anywhere. setup-php timings were
unchanged against the run 526 baseline, within the usual variance:
8.3 454s then 148s, 8.5 733s then 446s, both noise rather than signal.

The same warning appears on the Composer cache this workflow has carried
all along, including run 523 and earlier, so that step has never cached
anything either. Worth fixing, but in the runner config rather than here.

Leaving dead steps in the workflow is how the Composer cache went years
without anyone noticing it did nothing, so the experiment comes out until
act_runner has its cache service enabled. It is in the history when that
happens. Detail in #178.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff referenced this pull request 2026-08-20 18:00:27 +00:00

CI: Setup PHP is slow and flaky for PHP 8.3 only, on arm64 runners #178

thatguygriff added 1 commit 2026-08-20 18:04:34 +00:00

Retry the apt cache on actions/cache@v4 ... d5eb2764a3

My last conclusion was wrong. The GHES warning is not evidence that the
runner has no cache server; it is actions/cache v3 disabling itself.
v3's isGhes() reads GITHUB_SERVER_URL, and anything that is not
github.com reads as GitHub Enterprise, so on Gitea it always trips and
the action returns before touching the cache. That explains the 0.2s
save perfectly well without any runner setting being off.

Gitea's runner 3.0.0 release notes say every runner starts its own cache
server and that the runner "patches action bundles at load time to open
the GHES gate and read the cache endpoint from ACTIONS_CACHE_URL", with
actions/cache supported unforked. Our runners report v3.0.0, so the
server should be there and the gate should be open — but the patching
evidently does not reach a v3 bundle.

So this reapplies the apt cache and moves every actions/cache to v4. If
the hypothesis holds the GHES warning disappears, the save step actually
takes time, and a second run restores the .debs. The Composer cache gets
the bump too, since it has been silently doing nothing for the same
reason.

Refs #178.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff added 1 commit 2026-08-20 18:08:04 +00:00

Revert the v4 cache retry: the gate stays shut, so it is the runner ... 43b903c1c8

Tested and the hypothesis is dead. actions/cache@v4 resolved properly
(SHA 0057852) and printed the same GHES warning as v3, so the action
version was not what was closing the gate.

That points at the runner rather than the action. Gitea's docs say the
runner patches the GHES check out of the action's bundle only when it
recognises it, and that a bundle it does not recognise "is left alone".
No patching for either v3 or v4, and no ACTIONS_CACHE_URL to patch it
towards, is what you get when cache is simply off in the runner config.

So the fix is cache.enabled in act_runner's config.yaml, with host set to
an address job containers can reach. Nothing in this repository unblocks
it, and inert steps are what let the Composer cache rot unnoticed, so the
experiment comes out again. Both halves — the apt cache and the move to
v4 — should land together once the runner serves a cache.

Refs #178.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff referenced this pull request 2026-08-20 18:08:46 +00:00

CI: Setup PHP is slow and flaky for PHP 8.3 only, on arm64 runners #178

thatguygriff referenced this pull request 2026-08-20 18:14:05 +00:00

Probe what cache endpoint the runner exports #180

thatguygriff referenced this pull request 2026-08-20 18:19:33 +00:00

CI: Setup PHP is slow and flaky for PHP 8.3 only, on arm64 runners #178

thatguygriff added 1 commit 2026-08-20 18:33:05 +00:00

Hold PHP 8.5 until the runner serves a cache ... f6481d4a3f

8.5 lands on setup-php's php-builder path, same as 8.3, so it pays for
~70 apt -dev packages on every run. It timed out in run 526 and passed in
527 on identical code, which is a coin toss, and merging it would mean
intermittent red for a version nothing ships on yet.

The code is fine on 8.5 — verified locally on 8.5.9: 915 tests, PHPStan
and PHPCS clean, check-platform-reqs satisfied. This is purely about the
runners, so 8.5 comes back once #178 is fixed and the matrix is cheap
again. This PR is now just the PHPCS/PHPStan consolidation.

Refs #178.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks

thatguygriff changed title from Fold PHPCS and PHPStan into one job and test PHP 8.5 to Fold PHPCS and PHPStan into one job 2026-08-20 18:33:19 +00:00

thatguygriff referenced this pull request 2026-08-20 18:49:22 +00:00

Cache the packages php-builder installs, and restore PHP 8.5 #181

thatguygriff merged commit 7f10769330 into main 2026-08-20 18:55:17 +00:00

thatguygriff deleted branch ci/consolidate-quality-job-and-php-85 2026-08-20 18:55:17 +00:00

thatguygriff referenced this issue from a commit 2026-08-20 19:04:55 +00:00

Put PHP 8.5 back in the matrix

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

Clear labels

bug

Something isn't working

enhancement

Extends an existing feature

feature

New user-facing capability

payments

Billing, Stripe, receipts, reporting

security

Security vulnerability or hardening

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

Kydoimos (Kydoimos) thatguygriff (James Griffin-Allwood)

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Unsupervised/unsupervised-scheduler#179