osac-operator: copy Helm charts into installer overlay for presubmit CI - #80893
Conversation
The osac-installer-with-pr image only copies config/ from the PR branch, but the umbrella Helm chart reads CRDs from charts/operator-crds/ and deployment templates from charts/operator/. Without this overlay, PRs that change CRD schemas (e.g. field renames) deploy the new operator binary against old CRDs, causing silent status update failures. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
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 (1)
WalkthroughA single ChangesOSAC Operator Installer Image Update
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[REHEARSALNOTIFIER]
Prior to this PR being merged, you will need to either run and acknowledge or opt to skip these rehearsals. Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
@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. |
|
FYI @zszabo-rh |
|
/lgtm |
|
/pj-rehearse ack |
|
@omer-vishlitzky: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: omer-vishlitzky, rgolangh 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 |
…CI (openshift#80893) The osac-installer-with-pr image only copies config/ from the PR branch, but the umbrella Helm chart reads CRDs from charts/operator-crds/ and deployment templates from charts/operator/. Without this overlay, PRs that change CRD schemas (e.g. field renames) deploy the new operator binary against old CRDs, causing silent status update failures. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…CI (openshift#80893) The osac-installer-with-pr image only copies config/ from the PR branch, but the umbrella Helm chart reads CRDs from charts/operator-crds/ and deployment templates from charts/operator/. Without this overlay, PRs that change CRD schemas (e.g. field renames) deploy the new operator binary against old CRDs, causing silent status update failures. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…CI (openshift#80893) The osac-installer-with-pr image only copies config/ from the PR branch, but the umbrella Helm chart reads CRDs from charts/operator-crds/ and deployment templates from charts/operator/. Without this overlay, PRs that change CRD schemas (e.g. field renames) deploy the new operator binary against old CRDs, causing silent status update failures. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…CI (openshift#80893) The osac-installer-with-pr image only copies config/ from the PR branch, but the umbrella Helm chart reads CRDs from charts/operator-crds/ and deployment templates from charts/operator/. Without this overlay, PRs that change CRD schemas (e.g. field renames) deploy the new operator binary against old CRDs, causing silent status update failures. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…CI (openshift#80893) The osac-installer-with-pr image only copies config/ from the PR branch, but the umbrella Helm chart reads CRDs from charts/operator-crds/ and deployment templates from charts/operator/. Without this overlay, PRs that change CRD schemas (e.g. field renames) deploy the new operator binary against old CRDs, causing silent status update failures. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…CI (openshift#80893) The osac-installer-with-pr image only copies config/ from the PR branch, but the umbrella Helm chart reads CRDs from charts/operator-crds/ and deployment templates from charts/operator/. Without this overlay, PRs that change CRD schemas (e.g. field renames) deploy the new operator binary against old CRDs, causing silent status update failures. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…CI (openshift#80893) The osac-installer-with-pr image only copies config/ from the PR branch, but the umbrella Helm chart reads CRDs from charts/operator-crds/ and deployment templates from charts/operator/. Without this overlay, PRs that change CRD schemas (e.g. field renames) deploy the new operator binary against old CRDs, causing silent status update failures. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…CI (openshift#80893) The osac-installer-with-pr image only copies config/ from the PR branch, but the umbrella Helm chart reads CRDs from charts/operator-crds/ and deployment templates from charts/operator/. Without this overlay, PRs that change CRD schemas (e.g. field renames) deploy the new operator binary against old CRDs, causing silent status update failures. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary
charts/from osac-operator PR branches into theosac-installer-with-primage so that CRD and Helm chart changes are tested in presubmit CIProblem
The
osac-installer-with-primage only copiesconfig/from the PR branch into the installer submodule path. The umbrella Helm chart reads CRDs fromcharts/operator-crds/and deployment templates fromcharts/operator/— not fromconfig/crd/bases/. This means PRs that change CRD schemas (e.g., renamingstatus.jobs→status.provisioningJobs) deploy the new operator binary against the old CRDs from the snapshot's submodule pin.The result: the API server silently strips unknown status fields, the operator can't persist job tracking state, and it enters an infinite reconcile loop launching hundreds of duplicate AAP jobs. All VirtualNetwork/Subnet/PublicIP tests fail with timeout.
Evidence from osac-operator PR #299:
unknown field "status.provisioningJobs"repeated 478 timesProgressingFix
Add one line to the Dockerfile literal:
COPY charts/ /installer/base/osac-operator/charts/This ensures
helm upgradeduring CI refresh picks up CRDs and deployment templates from the PR branch, not the stale submodule pin.Test plan
file://../../base/osac-operator/charts/operator-crdsandfile://../../base/osac-operator/charts/operatorcharts/operator-crds/is kept in sync withconfig/crd/bases/bymake helm-crds, enforced by CI (make check-helm-crds)🤖 Generated with Claude Code
Summary by CodeRabbit
This PR modifies the OpenShift CI build configuration for the osac-operator repository to fix test failures caused by schema version mismatches during PR validation.
Context: The CI infrastructure generates an
osac-installer-with-primage that overlays PR changes into the installer base image. When testing osac-operator PRs, the build was copying only theconfig/directory from the PR branch, but not thecharts/directory containing Helm chart resources. This created a critical issue: while the PR's new operator binary would be deployed, it would be run against stale CRD definitions from the base snapshot, causing the Kubernetes API server to strip unknown fields from status updates. This led to infinite reconciliation loops and cascading test failures.The fix: A single line was added to the Dockerfile configuration in
ci-operator/config/osac-project/osac-operator/osac-project-osac-operator-main.yamlto copy the charts directory into the installer overlay:COPY charts/ /installer/base/osac-operator/charts/Impact: This ensures that when the umbrella Helm chart runs
helm upgradeoperations during CI refresh, it picks up both CRD schemas and deployment templates from the PR branch, allowing the operator to be tested against the correct schema version. The charts directory is kept in sync withconfig/crd/bases/through an automatedmake helm-crdsprocess enforced by CI checks.Why it matters: Without this change, PRs that modify CRD schemas (such as renaming fields) cannot be properly validated in CI, leading to silent failures where the API server silently drops unknown fields, causing the operator to lose state and retry infinitely. This is particularly problematic for infrastructure-related resources like VirtualNetwork, Subnet, and PublicIP that are critical to cluster functionality.