The vips driver uses jcupitt/vips (FFI binding), which needs ext-ffi
plus the libvips shared library at runtime - not the PECL vips
extension. Add a libvips apt install step and enable ffi in both test
workflows, then switch .env.testing to vips so CI exercises the new
default driver.
Guard ImageThumbnailSupersedeTest to skip when the configured driver's
runtime is unavailable, so contributors without libvips are not blocked.
The org's allowed-actions policy blocks crowdin/github-action@v3
(third-party, not verified/allowlisted). Reimplement the same flow
using the official @crowdin/cli npm package plus the GitHub-native gh
CLI, both of which satisfy the policy:
- upload sources: crowdin upload sources
- download translations: crowdin download
- open/update PR: gh pr create against staging, only when translations
changed
Credentials continue to come from crowdin.yml (project_id_env /
api_token_env), so no config change is needed.
An empty 'branches: []' under push/pull_request does not disable a
trigger; GitHub treats it as no branch filter and runs on every ref.
Expose only workflow_dispatch so the experimental suite runs solely on
manual trigger.
- Set a unique REDIS_PREFIX per matrix entry so cache/queue keys never
collide (the config default derives the prefix from APP_NAME, which is
identical across entries).
- Point the MariaDB entry at the 'mariadb' connection instead of 'mysql'
so the MariaDB driver is actually exercised (Laravel 11 treats them as
distinct drivers).
docker/build-push-action attaches provenance (and SBOM) attestations as
extra manifests with an 'unknown/unknown' platform. These render as noisy
'unknown' entries in the GHCR package UI next to the real amd64/arm64
platforms. Set provenance: false and sbom: false so only the runnable
architecture manifests are pushed.
Applied to both the branch-image (docker-push) and release-tag
(docker-tag) workflows.
Runs the Pest suite against real MySQL 8.4, MariaDB 11.4, and PostgreSQL 16
services instead of the default in-memory SQLite, to surface DB-specific
behavior (strict mode, ONLY_FULL_GROUP_BY, unsigned underflow).
This is expected to fail currently, so every step uses continue-on-error
and the test command is suffixed with '|| true' to always report success.
Testing/investigation only; not a required check.
Psalm 6.5.0 fatally crashes on PHP 8.5 (deprecated SplObjectStorage::attach
escalated by its error handler) before analyzing anything. Pin the Psalm
job to 8.4 so it runs and produces SARIF; revert to 8.5 once Psalm supports
it.
Replace the blank-SARIF fallback with an existence check; uploading an
empty SARIF would clear existing Code Scanning alerts. Now the upload is
skipped (with a warning) when Psalm produced no report.
Add a fallback step that writes a minimal valid SARIF report when Psalm
exits before producing one, so the Code Scanning upload never hard-fails
the job. Bump github/codeql-action/upload-sarif v3 -> v4.
Rename psalm.yml to php-psalm.yml to match sibling workflows, bump PHP
8.4 -> 8.5, use the shared checkout/setup-php/cache/composer steps and
staging/dev/unstable triggers. Keeps report-only behavior and SARIF
Code Scanning upload.
Port PR #6646 onto staging: add psalm/plugin-laravel with psalm.xml,
a staging-generated baseline, and a CI workflow that emits GitHub
annotations and uploads SARIF to Code Scanning. Fix the psalm.xml schema
for Psalm 6.5 (drop unsupported ClassMustBeFinal handler) and ignore
generated report artifacts in git/docker.