ci: derive ghcr.io push target from GITHUB_REPOSITORY_OWNER - #235
Open
hh24k wants to merge 3 commits into
Open
Conversation
Contributor
Author
YanniHu1996
approved these changes
Sep 8, 2026
gabriele-wolfox
approved these changes
Sep 8, 2026
gabriele-wolfox
force-pushed
the
dev/233
branch
from
September 8, 2026 08:28
7cb91b8 to
6bbe148
Compare
gabriele-wolfox
changed the title
gabriele-wolfox
force-pushed
the
dev/233
branch
from
September 8, 2026 12:18
03a1fcf to
6bd0b7a
Compare
CI hardcoded ghcr.io/cloudnative-pg as the image push target in Taskfile.yml, so a fork running CI on its own repo (a push to the fork's own main, or a manual workflow_dispatch run) fails at the push step: the fork's GITHUB_TOKEN has packages:write on its own ghcr.io/<owner> namespace, not on cloudnative-pg's. Add a REGISTRY_OWNER var derived from GITHUB_REPOSITORY_OWNER (falling back to "cloudnative-pg" outside CI) and use it everywhere the registry was hardcoded: core/operator containerize-snapshot and containerize-main, the olm:* image-push tasks, operator:helm-publish, and the OpenShift e2e job's operand image pull default, which needs to match whatever namespace the image was actually pushed to. release-publish.yml's tasks didn't need this fix on their own merits, since those jobs are already gated on github.repository_owner == 'cloudnative-pg', but got the same mechanical substitution for consistency. Fixes cloudnative-pg#233 Assisted-by: Claude Signed-off-by: Hai He <hai.he@enterprisedb.com>
Signed-off-by: huyantian <yantian.hu@enterprisedb.com>
Core CI, Operator CI, and OLM Bundle & Catalog push built images to ghcr.io, but a pull_request from a fork always resolves GITHUB_REPOSITORY_OWNER against the base repository, and GitHub always issues a read-only GITHUB_TOKEN for fork pull_request runs regardless of the permissions requested in the job. Every push attempt from a fork PR is denied, blocking any external contribution that touches core or operator code. Add a same-repo output to change-triage and thread it into a PUSH flag: core:ci/operator:ci build and test as before but skip --push when it is false, the preflight step (which needs a pushed image) is skipped with it, and the whole olm job (which needs both images pushed to resolve digests) is skipped rather than failed. openshift-e2e already had its own equivalent check inline; it now reuses the same output. This mirrors how cloudnative-pg/cloudnative-pg handles the same situation in continuous-integration.yml: only require the build step that can genuinely succeed without registry write access, and skip (never fail) anything that structurally needs a pushed image. Assisted-by: Claude Signed-off-by: Gabriele Quaresima <gabriele.quaresima@enterprisedb.com>
gabriele-wolfox
force-pushed
the
dev/233
branch
from
September 9, 2026 12:23
6bd0b7a to
8cce106
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #233.
CI hardcoded
ghcr.io/cloudnative-pgas the image push target inTaskfile.yml, so a fork running CI on its own repo (a push to the fork's ownmain, or a manualworkflow_dispatchrun) fails at the push step: the fork'sGITHUB_TOKENhaspackages: writeon its ownghcr.io/<owner>namespace, not on cloudnative-pg's.Added a
REGISTRY_OWNERvar derived fromGITHUB_REPOSITORY_OWNER(falling back tocloudnative-pgoutside CI) and used it everywhere the registry was hardcoded: core/operatorcontainerize-snapshot/containerize-main, theolm:*image-push tasks,operator:helm-publish, and the OpenShift e2e job's operand image pull default, which needs to match whatever namespace the image was actually pushed to.release-publish.yml's tasks didn't need this on their own merits, since those jobs are already gated ongithub.repository_owner == 'cloudnative-pg', but got the same mechanical substitution for consistency.