Problem
`release.yml`'s `docker/build-push-action` step fails on every attempt (dry-run via `workflow_dispatch`) with:
```
ERROR: failed to build: denied: permission_denied: write_package
```
What's already been tried, in order, none resolved it
- Repo-level default workflow permissions: confirmed `write` (was `read` after the M7 repo recreation, corrected).
- Package "Manage Actions access": added the `reed` repository explicitly.
- Package "Manage Codespace access": added the `reed` repository explicitly.
- Manually seeded the package via a real user PAT (`docker login` + `docker build` + `docker push ghcr.io/simonives/reed:seed`), succeeded with a real digest, confirming the package itself, credentials, and Dockerfile are all fine when pushed as a real user.
- Package visibility: was `Private` despite the linked repo being `Public`, changed to `Public`.
Every one of the above should plausibly have fixed it per GitHub's documented model, none did. The failure is identical (same error, same step) before and after each change.
Leading hypothesis, not yet tested
The package was first created by a manual user push (step 4 above) rather than by Actions itself. Some personal-account GHCR packages appear to retain an implicit restriction to the identity that first created them, regardless of the access grants layered on afterward via package settings. The standard community-reported workaround is to delete the package entirely and let a subsequent Actions-triggered push create it from scratch, since a package Actions creates itself doesn't carry this restriction.
Why this matters
This blocks `release.yml` from ever completing a real release (dry-run or otherwise) that includes the Docker/GHCR step, which blocks Docker-based distribution, the core distribution path documented in the README's "Self-hosting" section and ARCHITECTURE.md. PyPI publish and GitHub Release creation, gated behind `github.event_name == 'push'` on a real tag, have never been exercised at all since this blocks even getting that far in a dry run.
Recommended next step
Delete `ghcr.io/simonives/reed` entirely (all tags, including the manually-seeded `:seed`), then re-run `workflow_dispatch` with `dry_run: true` and see if a package Actions creates itself from zero succeeds where the manually-seeded one didn't. If it still fails, this needs a GitHub Support ticket, since every documented, UI-accessible permission control has been exhausted.
Problem
`release.yml`'s `docker/build-push-action` step fails on every attempt (dry-run via `workflow_dispatch`) with:
```
ERROR: failed to build: denied: permission_denied: write_package
```
What's already been tried, in order, none resolved it
Every one of the above should plausibly have fixed it per GitHub's documented model, none did. The failure is identical (same error, same step) before and after each change.
Leading hypothesis, not yet tested
The package was first created by a manual user push (step 4 above) rather than by Actions itself. Some personal-account GHCR packages appear to retain an implicit restriction to the identity that first created them, regardless of the access grants layered on afterward via package settings. The standard community-reported workaround is to delete the package entirely and let a subsequent Actions-triggered push create it from scratch, since a package Actions creates itself doesn't carry this restriction.
Why this matters
This blocks `release.yml` from ever completing a real release (dry-run or otherwise) that includes the Docker/GHCR step, which blocks Docker-based distribution, the core distribution path documented in the README's "Self-hosting" section and ARCHITECTURE.md. PyPI publish and GitHub Release creation, gated behind `github.event_name == 'push'` on a real tag, have never been exercised at all since this blocks even getting that far in a dry run.
Recommended next step
Delete `ghcr.io/simonives/reed` entirely (all tags, including the manually-seeded `:seed`), then re-run `workflow_dispatch` with `dry_run: true` and see if a package Actions creates itself from zero succeeds where the manually-seeded one didn't. If it still fails, this needs a GitHub Support ticket, since every documented, UI-accessible permission control has been exhausted.