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
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
46 lines
1.7 KiB
Markdown
46 lines
1.7 KiB
Markdown
# CI
|
|
|
|
CI and release jobs do not install PHP. They run inside the shared images
|
|
maintained in [Unsupervised/ci-php](https://git.unsupervised.ca/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/cache` — `COMPOSER_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.
|