Files
unsupervised-scheduler/docs/ci.md
T
thatguygriffandClaude Opus 5 1552bf4b5f
CI / Coding Standards (pull_request) Successful in 14s
CI / Tests (PHP 8.1) (pull_request) Successful in 30s
CI / Tests (PHP 8.2) (pull_request) Successful in 30s
CI / Tests (PHP 8.3) (pull_request) Successful in 29s
CI / No Debug Code (pull_request) Successful in 3s
CI / Tests (PHP 8.5) (pull_request) Successful in 21s
CI / Static Analysis (pull_request) Successful in 37s
CI / Build Plugin Zip (pull_request) Skipped
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

1.7 KiB

CI

CI and release jobs do not install PHP. They run inside the shared images maintained in Unsupervised/ci-php:

git.unsupervised.ca/unsupervised/ci-php:8.1
git.unsupervised.ca/unsupervised/ci-php:8.2
git.unsupervised.ca/unsupervised/ci-php:8.3
git.unsupervised.ca/unsupervised/ci-php:8.5

The Unsupervised org is public, so they pull anonymously — no registry credentials in any job here. What the images contain, how they are published, and how to add a PHP version are documented in that repository's README.

Which job runs where

Job Runs in
Coding Standards (PHPCS) ci-php:8.3
Static Analysis (PHPStan) ci-php:8.3
Tests ci-php:${{ matrix.php }}
Build Plugin Zip ci-php:8.3
No Debug Code runner image — no PHP, and it uses GNU grep --include
Open next-version bump PR (release.yml) runner image — no PHP

PHPCS and PHPStan are separate jobs so a coding-standards failure still lets the static analysis result through. They run in parallel.

Composer

composer.lock is committed, so every job installs the same dependency set and two builds of the same tag ship the same vendor tree. bin/build-zip.sh stages the lock into its build directory for the same reason, then removes it before writing the zip.

The Composer download cache lives at /composer/cacheCOMPOSER_HOME is /composer in the image — and is keyed on composer.lock.

Adding a PHP version to the test matrix

The image has to exist first. Add the version to the php matrix in ci-php's .gitea/workflows/publish.yml and merge, then add it to the test matrix in .gitea/workflows/ci.yml here.