v0.4.1 e2e patch: --no-audit does not bypass Composer block-insecure

[apermo]

Summary

The patch added in v0.4.1 (fix(e2e): patch wp-env for Composer 2.8 advisory, #23) does not fix the wp-env image build. The PKSA-5jz8-6tcw-pbk4 / PKSA-z3gr-8qht-p93v advisories still block the composer global require phpunit/phpunit step inside the wp-env Dockerfiles, so e2e consumers remain red.

Root cause

The patch rewrites the composer command to:

RUN COMPOSER_NO_AUDIT=1 composer global require --no-audit --dev phpunit/phpunit:"..."

COMPOSER_NO_AUDIT / --no-audit only skip the post-install audit. The advisory block is enforced by a separate setting, audit.block-insecure, during dependency resolution — which runs before any audit. Composer's own error output points at the correct toggle:

To ignore the advisories, add them to the audit "ignore" config. To turn the feature off entirely, you can set "block-insecure" to false in your "audit" config.

Reproduction

Any consumer pinned to reusable-wp-e2e.yml@v0.4.1. Example job (site-bookkeeper-dashboard PR #22, commit 082caad):

https://github.com/apermo/site-bookkeeper-dashboard/actions/runs/24599790524/job/71936418275

Relevant excerpt:

> [cli 14/14] RUN composer global require --dev phpunit/phpunit:"^5.7.21 || ^6.0 || ^7.0 || ^8.0 || ^9.0 || ^10.0"
Your requirements could not be resolved to an installable set of packages.
  Problem 1
    - Root composer.json requires phpunit/phpunit ^5.7.21 || ... || ^10.0, found phpunit/phpunit[...]
      but these were not loaded, because they are affected by security advisories
      ("PKSA-5jz8-6tcw-pbk4", "PKSA-z3gr-8qht-p93v").

Note this now fires on the cli image, not tests-cli, because both Dockerfiles run the same composer global require and v0.4.1's sed targets both but fixes neither.

Suggested fix

Rewrite the command so the Dockerfile disables block-insecure (or sets an explicit audit.ignore) before the require:

sed -i 's|composer global require|composer config --global audit.block-insecure false \&\& composer global require|g' "$f"

Or, more conservatively, ignore just the two PKSA IDs:

sed -i 's|composer global require|composer config --global --json audit.ignore '"'"'{"PKSA-5jz8-6tcw-pbk4":"PHPUnit EOL","PKSA-z3gr-8qht-p93v":"PHPUnit EOL"}'"'"' \&\& composer global require|g' "$f"

The --no-audit flag added in v0.4.1 can be dropped — it has no effect on resolution-time errors.

Scope

• Same fix needed in reusable-wp-visual-regression.yml and reusable-lhci.yml if they also patch wp-env Dockerfiles.
• reusable-wp-integration.yml is unaffected (it runs composer in the host, so consumers can set config.audit.ignore in their own composer.json — see site-bookkeeper-dashboard 4c39a96).

[apermo]

v0.4.2 still fails end-to-end. Root cause goes a level deeper than the sed command.

What actually happens

The patch step emits ##[warning]No wp-env Dockerfile found and exits 0 (see site-bookkeeper-dashboard job 71936905910). The sed is never run, so wp-env start later builds an unpatched image and hits the advisory block again.

Why the find misses

• @wordpress/env does not ship static Dockerfiles. They are generated at runtime by packages/env/lib/runtime/docker/docker-config.js (function writeDockerFiles) and written to config.workDirectoryPath (i.e. ~/.wp-env/<hash>/) — not into node_modules/@wordpress/env. See docker-config.js#L223-L233 on trunk.
• The generated file names are WordPress.Dockerfile, CLI.Dockerfile, Tests-WordPress.Dockerfile, Tests-CLI.Dockerfile. find ... -name 'Dockerfile*' doesn't match those; *.Dockerfile would.
• The patch step runs before wp-env start, so even with the right glob there are no files yet.

Suggested approach

Patch the JS source in node_modules instead of the generated Dockerfiles. The composer global require line lives as a template string literal at line 233:

WP_ENV_PATH="$(npm root -g)/@wordpress/env"
DOCKER_CONFIG="$WP_ENV_PATH/lib/runtime/docker/docker-config.js"
if [ -f "$DOCKER_CONFIG" ] && ! grep -q 'audit.block-insecure' "$DOCKER_CONFIG"; then
    sed -i 's|RUN composer global require|RUN composer config --global audit.block-insecure false \&\& composer global require|g' "$DOCKER_CONFIG"
    echo "Patched: $DOCKER_CONFIG"
else
    echo "::warning::$DOCKER_CONFIG not found or already patched"
fi

Alternatively, run wp-env start, then find ~/.wp-env -name '*.Dockerfile', patch them, and wp-env start --update to rebuild. That's more invasive (two starts) and fragile — the JS-source patch is simpler.

Same change needs to go into reusable-wp-e2e.yml, reusable-wp-visual-regression.yml, reusable-lhci.yml.

[apermo]

Reopening — v0.4.2 still fails. See the comment above for root cause: the patch step can't find the Dockerfiles because wp-env generates them at runtime with .Dockerfile suffix under ~/.wp-env/, not under node_modules.