ci: fail the PHP Unit build when a PHP extension fails to install [10.16]

[oc-tmueller]

Backport of #41848. Please merge that one first.

The failure this fixes the reporting of

setup-php treats a failed extension as a warning and lets the step pass. On master's run 35615464136 that produced a red Oracle job whose visible error named the wrong thing entirely:

==> Setup Extensions
✓ imagick Enabled
✗ oci8 Could not install oci8 on PHP 8.3.33     <-- 14:57:17, step still "passed"
...
In Install.php line 109:
  [InvalidArgumentException] Database <oci> is not supported.     <-- 14:57:53

maintenance:install validates --database against the list OC\Setup::getSupportedDatabases() builds from the loaded PHP extensions, so a missing oci8 presents as a database misconfiguration. The real cause was 36 seconds earlier, in a step that reported success.

Setting setup-php's fail-fast makes the Setup PHP step itself fail, with the ✗ oci8 line as its last output.

One difference from the master PR, and why the comment here is longer

This branch still has the matrix strategy.fail-fast: true (line 22) — #41695 switched it off on master and was never backported. So unlike on master, the two settings compose here: a failed extension now aborts its shard, which cancels the sibling database shards.

That is tolerable for the way ci.yml calls this workflow today, and the comment says so rather than waving it off:

• oci8 is the only extension in this list that downloads anything. Verified in the green 10.16 run: curl, gd, json, xml, zip, imagick all report Enabled in ~3 ms each (they come with setup-php's own PHP 7.4 build), while oci8 reports Installed and enabled after 29 s of Oracle Instant Client download plus compile.
• ci.yml:32-35 already gives Oracle its own single-database call — with a comment saying it exists precisely "so that a slow or failing Oracle run cannot cancel the other databases via fail-fast". That leg has no siblings to cancel.

Worth a maintainer decision, deliberately not done here: the guarantee above is a property of the current caller, not of this reusable workflow — databases is a workflow_call input, so a future caller mixing oracle: into a multi-database list would lose it. Backporting #41695 (strategy.fail-fast: false) would remove the interaction entirely, and the Oracle leg is a single job so fail-fast buys it nothing. I kept that out of this PR as a separate behavioural change for 10.16 CI.

Why the Oracle leg is exposed at all

setup-php's src/scripts/extensions/oci.sh has no cache, so every Oracle job downloads instantclient-basiclite-linuxx64.zip and instantclient-sdk-linuxx64.zip from download.oracle.com via unversioned "latest" URLs, then compiles oci8 from the php/pecl-database-oci8 main branch — both wrapped in >/dev/null 2>&1, which is why the log gives no reason for the failure. That flakiness is not ours to fix; the misattribution is.

How it was verified

Against the real upstream script at this branch's pinned SHA (accd6127, v2.37.0). src/install.ts maps the fail-fast input/env to process.env['fail_fast']; src/scripts/unix.sh reads it in read_env and enforces it in add_log. Executing that add_log directly:

• fail_fast=false → prints ✗ oci8 …, exit 0, execution continues (today's behaviour, i.e. the bug)
• fail_fast=true → prints ✗ oci8 …, exit 1
• fail_fast=true with a ✓ → exit 0, continues, so a successful install is unaffected

No currently-green job relies on a tolerated ✗ — every setup-php line in the recent 10.16 runs is ✓. YAML parses; env placement matches master's acceptance.yml. nightly.yml calls this same reusable workflow, so it picks the change up too.

No changelog entry, following the other workflow-only ci: commits.

🤖 Generated with Claude Code