MGMT-24194: add component installer step and workflow#78715
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@omer-vishlitzky: This pull request references MGMT-24194 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 story to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
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. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (4)
✅ Files skipped from review due to trivial changes (3)
WalkthroughAdds CI step-registry artifacts: a new installer component (commands script, step ref, and metadata/OWNERS) and a Packet-assisted baremetal workflow (workflow YAML, metadata/OWNERS) that composes pre/test/post step groups to run E2E OSAC tests with a PR-built component image override. ChangesInstaller Component Setup
Baremetal Component Workflow
Sequence Diagram(s)sequenceDiagram
autonumber
participant Runner as CI Runner
participant CI_Machine as ci_machine
participant Cluster as Target Cluster
participant Installer as Installer Container
Runner->>Runner: decode license -> /tmp/license.zip
Runner->>CI_Machine: scp /tmp/license.zip
Runner->>CI_Machine: ssh (remote shell, redacted output)
CI_Machine->>Cluster: set KUBECONFIG, annotate storageclass
CI_Machine->>Cluster: wait for kubevirt-hyperconverged
CI_Machine->>Cluster: apply OVN NetworkAttachmentDefinition
Runner->>CI_Machine: run podman installer container (mounts kubeconfig, pull-secret, license)
Installer->>Installer: rewrite overlay kustomization (newName/newTag, optional AAP_EE_IMAGE)
Installer->>Cluster: run /installer/scripts/setup.sh using mounted KUBECONFIG
Installer-->>Runner: exit status / logs (redacted)
Estimated Code Review Effort🎯 3 (Moderate) | ⏱️ ~25 minutes 🚥 Pre-merge checks | ✅ 12✅ Passed checks (12 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Review rate limit: 7/10 reviews remaining, refill in 17 minutes and 35 seconds. Comment |
openshift-merge-bot
Bot
added
the
rehearsals-ack
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@ci-operator/step-registry/osac-project/installer/component/osac-project-installer-component-commands.sh`:
- Around line 57-70: The script currently attempts to patch kustomization.yaml
but doesn't error if the target image entry "name: ${COMPONENT_IMAGE_NAME}" is
missing; add an explicit existence check before the sed blocks that greps for
"name: ${COMPONENT_IMAGE_NAME}" in kustomization.yaml and if not found call
process fail (exit 1) with a descriptive message so the job fails fast instead
of silently continuing; reference the existing variables and the
kustomization.yaml modification logic around the sed blocks that set
newName/newTag for COMPONENT_IMAGE_NAME, COMPONENT_REGISTRY and COMPONENT_TAG to
locate where to insert this check.
In
`@ci-operator/step-registry/osac-project/ofcir/baremetal/component/osac-project-ofcir-baremetal-component-workflow.yaml`:
- Around line 19-23: Update the workflow documentation to explicitly list the
required consumer inputs: callers must supply a dependency mapping named
"component-image" and set the environment variable "COMPONENT_IMAGE_NAME" (used
by the pre step that performs the image override), and note the expected
format/value (CI-built image reference) and failure behavior if omitted;
reference the workflow variant description and the pre step that performs the
override so consumers know to provide these inputs when invoking this variant.
🪄 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 YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 6560fc2a-6082-44ca-91cc-811e6e2af1b2
📒 Files selected for processing (7)
ci-operator/step-registry/osac-project/installer/component/OWNERSci-operator/step-registry/osac-project/installer/component/osac-project-installer-component-commands.shci-operator/step-registry/osac-project/installer/component/osac-project-installer-component-ref.metadata.jsonci-operator/step-registry/osac-project/installer/component/osac-project-installer-component-ref.yamlci-operator/step-registry/osac-project/ofcir/baremetal/component/OWNERSci-operator/step-registry/osac-project/ofcir/baremetal/component/osac-project-ofcir-baremetal-component-workflow.metadata.jsonci-operator/step-registry/osac-project/ofcir/baremetal/component/osac-project-ofcir-baremetal-component-workflow.yaml
| documentation: |- | ||
| This workflow executes the common end-to-end osac-test-infra test suite on a cluster | ||
| provisioned by running assisted-installer on a packet server. Unlike the base workflow, | ||
| this variant overrides a single component image with a CI-built version from a PR, | ||
| enabling E2E validation of component repo changes before merge. |
There was a problem hiding this comment.
Document required consumer inputs for this workflow variant.
The description says this overrides a component image, but it doesn’t state that consuming jobs must provide the component-image dependency mapping and COMPONENT_IMAGE_NAME. Without that, the pre step can fail or run without the intended override.
Suggested doc update
documentation: |-
This workflow executes the common end-to-end osac-test-infra test suite on a cluster
provisioned by running assisted-installer on a packet server. Unlike the base workflow,
this variant overrides a single component image with a CI-built version from a PR,
enabling E2E validation of component repo changes before merge.
+ Consuming jobs must map the `component-image` dependency and set `COMPONENT_IMAGE_NAME`
+ to the exact `name:` entry in `/installer/base/kustomization.yaml`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| documentation: |- | |
| This workflow executes the common end-to-end osac-test-infra test suite on a cluster | |
| provisioned by running assisted-installer on a packet server. Unlike the base workflow, | |
| this variant overrides a single component image with a CI-built version from a PR, | |
| enabling E2E validation of component repo changes before merge. | |
| documentation: |- | |
| This workflow executes the common end-to-end osac-test-infra test suite on a cluster | |
| provisioned by running assisted-installer on a packet server. Unlike the base workflow, | |
| this variant overrides a single component image with a CI-built version from a PR, | |
| enabling E2E validation of component repo changes before merge. | |
| Consuming jobs must map the `component-image` dependency and set `COMPONENT_IMAGE_NAME` | |
| to the exact `name:` entry in `/installer/base/kustomization.yaml`. |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@ci-operator/step-registry/osac-project/ofcir/baremetal/component/osac-project-ofcir-baremetal-component-workflow.yaml`
around lines 19 - 23, Update the workflow documentation to explicitly list the
required consumer inputs: callers must supply a dependency mapping named
"component-image" and set the environment variable "COMPONENT_IMAGE_NAME" (used
by the pre step that performs the image override), and note the expected
format/value (CI-built image reference) and failure behavior if omitted;
reference the workflow variant description and the pre step that performs the
override so consumers know to provide these inputs when invoking this variant.
New step-registry components for testing OSAC component repo PRs against the full E2E suite: - osac-project-installer-component: variant of the installer step that patches kustomize image tags to use CI-built component images - osac-project-ofcir-baremetal-component: workflow using the new step
omer-vishlitzky
force-pushed
the
MGMT-24194-step-registry-v2
branch
from
192bccb to
38a9e7a
Compare
openshift-ci
Bot
added
lgtm
omer-vishlitzky
force-pushed
the
MGMT-24194-step-registry-v2
branch
from
89cf855 to
822a0b5
Compare
|
/approve |
|
/lgtm |
omer-vishlitzky
force-pushed
the
MGMT-24194-step-registry-v2
branch
from
822a0b5 to
38a9e7a
Compare
|
[REHEARSALNOTIFIER] Note: If this PR includes changes to step registry files ( Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
| echo "************ osac-installer-component commands ************" | ||
| echo "--- Running with the following parameters ---" | ||
| echo "E2E_NAMESPACE: ${E2E_NAMESPACE}" | ||
| echo "E2E_KUSTOMIZE_OVERLAY: ${E2E_KUSTOMIZE_OVERLAY}" | ||
| echo "E2E_VM_TEMPLATE: ${E2E_VM_TEMPLATE}" | ||
| echo "OSAC_INSTALLER_IMAGE: ${OSAC_INSTALLER_IMAGE}" | ||
| echo "COMPONENT_IMAGE: ${COMPONENT_IMAGE}" | ||
| echo "COMPONENT_IMAGE_NAME: ${COMPONENT_IMAGE_NAME}" | ||
| echo "AAP_EE_IMAGE_OVERRIDE: ${AAP_EE_IMAGE_OVERRIDE:-}" |
There was a problem hiding this comment.
To truly test the components we need to import their up-to-date code as well and use it as the submodules
There was a problem hiding this comment.
https://github.com/openshift/release/pull/78716/changes#diff-839c036529a0e9487a73ea19a77185c047e760dc067deb3bf024386833287641R47-R58
here we build a modified osac-installer image: FROM osac-installer starts from the promoted baseline (all components at their pinned versions), then COPY config/ overlays the PR's
manifests over the osac-operator submodule. Lines 49-50 (of this file) build the PR's container image. The step registry in #78715 patches base/kustomization.yaml at runtime to point the image tag to
this CI-built image. So both the manifests and the running binary come from the PR, while everything else stays at the released versions.
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: danmanor, eranco74, jhernand, omer-vishlitzky The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift-ci
Bot
added
the
approved
|
/retest |
|
@omer-vishlitzky: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions 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 kubernetes-sigs/prow repository. I understand the commands that are listed here. |
5 participants
Summary
https://redhat.atlassian.net/browse/MGMT-24194
Adds shared CI infrastructure for running vmaas E2E tests on component repo PRs (fulfillment-service, osac-operator, osac-aap).
Why new step/workflow?
The existing
osac-project-installerstep deploys OSAC using the promoted osac-installer image, which pins component versions via kustomize image tags (e.g.,ghcr.io/osac-project/fulfillment-service:sha-f2cd619). When testing a component PR, we need the deployed cluster to run the PR's code, not the released version.The new
osac-project-installer-componentstep extends the existing one by patching the osac-installer image at runtime before deploying:base/kustomization.yaml— replaces the pinned SHA tag with the CI-built image from the PR, so the cluster deploys the PR's container imageAAP_EE_IMAGEin the overlay kustomization (osac-aap only) — so AAP runs playbooks using the PR's execution environment instead of the released oneNew components
osac-project-installer-component— acceptsCOMPONENT_IMAGE(CI-built image pull spec) andCOMPONENT_IMAGE_NAME(kustomize image name to replace), patches kustomization before runningsetup.shosac-project-ofcir-baremetal-component— identical toosac-project-ofcir-baremetalbut uses the new installer stepHow component repos use it
Each component repo's CI config builds two images:
Then the test definition overrides dependencies:
Test plan
Summary by CodeRabbit