Describe the bug
The "Build public push gateway" jobs in .github/workflows/docker.yml hardcode
ghcr.io/block/buzz-push-gateway in outputs, cache-from, and cache-to
(~lines 403-405 on current main). The relay/desktop image jobs already solve
exactly this with a repository-variable override —
IMAGE_NAME: ${{ vars.GHCR_IMAGE != '' && vars.GHCR_IMAGE || 'ghcr.io/block/buzz' }}
(~line 79) — but the push-gateway job doesn't participate in that pattern.
On a fork, the workflow's GHCR login authenticates as the fork's owner, so the
cache export to ghcr.io/block/... is denied and the job fails after an
otherwise-green build. The cache-to guard
(github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository)
doesn't cover this: for a same-repo PR inside a fork, both sides equal the
fork, the guard passes, and the export still targets block's namespace.
Steps to reproduce
- Fork block/buzz with Actions enabled.
- Open any same-repo PR in the fork (or push a branch that triggers docker.yml).
- "Build public push gateway" compiles green, then dies at cache export:
ERROR: failed to build: failed to solve: error writing layer blob: denied: permission_denied: The requested installation does not exist.
Observed on our fork: https://github.com/intent-solutions-io/buzz/actions/runs/30881963216/job/91905049513
Expected behavior
Fork CI completes without write access to block's GHCR namespace — the behavior
the relay/desktop image jobs already have via vars.GHCR_IMAGE.
Version and platform
- Buzz version: n/a — CI workflow,
main @ 631b05c
- OS: ubuntu-latest runners
Logs / additional context
Happy to send a small PR completing the existing pattern — e.g. a workflow-level
PUSH_GATEWAY_IMAGE: ${{ vars.GHCR_PUSH_GATEWAY_IMAGE != '' && vars.GHCR_PUSH_GATEWAY_IMAGE || 'ghcr.io/block/buzz-push-gateway' }}
referenced from the outputs/cache lines. Defaults preserve block's behavior
byte-for-byte; a fork sets one repository variable and its CI is clean.
(DCO-signed per CONTRIBUTING.)
Describe the bug
The "Build public push gateway" jobs in
.github/workflows/docker.ymlhardcodeghcr.io/block/buzz-push-gatewayinoutputs,cache-from, andcache-to(~lines 403-405 on current
main). The relay/desktop image jobs already solveexactly this with a repository-variable override —
IMAGE_NAME: ${{ vars.GHCR_IMAGE != '' && vars.GHCR_IMAGE || 'ghcr.io/block/buzz' }}(~line 79) — but the push-gateway job doesn't participate in that pattern.
On a fork, the workflow's GHCR login authenticates as the fork's owner, so the
cache export to
ghcr.io/block/...is denied and the job fails after anotherwise-green build. The
cache-toguard(github.event_name != 'pull_request' || github.event.pull_request.head.repo.full_name == github.repository)doesn't cover this: for a same-repo PR inside a fork, both sides equal the
fork, the guard passes, and the export still targets block's namespace.
Steps to reproduce
ERROR: failed to build: failed to solve: error writing layer blob: denied: permission_denied: The requested installation does not exist.Observed on our fork: https://github.com/intent-solutions-io/buzz/actions/runs/30881963216/job/91905049513
Expected behavior
Fork CI completes without write access to block's GHCR namespace — the behavior
the relay/desktop image jobs already have via
vars.GHCR_IMAGE.Version and platform
main@ 631b05cLogs / additional context
Happy to send a small PR completing the existing pattern — e.g. a workflow-level
PUSH_GATEWAY_IMAGE: ${{ vars.GHCR_PUSH_GATEWAY_IMAGE != '' && vars.GHCR_PUSH_GATEWAY_IMAGE || 'ghcr.io/block/buzz-push-gateway' }}referenced from the outputs/cache lines. Defaults preserve block's behavior
byte-for-byte; a fork sets one repository variable and its CI is clean.
(DCO-signed per CONTRIBUTING.)