OSAC-1733: Scope component build context to its own subdirectory

[eliorerz]

Summary

Fixes a real bug found via the first actual end-to-end run of osac's new e2e workflows (PR #14) against the components array added in #283: the "Build and load component images" step's podman build (plus the OSAC-CLI go build and CRD-directory check next to it) used the whole component checkout as their working root. That's wrong for a monorepo caller — a components[] entry like {"containerfile": "fulfillment-service/Containerfile"} clones the entire osac-project/osac checkout, but the Containerfile, go.mod, cmd/, and config/crd/bases/ it needs all live under fulfillment-service/, not at the checkout root.

Confirmed failure on real infra

Both the vmaas and caas e2e runs on osac PR #14 failed with:

Error: building at STEP "COPY go.mod go.sum /opt/app-root/src/": checking on sources under ".../component-0-src": copier: stat: "/go.mod": no such file or directory

podman build was given the whole monorepo checkout as its context instead of the component's own subdirectory.

Fix

Derive a build_dir from the containerfile's directory (the same scoping already used in replace-installer-submodule.sh for the exact same reason) and use it for:

• the podman build/ansible-builder context and file path
• the OSAC CLI go build working directory
• the config/crd/bases CRD-directory check

Standalone (non-monorepo) callers are unaffected — build_dir falls back to the checkout root when containerfile has no directory component, so nothing changes for them.

Verification

• Functional scratch-directory test simulating a monorepo checkout confirms the Containerfile, go.mod, and CRD directory all resolve correctly under the scoped build_dir, and that the standalone case is unchanged.
• YAML parses cleanly for all three workflow files.
• pre-commit run --all-files passes (Docker-dependent shellcheck hook skipped, as in the companion OSAC-1733: Build multiple components from one checkout via a components array #283 work; ran local shellcheck directly on the extracted "Build and load component images" step instead — no issues).
• Applied identically to e2e-bmaas-full-install.yml, e2e-vmaas-full-install.yml, and e2e-caas-full-install.yml.

[openshift-ci-robot]

@eliorerz: This pull request references OSAC-1733 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

Fixes a real bug found via the first actual end-to-end run of osac's new e2e workflows (PR #14) against the components array added in #283: the "Build and load component images" step's podman build (plus the OSAC-CLI go build and CRD-directory check next to it) used the whole component checkout as their working root. That's wrong for a monorepo caller — a components[] entry like {"containerfile": "fulfillment-service/Containerfile"} clones the entire osac-project/osac checkout, but the Containerfile, go.mod, cmd/, and config/crd/bases/ it needs all live under fulfillment-service/, not at the checkout root.

Confirmed failure on real infra

Both the vmaas and caas e2e runs on osac PR #14 failed with:

Error: building at STEP "COPY go.mod go.sum /opt/app-root/src/": checking on sources under ".../component-0-src": copier: stat: "/go.mod": no such file or directory

podman build was given the whole monorepo checkout as its context instead of the component's own subdirectory.

Fix

Derive a build_dir from the containerfile's directory (the same scoping already used in replace-installer-submodule.sh for the exact same reason) and use it for:

• the podman build/ansible-builder context and file path
• the OSAC CLI go build working directory
• the config/crd/bases CRD-directory check

Standalone (non-monorepo) callers are unaffected — build_dir falls back to the checkout root when containerfile has no directory component, so nothing changes for them.

Verification

• Functional scratch-directory test simulating a monorepo checkout confirms the Containerfile, go.mod, and CRD directory all resolve correctly under the scoped build_dir, and that the standalone case is unchanged.
• YAML parses cleanly for all three workflow files.
• pre-commit run --all-files passes (Docker-dependent shellcheck hook skipped, as in the companion OSAC-1733: Build multiple components from one checkout via a components array #283 work; ran local shellcheck directly on the extracted "Build and load component images" step instead — no issues).
• Applied identically to e2e-bmaas-full-install.yml, e2e-vmaas-full-install.yml, and e2e-caas-full-install.yml.

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: 2 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: ba1a7974-96ff-42ae-935b-20f7fd98e36f

📥 Commits

Reviewing files that changed from the base of the PR and between 807de68 and 052a331.

📒 Files selected for processing (3)

• .github/workflows/e2e-bmaas-full-install.yml
• .github/workflows/e2e-caas-full-install.yml
• .github/workflows/e2e-vmaas-full-install.yml

---

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