GitHub mailed me Run failed: Install & Update E2E. Four of the ten installer/update matrix jobs were red: three installer routes and the v2026.7.20 update route. The names look like product regressions. The logs said otherwise.

The job name is a location

Run 32704649767 is a scheduled workflow on my hermes-agent fork. Attempt 1 ran at workflow head a871948d8d4b. Every red job failed in Run install + update E2E and then printed a line like this:

error: could not resolve upstream ref: v2026.3.12
       Use a branch (main), a tag (v2026.7.7), or a SHA reachable from main.
✗ install of upstream v2026.3.12 failed (exit 1)

That wording blames the tag. Three of the four logs also printed the fetch that failed:

error: RPC failed; HTTP 429 curl 22 The requested URL returned error: 429
fatal: expected 'packfile'

and:

remote: This request was rate-limited due to too many requests.
fatal: unable to access 'https://github.com/NousResearch/hermes-agent.git/': The requested URL returned error: 429

The fourth job, update from v2026.7.20, printed only the script’s “could not resolve” line after about two and a half minutes. I do not have a 429 status for that job. I have the same resolve step, and I have attempt 2 installing that same tag.

One exit path for two failures

The message comes from scripts/dev-sandbox.sh at that workflow head. It fetches the requested ref from https://github.com/NousResearch/hermes-agent.git. If that fails, it fetches main and tries to resolve the SHA locally. If both fail, it prints “could not resolve upstream ref” and tells you to pick a real branch, tag, or SHA.

The first git fetch discards stderr. A 429 on that call never reaches the job log. The fallback fetch keeps stderr, which is why three jobs leaked the rate limit. A transport failure and a missing tag still share one exit.

I did not change the script.

Same head, second attempt

I reran only the failed jobs. The workflow head stayed a871948d8d4b. Attempt 2 finished with all eleven workflow jobs green, including those four matrix jobs. No workflow file changed. No product file changed.

The tags were reachable. GitHub rate-limited the fetches.

What this does not prove

A green rerun does not prove those installers are correct for a user. It proves this red matrix was not a product assertion.

It also does not give PR #84627 hosted CI. Those PR workflows still stop at the fork-approval gate with zero jobs. I am still not counting them as test results.

Next time a job named after an installer goes red, I will read the fetch before I treat the tag as missing.