OSAC-3490: Use explicit per-component IMAGE_NAME to fix ghcr.io collision

[eliorerz]

Summary

Fixes a currently-live bug: osac-operator's build-image.yaml and fulfillment-service's publish-image.yaml both set IMAGE_NAME: ${{ github.repository }}. Before the mono-repo merge that resolved to two different values; now both resolve to osac-project/osac for both workflows, so both components push to ghcr.io/osac-project/osac and stomp each other's mutable :latest/:main tags -- last-write-wins between two entirely different binaries. sha-<commit> tags don't collide since they're unique per commit; only the mutable tags do.

Fix

Gave each workflow an explicit, component-specific IMAGE_NAME literal instead of deriving it from github.repository, restoring the original per-component image names:

• build-image.yaml (osac-operator): IMAGE_NAME: osac-project/osac-operator
• publish-image.yaml (fulfillment-service): IMAGE_NAME: osac-project/fulfillment-service

Verification

Read both files' full current content fresh rather than trusting the ticket's line numbers (they'd shifted by one from the ticket's snapshot). Traced every IMAGE_NAME/REGISTRY/github.repository usage in both files, not just the env line:

• build-image.yaml has two images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} references (the main manager image and the manifest-container image) -- both correctly inherit from the same corrected env var, so the manifest image also lands under the right per-component path.
• publish-image.yaml has exactly one such reference.
• No other IMAGE_NAME/REGISTRY derivation exists in either file, and no other github.repository usage in either file relates to image naming.

Also grepped every workflow in the repo for github.repository to make sure no other file has the same unfixed anti-pattern: everything else (e2e-*.yml, publish-charts.yaml, scan-workflow-logs.yml) uses it for benign repo-identification purposes (checkout source, gh api/release calls), never as part of an image name. Found one directly relevant precedent while doing this: osac-aap's own execution-environment.yml already hardcodes images: ghcr.io/osac-project/osac-aap with a comment explicitly calling out this exact collision class -- confirming someone already applied the same fix pattern proactively for that component. This PR brings the other two components in line with that established pattern.

