20 Commits

Include renames

Author	SHA1	Message	Date
thatguygriffandClaude Opus 5	1552bf4b5f	Move the CI image definitions to the shared ci-php repository ... The image definition and its publishing workflow were only here because this was the first project to need them. They are project-agnostic, so they now live in Unsupervised/ci-php and any PHP project can consume the same tags. The registry path is unchanged — Gitea container images are named owner/image, not after the repository that pushes them — so nothing here needs repointing. Split the combined quality job into separate phpcs and phpstan jobs. They were folded together to halve the number of toolchain installs per run; with the toolchain in the image that saves nothing, and separating them means a coding-standards failure no longer hides the static analysis result. Rewrite the workflow comments to describe what the jobs do rather than the setup step they replaced, and cut docs/ci.md down to what is specific to this project — the image contents and publishing are documented in ci-php. Closes #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:39:08 -03:00
thatguygriffandClaude Opus 5	c9d18fec74	Commit composer.lock so CI and releases install a fixed dependency set ... composer.lock was gitignored, so `composer install` resolved the graph afresh on every job. CI could quietly start testing different dependency versions than it did the day before, and two builds of the same tag could ship different vendor trees — the run that produces the zip is the same run that picks the versions. Track the lock, and make the two places that consume it use it: - the Composer cache keys hash composer.lock rather than composer.json, since the lock is now what actually fingerprints the dependency set; - bin/build-zip.sh stages the lock alongside composer.json, so the --no-dev production install resolves to the locked versions. It already deleted both from the staging directory before zipping, so the shipped plugin is unchanged. The current lock installs cleanly on 8.1: nothing in it requires a PHP newer than the >=8.1 composer.json declares. Closes #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:33:04 -03:00
thatguygriffandClaude Opus 5	ab609898d6	Run CI and release jobs inside the prebuilt CI images ... Replaces setup-php with `container:` in every job that needs PHP. The images published by ci-images.yml already carry PHP, Composer, the intl and zip extensions and the CLI tools the workflow scripts shell out to, so nothing installs PHP at job time any more. That removes the apt path #178 was about: a ~145s floor on 8.3 against ~35s on 8.1/8.2, with a tail that twice ran past the step timeout and failed the run. All three copies of the `Keep downloaded .debs` / `Cache apt packages` workaround go with it. no-debug and bump-version stay on the runner image — neither needs PHP, and no-debug wants the runner's GNU `grep --include`. The Composer cache moves to /composer/cache, which is COMPOSER_HOME in the image, and release.yml gains the cache step it never had. Also corrects the image size in docs/ci.md to the 67MB measured from the published manifest; the ~120MB in the original was an estimate. Closes #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:25:02 -03:00
thatguygriffandClaude Opus 5	37c8d2b39e	Put PHP 8.5 back in the matrix ... I misread the instruction to hold 8.5 as "take it out until the cache lands" and removed it in f6481d4, so #179 merged without it. It was meant to stay where it was. Restoring it. 8.5 takes the same php-builder path as 8.3, so the apt cache in this branch is exactly what it needs, and the per-version key means it caches its own ~70 -dev packages rather than sharing with the ondrej-path jobs. composer test passes on 8.5.9 locally: 915 tests, 2592 assertions. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 16:04:52 -03:00
thatguygriffandClaude Opus 5	a90e06ae70	Key the apt cache per PHP version and drop the instrumentation ... Run 536 proved the cache works -- ACTIONS_CACHE_URL is now populated, no GHES warning, "Cache saved with key: apt-php-builder-deps-ARM64-v1" -- and in doing so showed the key was wrong. The jobs that saved it were 8.1 and 8.2. They take the ondrej PPA path, a handful of runtime packages, while 8.3 takes php-builder and its ~70 -dev packages. One shared key therefore lets whichever job finishes first decide what every other job restores, and 8.1 is always first, at ~30s against 8.3's several minutes. 8.3 would have restored a few runtime .debs it has no use for and then downloaded all 70 anyway. My "the dep list is the same for every PHP version" comment was true only among the builder versions. Keyed per version now, so each path caches what it actually installs. That also picks up a small win on 8.1 and 8.2 rather than only avoiding harm. Both temporary steps are gone. Report restored .debs was there to show the cache URL arriving and the restore landing; both are established, so it goes. Keep downloaded .debs stays -- it is not instrumentation, it disables Ubuntu's docker-clean, without which there are no .debs left to cache. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 15:57:27 -03:00
thatguygriffandClaude Opus 5	d5f6ebf0b5	Move actions/cache to v4 and probe the cache URL ... thatguygriff/infra#1 turned the runner cache server on, so actions/cache has an endpoint for the first time. v4 rather than v3 because v4.2+ can speak the cache service v2 API, which is what the runner serves. The instrumentation step now also prints ACTIONS_CACHE_URL, so a single run shows the endpoint arriving and the cache being read in one log rather than needing a separate probe. Refs #178. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 15:56:37 -03:00
thatguygriffandClaude Opus 5	4b4b2453ae	Cache the .debs php-builder installs, to measure whether it helps ... 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	2026-08-20 15:56:37 -03:00
thatguygriffandClaude Opus 5	f6481d4a3f	Hold PHP 8.5 until the runner serves a cache ... 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	2026-08-20 15:33:03 -03:00
thatguygriffandClaude Opus 5	43b903c1c8	Revert the v4 cache retry: the gate stays shut, so it is the runner ... 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	2026-08-20 15:07:18 -03:00
thatguygriffandClaude Opus 5	d5eb2764a3	Retry the apt cache on actions/cache@v4 ... 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	2026-08-20 15:04:33 -03:00
thatguygriffandClaude Opus 5	dd31afcd06	Revert the apt cache experiment: the cache service is switched off ... 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	2026-08-20 14:59:39 -03:00
thatguygriffandClaude Opus 5	85c7a01939	Cache the .debs php-builder installs, to measure whether it helps ... 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	2026-08-20 14:44:54 -03:00
thatguygriffandClaude Opus 5	bc046ec2a1	Fold PHPCS and PHPStan into one job and test PHP 8.5 ... 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	2026-08-20 14:29:30 -03:00
thatguygriffandClaude Opus 5	9071a3f70f	Stop authenticating setup-php against the GitHub API ... The GitHub API rate limit was the wrong diagnosis, so this reverts the 1Password-backed token added in #175 along with the mirrored composite action, leaving the workflows as they were. Timing every Setup PHP step across runs 454-523 rules the rate limit out. PHP 8.1 and 8.2 install in 26-41 seconds, 12 for 12, never once failing. PHP 8.3 has never finished in under 143 seconds and ranges up to 1273, with two outright failures. Those jobs share a fan-out, and so an egress address and a rate limit bucket, with the 8.1 and 8.2 jobs that are never touched. A throttle could not sort itself by PHP version that way. Run 523, the first to carry the token, is the direct refutation: the token resolved and verified, and Setup PHP still took 749 seconds on kallone and 408 on eris. The 8.3 penalty also predates the whole story, sitting at ~145 seconds back on 30 July. What is left is a slow path specific to 8.3 on these arm64 runners, whose long tail sometimes crosses the step timeout and reports the unhelpful "Could not setup PHP 8.3". That is worth fixing on its own terms rather than behind a token that was never in the path. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01Uw545F1vveNJKjzLxdi2ks	2026-08-20 14:22:52 -03:00
thatguygriffandClaude Opus 5	1291af0b72	Authenticate setup-php against the GitHub API ... setup-php resolves its tools through the GitHub API, unauthenticated at 60 requests an hour per source address. A CI fan-out across the fleet exhausts that bucket, and the step then retries for several minutes before reporting only "Could not setup PHP 8.3". It reads as a hang rather than a throttle, and it took out both a main CI run and a release build. Each cluster has its own egress address and so its own bucket, which is why the same job passed on one runner and failed on another in the same minute. The token comes from 1Password through the Connect instance in whichever cluster picked up the job, matching the pattern in thatguygriff/infra. That repository's composite action is not reachable from here, so it is mirrored locally. It stays a step output rather than being exported to the job environment, to keep it away from the package scripts composer install runs. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_0133tYSQoZhoKebKZV8o2GPs	2026-08-20 13:27:22 -03:00
thatguygriffandClaude Fable 5	dbf61e8593	Word-bound the no-debug CI grep so method calls like ->add() don't match dd( ... The unanchored dd\( pattern matched the substring in DateTimeImmutable::add(), failing the check on non-debug code. Co-Authored-By: Claude Fable 5 <[email protected]>	2026-07-05 16:12:37 -03:00
thatguygriffandClaude Opus 4.8	2011319750	Fix CI artifact so the downloaded plugin installs directly ... Gitea/Actions re-zips artifacts on download, so uploading the built plugin zip produced a double-wrapped archive (a zip containing a zip). WordPress then reported "No valid plugins were found" because the upload had no plugin folder/header at its top level. Unpack the built zip and upload the resulting plugin folder instead, so the downloaded artifact's top level is unsupervised-schedular/ and installs directly via Plugins -> Add New -> Upload. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-05 12:31:29 -03:00
thatguygriffandClaude Opus 4.8	e9d6c189bc	Add plugin zip build task and CI release artifact ... - bin/build-zip.sh + `composer build`: stage runtime files only, generate a production (no-dev) optimized autoloader, and emit dist/<slug>-<version>.zip with a single top-level plugin folder, ready to upload via wp-admin. Tests, tooling configs, docs, and dev dependencies are excluded; version is read from the plugin header. - CI `build` job: on push to main (post-merge), after lint/static-analysis/ test/no-debug pass, runs the build and uploads the zip via actions/upload-artifact. - Ignore build/ and dist/. Co-Authored-By: Claude Opus 4.8 <[email protected]>	2026-06-05 11:44:53 -03:00
thatguygriffandClaude Sonnet 4.6	ed49924f95	Fix all PHPCS coding standards violations ... - Add phpcs.xml.dist: excludes PSR-4 file naming, camelCase naming, short array syntax, and redundant per-method/property docblocks - Fix wp_unslash() on all $_POST reads (LoginPage, AvailabilityController) - Add phpcs:ignore for password field (must not be sanitized) - Fix Yoda conditions throughout (AvailabilityRepository, AvailabilityEndpoint, BookingEndpoint, AvailabilityController) - Fix inline comments to end with full stops (AdminMenu) - Replace short ternary ?: with explicit full ternary (BookingEndpoint) - Rename $namespace param to $route_namespace (reserved keyword warning) - Add short descriptions to doc blocks that had tag-only blocks - Add nonce suppression comment in handleFormAction (nonce verified by caller) - Update composer.json and CI to use phpcs.xml.dist Co-Authored-By: Claude Sonnet 4.6 <[email protected]>	2026-03-30 16:20:49 -03:00
thatguygriffandClaude Sonnet 4.6	0fbafc9d18	Initial plugin scaffold: lesson scheduling WordPress plugin ... - Custom DB tables for availability slots and lesson bookings - Instructor (wp-admin) and student (front-end) roles with custom capabilities - REST API under us-scheduler/v1 for availability CRUD and booking - [us_booking] and [us_student_login] shortcodes for student front end - PHPUnit + Brain\Monkey unit test suite (29 tests) - Gitea Actions CI: lint, PHPStan, tests on PHP 8.1/8.2/8.3, no-debug check - Feature docs under docs/features/ Co-Authored-By: Claude Sonnet 4.6 <[email protected]>	2026-03-30 12:44:46 -03:00