front-e2e: GHCR push denied for image-changing lanes — publyapp-e2e-* packages appear unlinked from the repo

[radandevist]

Signature

Push stack images to GHCR (same-repo runs only) (front-e2e.yml:210) fails deterministically with:

denied: permission_denied: The requested installation does not exist.

before a single e2e test executes. Reproduced on 1 initial run + 3 failed-job reruns + 1 fresh run (empty commit), i.e. 5/5 failures on lane/wt-1264 today.

Correlation observed

• Failing lanes all change front/api code → compose bake must upload new layers.
• Succeeding lanes in the same window (lane/wt-nuget2 @06:21, lane/wt-866 @06:05, same actor) changed no image content → push is manifest/cache-hit only.
• Package API: GET /users/radandevist/packages/container/publyapp-e2e-front returns "repository": null — the container package is not linked to PublyApp/publyapp, so GITHUB-token uploads requiring new layer writes are refused while no-op pushes slip through cache semantics.

Suggested owner actions

1. Relink the four publyapp-e2e-* container packages to PublyApp/publyapp (GitHub → Your packages → package settings → Manage repositories / link).
2. If the unlink was accidental, open a GitHub support incident referencing this signature.
3. Consider a periodic CI canary that pushes a tiny throwaway layer so breakage surfaces on a schedule instead of blocking feature lanes.

Evidence

• Transcript: .dump/round2-front-e2e-infra-failure.txt on branch lane/wt-1264 (PR refactor(front): resolve React Compiler follow-ups from #1234 skip inventory (#1264) #1326).
• Failed runs: 32815375127 (+3 reruns), 32817535920. Succeeded same window: 32816589372, 32815479487.

Found while getting #1326's CI fully green; all non-e2e checks there are green on ad6116f.

[radandevist]

Reproduced identically from another image-changing lane: lane/wt-820 / PR #1385 (front bulk-actions). Failed runs 32814036920 and 32817875467, same denied: permission_denied: The requested installation does not exist. at the GHCR push step, zero e2e tests executed. Same correlation holds: all non-e2e checks on fd8aff6 are green. Will rerun failed jobs once the packages are relinked.

[radandevist]

Strengthened evidence (06:52–06:56Z): four more image-changing lanes failed consecutively after the last success — wt-1378 (06:34), wt-1357 (06:35), wt-820 (06:38), wt-1362 (06:40) — same signature (permission_denied: The requested installation does not exist, front-e2e.yml:210 push step). Last success remains wt-nuget2 @06:21. This is now a hard outage for any push carrying new layers, not a flake pattern.

Also note: the publish deploy images run on develop triggered at 06:53Z (production release path) is in flight — if its push steps fail the same way, production releases are blocked too, which raises priority of the package relink.

[radandevist]

P0 confirmation — production releases are blocked too. The publish deploy images run on develop triggered at 06:53Z failed at 06:59Z with the identical signature:

ERROR: failed to push ghcr.io/radandevist/publyapp/api:f49096d0e6f8…: denied: permission_denied: The requested installation does not exist.

So the unlink affects at minimum publyapp/api (and likely all publyapp/* production images), not just the publyapp-e2e-* packages. Until the packages are relinked (or an incident with GitHub support resolves it), no release images can ship and every image-changing PR lane stays red regardless of its diff. Run: 32819005410.

[radandevist]

Duplicate of #1362: since the transfer to the PublyApp org, the workflows pushed to the old ghcr.io/radandevist/... namespace where the org's GITHUB_TOKEN has no write access. PR #1396 derives the namespace from the repository owner; its first run pushed the publyapp-e2e-* packages under the org successfully (a cleanup edge case is being fixed in the same PR). Closing.

[radandevist]

Forensic bracket from the workflow history: last successful GHCR push 2026-08-25T06:21:08Z (front e2e, lane/wt-nuget2), first failure 06:34:08Z (fresh run). Every GHCR-writing run since — 5 e2e lanes plus the 06:53Z production publish deploy images — has failed with the same permission_denied. Onset window for the GitHub-side change is therefore 06:21–06:34Z today. That timestamp range should make it straightforward to correlate with a package-setting change or a GitHub incident on your side.