Also searched the mono-repo and org-wide for any file (Helm values, kustomize, docs) hardcoding the currently-broken shared ghcr.io/osac-project/osac path expecting it to mean a specific component -- found none. (The only other ghcr.io/osac-project/osac-prefixed hits found were osac-csi-driver's own image name in a different repo, unrelated.)

Validated with a YAML parse check and yamllint -c .yamllint.yaml --strict on both files -- clean.

Follow-up fix: same collision leaking into the service chart (via CodeRabbit review)

publish-charts.yaml's publish-service-chart job (fulfillment-service) independently derived REPO: ${{ github.repository }} and used it to build app_image="${registry}/${REPO}:${app_version}", written into charts/service/values.yaml's images.service field at release time. Same root cause, a second leak point: once the IMAGE_NAME fix above lands, fulfillment-service's real image only exists at ghcr.io/osac-project/fulfillment-service, so this job would have injected a reference to an image that no longer exists at ghcr.io/osac-project/osac -- breaking every real fulfillment-service chart release.

Fixed by hardcoding that job's REPO env var to osac-project/fulfillment-service, matching the IMAGE_NAME set in publish-image.yaml.

Re-read the full file to confirm scope: REPO in publish-service-chart is used exactly once, only for the image-reference construction above -- nothing else in that job needs it. The other four REPO: ${{ github.repository }} occurrences in this file (osac-operator's publish-operator-crds-chart/publish-operator-chart/create-operator-release jobs) all use it correctly for real gh api/gh release create calls against the actual triggering repo and are untouched -- confirmed osac-operator's own chart (charts/operator/values.yaml) already hardcodes its repository: field statically and this file's operator job only ever sed-replaces the tag, never the repository, so osac-operator was never affected by this particular leak.

Validated with a YAML parse check and yamllint -c .yamllint.yaml --strict -- clean.

Unblocks

OSAC-3368 (updating the enclave repo's hardcoded image references) was blocked on this -- there was no correct, stable image name to point at for either component. This restores ghcr.io/osac-project/osac-operator and ghcr.io/osac-project/fulfillment-service as the correct stable names, matching what OSAC-3368 already expects.

Summary by CodeRabbit

• Chores
  • Standardized container image references used during builds and publishing.
  • Updated service chart publishing to use the correct image repository.
  • Improved consistency of image tags across deployment artifacts.

[coderabbitai]

Walkthrough

The workflows now use fixed image repositories for the operator and fulfillment service instead of deriving repositories from the GitHub repository.

Changes

Container image identity updates

Layer / File(s)	Summary
Workflow image names .github/workflows/build-image.yaml, .github/workflows/publish-image.yaml, .github/workflows/publish-charts.yaml	The workflows use osac-project/osac-operator for the operator image and osac-project/fulfillment-service for the fulfillment service image and chart reference.

Estimated code review effort: 2 (Simple) | ~10 minutes

Possibly related PRs

• osac-project/osac#29: Both PRs update image and chart publishing workflows. PR #29 also changes release triggers and version tags.

🚥 Pre-merge checks | ✅ 10 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Ai-Attribution	⚠️ Warning	The PR description mentions CodeRabbit, but both PR commits have empty bodies and no Assisted-by or Generated-by trailer; no Co-Authored-By trailer is present.	Add the required Red Hat Assisted-by or Generated-by trailer for the AI-assisted commit(s). Do not use Co-Authored-By for AI tools.

✅ Passed checks (10 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
No-Hardcoded-Secrets	✅ Passed	The PR adds only component image names and comments; no literal API keys, tokens, passwords, private keys, credential URLs, or long encoded blobs were added. Existing GITHUB_TOKEN references use se...
No-Weak-Crypto	✅ Passed	The PR adds only component image names and comments; affected workflows contain no MD5, SHA-1, DES, RC4, Blowfish, ECB, custom crypto, or secret/token comparisons.
No-Injection-Vectors	✅ Passed	The PR only replaces repository-derived image names with hardcoded literals. The diff adds no SQL concatenation, eval/exec, pickle.loads, unsafe yaml.load, os.system, shell=True, or dangerouslySetI...
Container-Privileges	✅ Passed	The PR changes only image-name workflow values; its full diff adds no privileged, hostPID/hostNetwork/hostIPC, SYS_ADMIN, allowPrivilegeEscalation, or root settings.
No-Sensitive-Data-In-Logs	✅ Passed	The cumulative diff adds no logging. Tokens are passed to actions or Helm via stdin; logs contain only image tags, versions, commit SHAs, and static manifest metadata.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the explicit per-component image names that prevent GitHub Container Registry image collisions.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.github/workflows/publish-image.yaml:
- Around line 28-33: Align the image repository used by the workflow and
deployment chart: update the repository reference in the chart’s service values
configuration to match IMAGE_NAME, ghcr.io/osac-project/fulfillment-service,
while preserving the existing image tag behavior.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 6fcaf6d6-b8a8-47e5-8920-d1a627bff3fa

📥 Commits

Reviewing files that changed from the base of the PR and between d8d6169 and f2a76bd.

📒 Files selected for processing (2)

• .github/workflows/build-image.yaml
• .github/workflows/publish-image.yaml

[eliorerz]

Good catch from the CodeRabbit review -- confirmed and fixed in the latest commit. publish-charts.yaml's publish-service-chart job had the same root-cause leak: it independently derived REPO from github.repository to build the image reference written into charts/service/values.yaml, which would have pointed fulfillment-service's chart at a now-nonexistent ghcr.io/osac-project/osac image once the IMAGE_NAME fix lands.

Re-read the full file to confirm scope before touching anything: REPO is used exactly once in that job (the image-reference construction), so hardcoding it to osac-project/fulfillment-service is safe. Left every other REPO usage in the file untouched -- osac-operator's three jobs all use REPO correctly for real gh api/gh release create calls against the actual repo, and confirmed osac-operator's own chart hardcodes its repository field statically already (this file's operator job only ever sed-replaces the tag), so osac-operator was never affected by this particular leak.

[eliorerz]

Reviewed from scratch — pulled the branch fresh, read the full current content of all three files, and independently verified every claim rather than trusting the description.

(1) Content confirmed as described. build-image.yaml now has IMAGE_NAME: osac-project/osac-operator and publish-image.yaml has IMAGE_NAME: osac-project/fulfillment-service, both hardcoded with an explanatory comment. Confirmed build-image.yaml's two images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} references (main image + manifest-container image) both correctly inherit the corrected value — traced both, no third derivation site missed.

(2) osac-operator's chart genuinely unaffected — verified via both the values file AND the full job steps, not just one:

osac-operator/charts/operator/values.yaml:
  image:
    repository: ghcr.io/osac-project/osac-operator
    tag: latest  # PLACEHOLDER -- overwritten at release time by publish-charts.yaml

And publish-operator-chart's only mutation of that file is:

sed -i "s/tag: latest/tag: v${{ steps.version.outputs.version }}/" charts/operator/values.yaml

That sed only ever matches and replaces tag: latest — it has no way to touch repository:, which stays whatever's committed. So osac-operator's chart was correctly never exposed to this leak class; confirmed by reading the actual substitution logic, not just noting the field looks static.

(3) Fulfillment-service REPO fix confirmed scoped to exactly one line. git show 2d724e0e (the second commit) is 8 insertions / 1 deletion, entirely the REPO: env line in publish-service-chart's single step. Confirmed REPO is used exactly once in that step (app_image="${registry}/${REPO}:${app_version}") — the job's other repo-ish reference, oci://ghcr.io/${{ github.repository_owner }}/charts on the push line, is a different context value (repository_owner, i.e. just the org, osac-project) used for the shared charts OCI namespace, not per-component and not part of this collision, correctly left alone. Confirmed the other 4 github.repository occurrences in the file (lines 143/196/253/269, all in the three osac-operator jobs — the tag-verification script call and the gh release create --repo call) are byte-for-byte untouched by this commit and correctly still need the real triggering repo for their gh api/gh release calls against osac-project/osac.

(4) Grepped and reasoned through every github.repository hit in the repo for a third leak point — found none:

• osac-aap/vendor/.../docs-push.yml — a vendored third-party Ansible collection's own CI file inside vendor/; never executed by this repo's Actions (not under .github/workflows/), irrelevant.
• The # Hardcoded rather than github.repository... comment lines in publish-image.yaml/publish-charts.yaml/build-image.yaml and execution-environment.yml — just this fix's own explanatory comments (and osac-aap's pre-existing one), not live usages.
• scan-workflow-logs.yml's two hits — one feeds gh api repos/${REPO}/commits/.../pulls (finding the PR for a commit), the other builds a run-URL for a Slack/PR notification. Both need the real repo, neither touches image naming.
• The "repo":"... || github.repository" fields inside the components[] JSON in e2e-{bmaas,vmaas,caas}-full-install.yml — these tell the reusable e2e workflow which repo/ref to clone and build a component's image from for that one ephemeral test run; the resulting per-run image override is keyed by imageKey (service.images.service, operator.image.repository, aap.bootstrap.image), not by repo name, specifically so multiple components sharing the same repo value don't collide here either. Already correctly abstracted, not a leak point.

Also confirmed: osac-aap/execution-environment.yml already hardcodes images: ghcr.io/osac-project/osac-aap with a comment explicitly citing OSAC-3490 — a genuine pre-existing precedent this PR now matches for the other two components, not an invented one. All three files parse as valid YAML, and git merge-tree against current main is conflict-free. (Side note: this branch predates PR #29's tag-scoping rework of publish-charts.yaml — worth a rebase check before merge to avoid the two PRs' changes to that file landing awkwardly, but that's a sequencing note, not a defect in this PR's own logic.)

Verdict: both commits are correct, complete, and properly scoped. No third leak point found. Good to merge (mind the likely rebase against #29 once that lands).

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: eliorerz

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [eliorerz]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci-robot]

@eliorerz: This pull request references OSAC-3490 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

Fixes a currently-live bug: osac-operator's build-image.yaml and fulfillment-service's publish-image.yaml both set IMAGE_NAME: ${{ github.repository }}. Before the mono-repo merge that resolved to two different values; now both resolve to osac-project/osac for both workflows, so both components push to ghcr.io/osac-project/osac and stomp each other's mutable :latest/:main tags -- last-write-wins between two entirely different binaries. sha-<commit> tags don't collide since they're unique per commit; only the mutable tags do.

Fix

Gave each workflow an explicit, component-specific IMAGE_NAME literal instead of deriving it from github.repository, restoring the original per-component image names:

• build-image.yaml (osac-operator): IMAGE_NAME: osac-project/osac-operator
• publish-image.yaml (fulfillment-service): IMAGE_NAME: osac-project/fulfillment-service

Verification

Read both files' full current content fresh rather than trusting the ticket's line numbers (they'd shifted by one from the ticket's snapshot). Traced every IMAGE_NAME/REGISTRY/github.repository usage in both files, not just the env line:

• build-image.yaml has two images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }} references (the main manager image and the manifest-container image) -- both correctly inherit from the same corrected env var, so the manifest image also lands under the right per-component path.
• publish-image.yaml has exactly one such reference.
• No other IMAGE_NAME/REGISTRY derivation exists in either file, and no other github.repository usage in either file relates to image naming.

Also grepped every workflow in the repo for github.repository to make sure no other file has the same unfixed anti-pattern: everything else (e2e-*.yml, publish-charts.yaml, scan-workflow-logs.yml) uses it for benign repo-identification purposes (checkout source, gh api/release calls), never as part of an image name. Found one directly relevant precedent while doing this: osac-aap's own execution-environment.yml already hardcodes images: ghcr.io/osac-project/osac-aap with a comment explicitly calling out this exact collision class -- confirming someone already applied the same fix pattern proactively for that component. This PR brings the other two components in line with that established pattern.

Also searched the mono-repo and org-wide for any file (Helm values, kustomize, docs) hardcoding the currently-broken shared ghcr.io/osac-project/osac path expecting it to mean a specific component -- found none. (The only other ghcr.io/osac-project/osac-prefixed hits found were osac-csi-driver's own image name in a different repo, unrelated.)

Validated with a YAML parse check and yamllint -c .yamllint.yaml --strict on both files -- clean.

Follow-up fix: same collision leaking into the service chart (via CodeRabbit review)

publish-charts.yaml's publish-service-chart job (fulfillment-service) independently derived REPO: ${{ github.repository }} and used it to build app_image="${registry}/${REPO}:${app_version}", written into charts/service/values.yaml's images.service field at release time. Same root cause, a second leak point: once the IMAGE_NAME fix above lands, fulfillment-service's real image only exists at ghcr.io/osac-project/fulfillment-service, so this job would have injected a reference to an image that no longer exists at ghcr.io/osac-project/osac -- breaking every real fulfillment-service chart release.

Fixed by hardcoding that job's REPO env var to osac-project/fulfillment-service, matching the IMAGE_NAME set in publish-image.yaml.

Re-read the full file to confirm scope: REPO in publish-service-chart is used exactly once, only for the image-reference construction above -- nothing else in that job needs it. The other four REPO: ${{ github.repository }} occurrences in this file (osac-operator's publish-operator-crds-chart/publish-operator-chart/create-operator-release jobs) all use it correctly for real gh api/gh release create calls against the actual triggering repo and are untouched -- confirmed osac-operator's own chart (charts/operator/values.yaml) already hardcodes its repository: field statically and this file's operator job only ever sed-replaces the tag, never the repository, so osac-operator was never affected by this particular leak.

Validated with a YAML parse check and yamllint -c .yamllint.yaml --strict -- clean.

Unblocks

OSAC-3368 (updating the enclave repo's hardcoded image references) was blocked on this -- there was no correct, stable image name to point at for either component. This restores ghcr.io/osac-project/osac-operator and ghcr.io/osac-project/fulfillment-service as the correct stable names, matching what OSAC-3368 already expects.

Summary by CodeRabbit

• Chores
• Standardized container image references used during builds and publishing.
• Updated service chart publishing to use the correct image repository.
• Improved consistency of image tags across deployment artifacts.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/build-image.yaml (1)

75-75: 🔒 Security & Privacy | 🟠 Major | ⚡ Quick win

Pin all actions to full commit SHAs.

Lines 75, 81, 114, 136, and 162 use mutable major tags. Replace each ref with a 40-character commit SHA and retain the action version in a comment.

As per path instructions, .github/workflows/**/* files must pin actions by full SHA, not tag.

Also applies to: 81-81, 114-114, 136-136, 162-162

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/build-image.yaml at line 75, Update every action reference
in the workflow, including the steps at lines 75, 81, 114, 136, and 162, to use
its immutable 40-character commit SHA instead of a mutable major tag, and retain
the corresponding action version in an inline comment.

Source: Path instructions

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In @.github/workflows/build-image.yaml:
- Line 75: Update every action reference in the workflow, including the steps at
lines 75, 81, 114, 136, and 162, to use its immutable 40-character commit SHA
instead of a mutable major tag, and retain the corresponding action version in
an inline comment.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Repository: osac-project/coderabbit/.coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: ceb7624a-1c15-4a44-bf9b-c15d1739c27a

📥 Commits

Reviewing files that changed from the base of the PR and between f2a76bd and 0504c5c.

📒 Files selected for processing (3)

• .github/workflows/build-image.yaml
• .github/workflows/publish-charts.yaml
• .github/workflows/publish-image.yaml