ci: unrot the Windows PHP download and make PRs run the same matrix as master

[armando-rodriguez-cko]

Why

build-master has failed on every push since 2026-07-30. The two merges earlier today were not the cause; they just made it visible.

The Windows job downloads PHP from a URL pinning the exact patch:

https://downloads.php.net/~windows/releases/php-8.4.23-Win32-vs17-x64.zip

That directory only keeps the current patch of each branch. Once 8.4.24 shipped, this URL began returning 404 and the job died during setup, before running a single test:

Invoke-WebRequest : The remote server returned an error: (404) Not Found.

8.1.34 still resolves today, which is the only reason that job stayed green. It would have rotted the same way on the next 8.1 patch.

Fix 1 — a URL that does not rot

Both downloads now point at windows.php.net/downloads/releases/archives/, which keeps every patch ever published. Verified both files return successfully.

Bumping the PHP patch becomes a deliberate manual edit rather than a time bomb that fires whenever upstream releases.

Fix 2 — PRs run the same matrix as master

The reason nobody caught this: build-pull-request ran ubuntu-latest only. No pull request could exercise Windows, so a Windows-only break was undiscoverable until master was already red.

While aligning the two I found a second problem: the PR workflow installed the distro default PHP for both matrix entries, ignoring php-version. Its 8.1 and 8.4 jobs were testing the same interpreter, so the matrix was reporting coverage it did not have.

build-pull-request.yml is now generated from build-master.yml and differs only in the trigger: same OS and PHP matrix, same setup steps, same checks. Master's Release-commit guard is dropped, having no meaning on a pull request.

Note

No new secrets or workflow variables.

This PR is itself the test of fix 2: its own checks should now include windows-latest on 8.1 and 8.4, which no previous PR in this repo has run.

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-master.yml
• security_sensitive_path:.github/workflows/build-pull-request.yml

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 2

---

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-master.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-pull-request.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[armando-rodriguez-cko]

Updated after the SonarCloud finding, and the finding is fixed rather than sidestepped.

Why it appeared: copying the setup block into build-pull-request.yml made it new code, so the rule fired on a line that had existed in build-master.yml all along. It is a fair point about a job that runs with repository secrets, so all three downloads are now verified:

Download	Verification
PHP zip (Windows)	Pinned SHA-256 per version, checked before Expand-Archive. php.net publishes no checksum next to these archives, so the hashes were computed from the official download: that buys integrity, not independent provenance, and the comment in the file says so.
Composer (Windows)	Pinned to 2.10.2 and checked against the SHA-256 that getcomposer.org publishes for that exact version. composer-stable.phar was a moving target and could not be checksummed at all.
Composer (Ubuntu)	The installer was piped straight from curl into php. Now verified against composer.github.io/installer.sig first, which is the check Composer's own docs prescribe.

A mismatch throws with both hashes in the message, so a future patch bump fails loudly instead of quietly running something else.

And the duplication is gone. build-pull-request.yml is now a 20-line caller of build-master.yml through workflow_call, not a copy. That is a better answer to the original problem than what I first pushed: one definition, so the two cannot drift again, and no duplicated download block. The Release-commit guard is now conditioned on github.event_name == 'push', since a pull request has no github.event.commits to test.

Previous run of this PR did prove the point: windows-latest on 8.1 and 8.4 both passed, which no earlier PR in this repo had ever run.

[agent-wall-e]

🔴 Risk Classification: MAJOR

Approval route: AI Review + Human Approval Required
Rollback controls: Change-freeze window + documented rollback plan

Classification reasons

• security_sensitive_path:.github/workflows/build-master.yml
• security_sensitive_path:.github/workflows/build-pull-request.yml

Operational gates

• ✅ jira_ticket
• ✅ independent_review

Files analysed: 2

---

_{wall-e 2026.06.19-02 · policy 376219bc71e6…}

[agent-wall-e]

🔬 Debug — why this classification?

Each reason code emitted by the classifier, its source clause in the AI in SDLC Control Framework, and what it means.

Reason code	Kind	Clause	Meaning
security_sensitive_path — .github/workflows/build-master.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).
security_sensitive_path — .github/workflows/build-pull-request.yml	classifying	§2.1 M4/M5	Path matched a sensitive pattern (auth, secrets, crypto, PCI, migrations, network IaC).

Kinds:

• classifying — this rule contributed to the chosen tier.
• informational — context only; did not by itself decide the tier.

See issue #3 for the proposal to formalise this map as Appendix A of the standards doc.

_{wall-e 2026.06.19-02 · debug}

[agent-wall-e]

🔵 Advisory review: Sound, but needs your judgement

This PR needs a human approval. The code itself reads as correct; whether it should land depends on context I don't have.

The PR fixes a rotting Windows PHP download URL, adds integrity checks for both PHP and Composer, and unifies the PR/master CI matrix via workflow_call — all of which look correct. The main judgement call is accepting SHA-256 hashes that were self-computed by the author against the official downloads (no independent provenance), and confirming that secrets: inherit on the pull_request trigger is acceptable for your threat model.

For you to decide

• The PHP SHA-256 hashes in build-master.yml (8.1.34 and 8.4.23) are described as 'computed from the official download and pinned here' — a human reviewer should independently verify at least one hash against php.net or a trusted mirror before merging, since this is the integrity anchor for code executed in CI.
• build-pull-request.yml uses secrets: inherit with a pull_request trigger; for public forks this means secrets are exposed to the called workflow during PR runs — this is the standard GitHub Actions footgun and the team needs to confirm the repo is private or that fork PRs cannot trigger this.
• The Composer signature check on Linux fetches the expected signature from composer.github.io over the network at job time, meaning a MITM or a compromised composer.github.io could supply a matching sig+installer pair; this is the officially recommended check but reviewers should be aware it is not a pinned hash.
• The truncated diff means the Windows Composer phar section (mentioned in the comment as 'pinned to a version rather than composer-stable.phar') is not fully visible — the reviewer should confirm the Windows path also verifies the phar before executing it and that the pinned version/hash are present.
• The if condition change from !contains(...) to github.event_name != 'push' || !contains(...) correctly handles the workflow_call case where github.event.commits is empty; logic looks sound.
• The old PR workflow installed distro-default PHP ignoring the matrix php-version — this bug is confirmed removed by the diff, which is a correctness improvement worth noting.

⚠️ The diff was too large to read in full, so this review covers only part of the change.

---

_{This is not an approval. wall-e cannot auto-approve this PR — it is an opinion to help whoever does. Advisory review · us.anthropic.claude-sonnet-4-6 · wall-e 2026.06.19-02}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud