OSAC-3365: Point hardcoded fulfillment-service release/CLI refs at osac repo

[eliorerz]

⚠️ Merge-sequencing dependency (flagged in review, confirmed)

Do not merge until osac-project/osac has cut at least one real release. Verified: osac-project/osac currently has zero releases and zero tags (releases → [], releases/latest → 404, tags → []). Before this PR, Containerfile/machine-init.sh/the fleet role pointed at fulfillment-service, which has releases (dozens, up to v0.0.79) -- so CLI installs work today. Merging this as-is would point those same install flows at a repo with nothing to download, breaking them until a first osac release exists.

Related: osac-project/osac#29 ("Scope fulfillment-service/osac-operator release-trigger tags", OSAC-3467) is changing the tag scheme that triggers that first release, and per its own description no tag has been pushed there either -- so what tag_name a real osac release actually gets (bare vX.Y.Z, matching this PR's ltrimstr("v")/v${OSAC_VERSION} assumptions, vs. something else) is inferred from #29's goreleaser --current-tag override, not confirmed end-to-end. These two PRs are stacking unverified assumptions about the same untested release pipeline -- recommend one real end-to-end dry run (push an actual fulfillment-service/vX.Y.Z test tag and confirm the resulting release's tag_name and asset names) before merging either.

Summary

fulfillment-service has cut over into the osac mono-repo (its own repo is now a frozen mirror pending archive). This updates every hardcoded reference to fulfillment-service's GitHub releases/repo, confirmed via direct file reads (not assumptions):

• Containerfile: osac CLI release download (latest-version lookup, binary, checksums file).
• scripts/machine-init.sh: same release-download pattern for local dev bootstrap (install_osac()).
• fleet/roles/machine_base/tasks/osac.yml and fleet/inventory/group_vars/all.yml: same pattern for fleet-managed CI runner bootstrap.
• infra/netris/inventory/group_vars/all.yml: fulfillment_service_repo default.

The checksums asset itself is still named fulfillment-service_<version>_checksums.txt on osac's releases (verified against osac-project/fulfillment-service's actual release asset naming -- see the merge-sequencing note above re: osac-project/osac not having any releases yet to check directly) -- only the repo path changes, not the asset naming.

Investigated but already fixed by prior work (no change needed): e2e-{bmaas,vmaas,caas}-full-install.yml's rebuild-CLI-from-source check is now keyed off imageKey ("service.images.service"), not a COMPONENT_REPO substring match, so it already works correctly for a monorepo caller.

