Authenticate setup-php against the GitHub API #175

2026-08-20T16:27:38Z

thatguygriff commented

2026-08-20 16:27:38 +00:00

Fixes the intermittent Could not setup PHP 8.3 failures that took out CI on main (run 519) and the release build (run 520).

setup-php resolves its tools through the GitHub API, which allows 60 requests an hour per source address when unauthenticated. A CI fan-out across the fleet exhausts that, and the step then retries for minutes before reporting only Could not setup PHP — it reads as a hang rather than a throttle.

Each cluster egresses from its own address (eris 156.34.91.87, kallone 156.34.93.179, nemesis 47.54.36.100) and so has its own bucket. That is why, during run 519, three jobs with identical PHP and tool config behaved differently on the same node in the same minute:

job	node	duration	result
Tests (PHP 8.2)	kallone	54s	success
PHPStan	kallone	8m06s	success
Coding Standards	kallone	7m10s	failure

Ruled out by measurement first: memory (dind peaked 136Mi of 1Gi), CPU (node at 1.24 of 4 cores, load 1.67, 8.3GiB free), and docker0 MTU (1450 everywhere).

The token is read from 1Password via the Connect instance in whichever cluster picked up the job, mirroring the pattern in thatguygriff/infra. That repo's op-connect composite action is not reachable from here, so it is mirrored as .gitea/actions/op-github-token.

It stays a step output rather than being exported to the job environment, so a GitHub PAT is not sitting in the environment where composer install runs third-party package scripts.

Org-level OP_CONNECT_HOST variable added to Unsupervised (the three OP_CONNECT_TOKEN_* secrets were already there).

🤖 Generated with Claude Code

https://claude.ai/code/session_0133tYSQoZhoKebKZV8o2GPs

Fixes the intermittent `Could not setup PHP 8.3` failures that took out CI on main (run 519) and the release build (run 520). `setup-php` resolves its tools through the GitHub API, which allows 60 requests an hour per source address when unauthenticated. A CI fan-out across the fleet exhausts that, and the step then retries for minutes before reporting only `Could not setup PHP` — it reads as a hang rather than a throttle. Each cluster egresses from its own address (eris `156.34.91.87`, kallone `156.34.93.179`, nemesis `47.54.36.100`) and so has its own bucket. That is why, during run 519, three jobs with identical PHP and tool config behaved differently on the same node in the same minute: | job | node | duration | result | |---|---|---|---| | Tests (PHP 8.2) | kallone | 54s | success | | PHPStan | kallone | 8m06s | success | | Coding Standards | kallone | 7m10s | **failure** | Ruled out by measurement first: memory (dind peaked 136Mi of 1Gi), CPU (node at 1.24 of 4 cores, load 1.67, 8.3GiB free), and docker0 MTU (1450 everywhere). The token is read from 1Password via the Connect instance in whichever cluster picked up the job, mirroring the pattern in `thatguygriff/infra`. That repo's `op-connect` composite action is not reachable from here, so it is mirrored as `.gitea/actions/op-github-token`. It stays a **step output** rather than being exported to the job environment, so a GitHub PAT is not sitting in the environment where `composer install` runs third-party package scripts. Org-level `OP_CONNECT_HOST` variable added to `Unsupervised` (the three `OP_CONNECT_TOKEN_*` secrets were already there). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_0133tYSQoZhoKebKZV8o2GPs

thatguygriff added 1 commit 2026-08-20 16:27:38 +00:00

Authenticate setup-php against the GitHub API

CI / PHPStan (pull_request) Successful in 6m52s

Details

CI / Tests (PHP 8.1) (pull_request) Successful in 6m0s

Details

CI / Tests (PHP 8.2) (pull_request) Successful in 1m11s

Details

CI / Tests (PHP 8.3) (pull_request) Successful in 2m55s

Details

CI / No Debug Code (pull_request) Successful in 2s

Details

CI / Coding Standards (pull_request) Successful in 7m6s

Details

CI / Build Plugin Zip (pull_request) Skipped

Details

1291af0b72

setup-php resolves its tools through the GitHub API, unauthenticated at 60
requests an hour per source address. A CI fan-out across the fleet exhausts
that bucket, and the step then retries for several minutes before reporting
only "Could not setup PHP 8.3". It reads as a hang rather than a throttle,
and it took out both a main CI run and a release build.

Each cluster has its own egress address and so its own bucket, which is why
the same job passed on one runner and failed on another in the same minute.

The token comes from 1Password through the Connect instance in whichever
cluster picked up the job, matching the pattern in thatguygriff/infra. That
repository's composite action is not reachable from here, so it is mirrored
locally. It stays a step output rather than being exported to the job
environment, to keep it away from the package scripts composer install runs.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_0133tYSQoZhoKebKZV8o2GPs

thatguygriff merged commit 170d7e6c21 into main

2026-08-20 16:56:39 +00:00

thatguygriff deleted branch ci/github-token-for-setup-php

2026-08-20 16:56:39 +00:00

thatguygriff referenced this issue from a commit

2026-08-20 17:22:59 +00:00

Stop authenticating setup-php against the GitHub API

thatguygriff referenced this pull request

2026-08-20 17:23:18 +00:00

Stop authenticating setup-php against the GitHub API #177

thatguygriff referenced this pull request

2026-08-20 17:23:44 +00:00