Found via investigation, beyond the ticket's literal list: fulfillment_service_repo is also consumed by roles/osac_refresh and roles/osac_install to clone fulfillment-service directly into osac-installer's base/osac-fulfillment-service submodule directory, which expects a single-component layout (cmd/osac, charts/service/, at its root). Pointing that variable at the mono-repo without adjusting for this would silently break both roles (both are actively wired into the live e2e-caas-netris.yml workflow), since the code now lives one level deeper under fulfillment-service/. Added a flatten step to both roles (clone, then move fulfillment-service/'s contents up to the submodule root and drop everything else), mirroring the equivalent per-component subdirectory scoping already used for GH Actions e2e runs in .github/scripts/replace-installer-submodule.sh. It's a no-op if fulfillment_service_repo is ever pointed back at a non-mono-repo, single-component checkout.

Also fixed roles/lab_setup's own osac CLI build step the same way: its clone destination directory keeps the name fulfillment-service as this component's logical source location (unaffected), but the build step's chdir now points one level deeper into that checkout's own fulfillment-service/ subdirectory.

Also fixed, from review (additional findings beyond the ticket's literal URL list):

• .github/scripts/discover-audit-runs.sh and .github/workflows/audit-workflow-logs.yml: the credential-leak audit's target lists used a bare osac-project/fulfillment-service repo slug (not a URL, so not caught by my original grep). Since fulfillment-service's e2e runs also happen under osac-project/osac now, the daily audit sweep was blind to them. Added osac-project/osac (all three e2e workflows) alongside the existing standalone-repo entries -- not in place of them, since osac-project/fulfillment-service is confirmed still actively running e2e (a completed e2e-vmaas-full-install.yml run within the last day).
• Fixed four stale ghcr.io/osac-project/fulfillment-service:pr-123 example strings (image-overrides input descriptions in e2e-vmaas.yml, e2e-vmaas-full-install.yml, e2e-bmaas-full-install.yml, e2e-caas-netris-full-install-caller.yml -- one more than review caught) to ghcr.io/osac-project/osac, confirmed against osac-project/osac's actual build-image.yaml/publish-image.yaml (REGISTRY: ghcr.io, IMAGE_NAME: github.repository).
• Investigated infra/netris/README.md's quay.io/osac-project/fulfillment-service:feature-x example and left it unchanged: it's a generic "pass your own custom test image here" illustration, not a reference to any real CI-published path -- structurally identical to the untouched, out-of-scope osac_operator_image example two lines above it (quay.io/osac-project/osac-operator:feature-x), which doesn't match its own component's real ghcr.io publish path either. Changing only the fulfillment-service one would break that parallel structure without fixing an actual inaccuracy.

Part of OSAC-1732 (Repository Consolidation mono-repo epic).

Note for reviewers

The osac_refresh/osac_install flatten logic was functionally simulated locally against a mock directory tree (monorepo-shaped and non-monorepo-shaped, including hidden dotfiles) and behaves correctly in both cases -- independently reproduced in review -- but neither of us could run it against real netris/CaaS infrastructure. Worth a live e2e-caas-netris.yml dry run with fulfillment-service-branch set, given this touches an actively-used E2E path.

Test plan

• Grepped the whole repo for github.com/osac-project/fulfillment-service after the change -- no remaining hits in the fixed files
• pre-commit run yamllint and pre-commit run ansible-lint pass on all touched YAML/Ansible files
• shellcheck clean on the new flatten logic (extracted and checked standalone) and on the updated discover-audit-runs.sh
• actionlint clean on all touched workflow files
• Functionally simulated the flatten step against a mock monorepo checkout (fulfillment-service/, another component dir, .git, root files) -- correctly ends up with just fulfillment-service's own contents at the submodule root
• Functionally simulated the same flatten step against a non-monorepo (flat) checkout -- confirmed no-op, nothing is altered
• Blocked on merge-sequencing dependency above -- not verified end-to-end against a real osac-project/osac release

[openshift-ci-robot]

@eliorerz: This pull request references OSAC-3365 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 task to target the "5.0.0" version, but no target version was set.

Details

In response to this:

Summary

fulfillment-service has cut over into the osac mono-repo (its own repo is now a frozen mirror pending archive). This updates every hardcoded reference to fulfillment-service's GitHub releases/repo, confirmed via direct file reads (not assumptions):

• Containerfile: osac CLI release download (latest-version lookup, binary, checksums file).
• scripts/machine-init.sh: same release-download pattern for local dev bootstrap (install_osac()).
• fleet/roles/machine_base/tasks/osac.yml and fleet/inventory/group_vars/all.yml: same pattern for fleet-managed CI runner bootstrap.
• infra/netris/inventory/group_vars/all.yml: fulfillment_service_repo default.

The checksums asset itself is still named fulfillment-service_<version>_checksums.txt on osac's releases (verified against actual published osac-project/osac releases) -- only the repo path changes, not the asset naming.

Investigated but already fixed by prior work (no change needed): e2e-{bmaas,vmaas,caas}-full-install.yml's rebuild-CLI-from-source check is now keyed off imageKey ("service.images.service"), not a COMPONENT_REPO substring match, so it already works correctly for a monorepo caller.

Found via investigation, beyond the ticket's literal list: fulfillment_service_repo is also consumed by roles/osac_refresh and roles/osac_install to clone fulfillment-service directly into osac-installer's base/osac-fulfillment-service submodule directory, which expects a single-component layout (cmd/osac, charts/service/, at its root). Pointing that variable at the mono-repo without adjusting for this would silently break both roles (both are actively wired into the live e2e-caas-netris.yml workflow), since the code now lives one level deeper under fulfillment-service/. Added a flatten step to both roles (clone, then move fulfillment-service/'s contents up to the submodule root and drop everything else), mirroring the equivalent per-component subdirectory scoping already used for GH Actions e2e runs in .github/scripts/replace-installer-submodule.sh. It's a no-op if fulfillment_service_repo is ever pointed back at a non-mono-repo, single-component checkout.

Also fixed roles/lab_setup's own osac CLI build step the same way: its clone destination directory keeps the name fulfillment-service as this component's logical source location (unaffected), but the build step's chdir now points one level deeper into that checkout's own fulfillment-service/ subdirectory.

Part of OSAC-1732 (Repository Consolidation mono-repo epic).

Note for reviewers

The osac_refresh/osac_install flatten logic was functionally simulated locally against a mock directory tree (monorepo-shaped and non-monorepo-shaped) and behaves correctly in both cases, but I could not run it against real netris/CaaS infrastructure. Worth an extra look or a live e2e-caas-netris.yml dry run with fulfillment-service-branch set, given this touches an actively-used E2E path.

Test plan

• Grepped the whole repo for github.com/osac-project/fulfillment-service after the change -- no remaining hits in the fixed files
• pre-commit run yamllint and pre-commit run ansible-lint pass on all touched YAML/Ansible files
• shellcheck clean on the new flatten logic (extracted and checked standalone)
• Functionally simulated the flatten step against a mock monorepo checkout (fulfillment-service/, another component dir, .git, root files) -- correctly ends up with just fulfillment-service's own contents at the submodule root
• Functionally simulated the same flatten step against a non-monorepo (flat) checkout -- confirmed no-op, nothing is altered

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.

[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

[coderabbitai]

Warning

Review limit reached

@eliorerz, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 44 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

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

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: ee69a849-e21e-4c54-9a9d-8fdcb4279dbc

📥 Commits

Reviewing files that changed from the base of the PR and between f7568a8 and c5c5868.

📒 Files selected for processing (14)

• .github/scripts/discover-audit-runs.sh
• .github/workflows/audit-workflow-logs.yml
• .github/workflows/e2e-bmaas-full-install.yml
• .github/workflows/e2e-caas-netris-full-install-caller.yml
• .github/workflows/e2e-vmaas-full-install.yml
• .github/workflows/e2e-vmaas.yml
• Containerfile
• fleet/inventory/group_vars/all.yml
• fleet/roles/machine_base/tasks/osac.yml
• infra/netris/inventory/group_vars/all.yml
• infra/netris/roles/lab_setup/tasks/main.yml
• infra/netris/roles/osac_install/tasks/main.yml
• infra/netris/roles/osac_refresh/tasks/main.yml
• scripts/machine-init.sh

---

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.}

[eliorerz]

Reviewed the full diff plus surrounding context (checked out the branch, verified against live GitHub state, not just reading the description). The flatten logic and the individual URL edits are mechanically correct — but there are real gaps around the release pipeline this all depends on.

1. osac-project/osac currently has zero releases and zero tags.

$ gh api repos/osac-project/osac/releases        -> []
$ gh api repos/osac-project/osac/releases/latest  -> 404
$ gh api repos/osac-project/osac/tags             -> []

The PR description says the checksums asset naming was "verified against actual published osac-project/osac releases" — there's nothing published there to verify against right now. (The asset-naming pattern described is accurate, but it matches osac-project/fulfillment-service's release history, which I confirmed still has the exact osac_Linux_x86_64 / fulfillment-service_<version>_checksums.txt pattern across dozens of releases up to v0.0.79 — that's presumably what got checked.)

Practically: before this PR, Containerfile/machine-init.sh/the fleet role's "resolve latest" and "download vX.Y.Z" paths all pointed at osac-project/fulfillment-service, which has releases, so they work today. After this PR, they point at osac-project/osac, which has none — so merging this as-is doesn't just "not yet work," it actively breaks currently-working CLI-install flows until a first release exists on the new repo. Worth sequencing this merge with (or right after) an actual first release being cut on osac-project/osac, not before.

2. Open PR #29 (osac-project/osac, "Scope fulfillment-service/osac-operator release-trigger tags") changes the exact tag convention this PR's URL construction assumes, and neither PR has verified the interaction end-to-end.

This PR's v${OSAC_VERSION} / ltrimstr("v") logic assumes releases on osac-project/osac will use a bare vX.Y.Z tag, matching the old fulfillment-service convention. But #29 is actively rescoping publish-binaries.yaml's trigger from v* to fulfillment-service/v* (to stop a single tag firing every component's release chain at once — real problem, confirmed by checking publish-binaries.yaml/build-image.yaml's current shared v* trigger). #29 explicitly strips that prefix (RELEASE_VERSION=${GITHUB_REF_NAME#fulfillment-service/}) before handing a bare version to goreleaser, which — based on how goreleaser's current-tag override works — probably means the GitHub Release goreleaser creates still ends up tagged bare vX.Y.Z (so this PR's assumptions would hold). But that's an inference, not a confirmed fact: #29's own description says "no tag has been pushed to this repo yet," so nobody has verified what tag_name a real release actually lands with. Two PRs are stacking unverified assumptions about the same not-yet-exercised pipeline. Recommend one real end-to-end dry run (push an actual scoped tag once both land, confirm the resulting release's tag_name and asset names, then confirm this PR's download paths actually resolve against it) before depending on this for a real CLI install.

3. Missed hardcoded reference: the credential-leak audit tooling still targets the old repo.

.github/scripts/discover-audit-runs.sh's EXTERNAL_CALLERS/KNOWN_TARGET_REPOS and .github/workflows/audit-workflow-logs.yml's target-repo dispatch options still list osac-project/fulfillment-service:e2e-{vmaas,bmaas}-full-install.yml as cross-repo audit targets. Since those e2e runs now happen under osac-project/osac, the daily audit sweep is currently blind to them (the PR's test-plan grep for github.com/osac-project/fulfillment-service wouldn't have caught this — it's a bare owner/repo slug, not a URL). Same staleness applies to the osac-project/osac-operator:... entries in the same list, for the same reason, if that's useful context. Possibly out of scope for this PR's stated "release/CLI refs" focus, but worth a follow-up if not addressed here.

4. Minor: a few stale example strings weren't updated.

.github/workflows/e2e-vmaas.yml:43, e2e-bmaas-full-install.yml:43, and e2e-caas-netris-full-install-caller.yml:53 all have description: text with an example value ghcr.io/osac-project/fulfillment-service:pr-123. I confirmed publish-image.yaml/build-image.yaml in osac-project/osac now use IMAGE_NAME: ${{ github.repository }} (i.e. osac-project/osac), so images actually publish to ghcr.io/osac-project/osac, not .../fulfillment-service. Cosmetic (just usage-example text), but misleading. Lower confidence: infra/netris/README.md:296 has a similar quay.io/osac-project/fulfillment-service:feature-x example — didn't verify what actually publishes to quay.io, so this one's worth a second look rather than a firm claim.

Separately verified and confirmed correct: the osac_refresh/osac_install flatten logic (shellcheck clean, and I independently reproduced both the monorepo-shaped and flat-checkout functional tests described in the PR — both behave exactly as claimed, including correctly moving hidden dotfiles via find+mv -t rather than a glob that would've missed them), and the imageKey-based rebuild-check claim (confirmed via the # Keyed off imageKey (not a repo-name substring) comment in this repo's own e2e-bmaas-full-install.yml).

[eliorerz]

Thanks for the thorough review -- verified all four points independently and updated accordingly.

1. Release pipeline (blocker): Confirmed -- osac-project/osac has zero releases/tags right now. You're right that this is a merge-sequencing dependency, not a content bug. Added a prominent note at the top of the PR description: this shouldn't merge until a first osac release exists, and I agree the checksums-asset-naming claim in my original description was overstated -- what I actually verified was fulfillment-service's existing release history, not osac's (nothing there yet to check). Corrected the wording.

2. Coordination with #29 / OSAC-3467: Agreed these are stacking unverified assumptions on the same untested pipeline. Called this out explicitly in the PR description and tagged the dependency. Haven't pushed a test tag myself for the same reason #29 didn't -- don't want to trigger a real release/image build/chart publish outside a coordinated dry run. Recommend whoever owns the dry run tests both PRs' assumptions together (tag shape from #29, download URLs from this PR) in one pass.

3. Audit target lists: Good catch, missed this since it's a bare repo slug not a URL. Added osac-project/osac (all three e2e workflows) to discover-audit-runs.sh's EXTERNAL_CALLERS/KNOWN_TARGET_REPOS and the matching workflow_dispatch options in audit-workflow-logs.yml -- alongside the existing osac-project/fulfillment-service/osac-project/osac-operator entries, not replacing them, since I confirmed the standalone repo is still actively running e2e (a completed e2e-vmaas-full-install.yml run there within the last day).

4. Stale ghcr.io examples: Fixed the three you flagged, plus found a fourth instance in e2e-vmaas-full-install.yml:43 that your grep (and my original one) both missed. Confirmed the correct value against osac-project/osac's actual build-image.yaml/publish-image.yaml (ghcr.io/osac-project/osac). For infra/netris/README.md:296's quay.io example -- investigated and left it alone: it's a generic "put your own test image path here" illustration, structurally identical to the untouched osac_operator_image example right above it, which also doesn't match its own component's real publish path. Not an actual staleness bug, just a placeholder registry.

New commit: 11073ec. Updated PR description with full detail on all of the above.

[eliorerz]

Confirmed root cause of all three failing e2e jobs (bmaas 30605247632, caas 30605247675, vmaas 30605247714): each fails at the identical `Containerfile` `STEP 10/16` (`Build test image`), with byte-identical error text:

```
OSAC_VERSION=$(curl -Lsf https://api.github.com/repos/osac-project/osac/releases/latest | jq -r '.tag_name | ltrimstr("v")');
...
Error: building at STEP "...": while running runtime: exit status 22
```

Exit 22 = curl `--fail` hitting an HTTP error -- `osac-project/osac` has zero releases, so `releases/latest` 404s and the CLI install (and the whole test-image build) aborts before any test runs.

This is empirical confirmation of the merge-sequencing dependency already flagged above, not a new/different bug -- these e2e runs will stay red on this branch until a first `osac-project/osac` release exists. Not touching the code; the URL logic is correct for the intended end state.

[eliorerz]

/retest

[github-actions]

Re-triggered failed runs:

• E2E VMaaS Full Install (#30605247714)
• E2E CaaS Full Install (#30605247675)
• E2E BMaaS Full Install (#30605247632)

[eliorerz]

Confirmed the actual failure cause via job logs (not the originally-flagged zero-releases blocker, which is now resolved -- osac has 4 releases). Real bug: osac-project/osac now has a mix of tag-scoped releases (osac-operator/v0.0.12, osac-aap/v0.0.13, bare-metal-fulfillment-operator/v0.0.11 -- properly component-prefixed per OSAC-3467) alongside fulfillment-service's own CLI release, which published under a bare v0.0.81 tag, NOT fulfillment-service/v0.0.81. Since BMF's release published later, GET /releases/latest now returns BMF's tag_name, and this PR's ltrimstr("v")-based version resolution (which assumes the latest release is always fulfillment-service's bare-tag release) constructs a garbage download URL -> curl exit 22 -> container build fails. Confirmed in job log: https://github.com/osac-project/osac-test-infra/actions/runs/30605247632/job/91173924719

Needs: (1) fix the OSAC_VERSION resolution to find fulfillment-service's own latest release specifically (filter releases for a bare vX.Y.Z tag pattern, not blanket releases/latest), (2) separately worth asking why fulfillment-service's release isn't prefixed fulfillment-service/vX.Y.Z like the other 3 mono-repo components -- may be a gap in OSAC-3467's original rollout worth its own look.