GitOps | Change cluster architecture#74377
GitOps | Change cluster architecture#74377varshab1210 wants to merge 10 commits intoopenshift:mainfrom
Conversation
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
/test all |
openshift-ci
Bot
added
the
approved
varshab1210
force-pushed
the
change-arch
branch
from
026d46a to
c1016e4
Compare
|
/test all |
|
/pj-rehearse |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/test all |
|
/pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-parallel |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/test all |
varshab1210
force-pushed
the
change-arch
branch
from
59ea828 to
ba975e9
Compare
|
/test all |
1 similar comment
|
/test all |
|
/pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-parallel |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-parallel |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-parallel |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
varshab1210
force-pushed
the
change-arch
branch
from
ba975e9 to
b76b18a
Compare
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: varshab1210 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 |
|
/test all /pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-parallel |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-parallel |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
varshab1210
force-pushed
the
change-arch
branch
from
b76b18a to
09fd9cf
Compare
Signed-off-by: Varsha B <vab@redhat.com>
Signed-off-by: Varsha B <vab@redhat.com>
Signed-off-by: Varsha B <vab@redhat.com>
Signed-off-by: Varsha B <vab@redhat.com>
Signed-off-by: Varsha B <vab@redhat.com>
varshab1210
force-pushed
the
change-arch
branch
from
fe4a54e to
7c4686a
Compare
WalkthroughAdds arm64 architecture support to CI configs and presubmit jobs; updates test environments to use arm64 release images; and augments operator installation steps with failure-handling that prints diagnostic YAML, pod listings/describes, operator logs, and recent namespace events before exiting on error. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 9 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (9 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yaml (1)
79-92: Confirm this diagnostic scaffolding is intentional for merge.Given the commit history (
diagnostic steps,more diagnostic step,pod diagnostics) and that this PR's stated goal is the arch change, much of this instrumentation looks like temporary debugging for the arm64 bring-up. If that's the case, please strip it (or move to a step-registry ref behind a flag) before un-drafting — otherwise every future failure will dump hundreds of lines of unrelated status into CI logs and make triage harder, not easier. If it's meant to stay, a short comment in the YAML explaining why would help future readers.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yaml` around lines 79 - 92, The diagnostic scaffolding (the operator install failure block that runs the operator-sdk run bundle command and the subsequent oc commands: oc get csv, oc get pods, oc describe pods, oc logs, oc get events) appears to be temporary debugging noise; either remove this entire failure dump before merging, or gate it behind a CI flag/step-registry ref (e.g., ENABLE_VERBOSE_DIAGS) and add a short YAML comment above the block explaining why it exists and when to enable it so future CI failures don’t always produce huge unrelated logs.
🤖 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/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yaml`:
- Around line 104-164: The diagnostic shell block is duplicated and should be
extracted into a reusable step-registry script (e.g. create
ci-operator/step-registry/gitops-operator/collect-diagnostics and expose it as a
step ref like gitops-operator/collect-diagnostics), then replace the duplicated
inline blocks in the kuttl-sequential `sequential-e2e-steps` and kuttl-parallel
`parallel-e2e-steps` (and the e2e test) with chain/ref to that step; inside the
extracted script remove the unused variable `container_state` (from where
`container_state=$(oc get pod ... .status.containerStatuses[0].state)` is set),
and fix the faulty check that compares `pod_phase` to container waiting reasons
by either removing the `CrashLoopBackOff`/`Error` comparisons against
`pod_phase` or switching that check to inspect `oc get pod -o
jsonpath='{.status.containerStatuses[*].state.waiting.reason}'` (keeping the
existing `ready_status != "True"` and `restart_count != "0"` checks).
---
Nitpick comments:
In
`@ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yaml`:
- Around line 79-92: The diagnostic scaffolding (the operator install failure
block that runs the operator-sdk run bundle command and the subsequent oc
commands: oc get csv, oc get pods, oc describe pods, oc logs, oc get events)
appears to be temporary debugging noise; either remove this entire failure dump
before merging, or gate it behind a CI flag/step-registry ref (e.g.,
ENABLE_VERBOSE_DIAGS) and add a short YAML comment above the block explaining
why it exists and when to enable it so future CI failures don’t always produce
huge unrelated logs.
🪄 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: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: b12409a7-fb97-4f5a-8a06-d09c74f0ee64
📒 Files selected for processing (2)
ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yamlci-operator/jobs/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master-presubmits.yaml
| echo "=== Manager pod is up, checking if operator is reconciling default instance ===" | ||
| sleep 10s | ||
| echo "=== Check openshift-gitops namespace ===" | ||
| oc get namespace openshift-gitops || echo "Namespace openshift-gitops does not exist yet" | ||
| echo "=== GitOpsService CR (should be created automatically) ===" | ||
| oc get gitopsservices -A -o yaml || echo "No GitOpsService CR found" | ||
| echo "=== ArgoCD CRs ===" | ||
| oc get argocds -A -o yaml || echo "No ArgoCD CRs found" | ||
| echo "=== All resources in openshift-gitops namespace ===" | ||
| oc get all -n openshift-gitops 2>/dev/null || echo "No resources in openshift-gitops namespace" | ||
| echo "=== Operator Manager Logs (checking for reconciliation activity) ===" | ||
| oc logs -n openshift-gitops-operator -l control-plane=gitops-operator -c manager --tail=100 || true | ||
| echo "=== Events in openshift-gitops-operator namespace ===" | ||
| oc get events -n openshift-gitops-operator --sort-by='.lastTimestamp' | tail -20 || true | ||
| echo "=== Events in openshift-gitops namespace (if exists) ===" | ||
| oc get events -n openshift-gitops --sort-by='.lastTimestamp' 2>/dev/null | tail -20 || echo "No events in openshift-gitops namespace" | ||
| echo "=== Pod Status with Wide Output ===" | ||
| oc get pods -n openshift-gitops -o wide || true | ||
| echo "=== Detailed Pod Status (Phase and Ready Condition) ===" | ||
| oc get pods -n openshift-gitops -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}Phase={.status.phase}{"\t"}Ready={.status.conditions[?(@.type=="Ready")].status}{"\t"}Reason={.status.conditions[?(@.type=="Ready")].reason}{"\t"}Message={.status.conditions[?(@.type=="Ready")].message}{"\n"}{end}' || true | ||
| echo "=== All Pod Conditions (to see why pods aren't Ready) ===" | ||
| for pod in $(oc get pods -n openshift-gitops -o jsonpath='{.items[*].metadata.name}'); do | ||
| echo "--- Conditions for pod: $pod ---" | ||
| oc get pod -n openshift-gitops $pod -o jsonpath='{range .status.conditions[*]}{.type}{": "}{.status}{" (Reason: "}{.reason}{", Message: "}{.message}{")\n"}{end}' || true | ||
| done | ||
| echo "=== Logs from ALL Pods (to identify why Running pods aren't Ready) ===" | ||
| for pod in $(oc get pods -n openshift-gitops -o jsonpath='{.items[*].metadata.name}'); do | ||
| pod_phase=$(oc get pod -n openshift-gitops $pod -o jsonpath='{.status.phase}' 2>/dev/null || echo "Unknown") | ||
| ready_status=$(oc get pod -n openshift-gitops $pod -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' 2>/dev/null || echo "Unknown") | ||
| echo "--- Logs from pod: $pod (Phase: $pod_phase, Ready: $ready_status) ---" | ||
| oc logs -n openshift-gitops $pod --all-containers=true --tail=100 || true | ||
| echo "" | ||
| done | ||
| echo "=== Checking ALL Pods for Issues (CrashLoopBackOff, Not Ready, or Error states) ===" | ||
| for pod in $(oc get pods -n openshift-gitops -o jsonpath='{.items[*].metadata.name}'); do | ||
| pod_phase=$(oc get pod -n openshift-gitops $pod -o jsonpath='{.status.phase}' 2>/dev/null || echo "Unknown") | ||
| ready_status=$(oc get pod -n openshift-gitops $pod -o jsonpath='{.status.conditions[?(@.type=="Ready")].status}' 2>/dev/null || echo "Unknown") | ||
| container_state=$(oc get pod -n openshift-gitops $pod -o jsonpath='{.status.containerStatuses[0].state}' 2>/dev/null || echo "Unknown") | ||
| restart_count=$(oc get pod -n openshift-gitops $pod -o jsonpath='{.status.containerStatuses[0].restartCount}' 2>/dev/null || echo "0") | ||
| echo "--- Checking pod: $pod (Phase: $pod_phase, Ready: $ready_status, Restarts: $restart_count) ---" | ||
| if [ "$pod_phase" = "CrashLoopBackOff" ] || [ "$pod_phase" = "Error" ] || [ "$ready_status" != "True" ] || [ "$restart_count" != "0" ]; then | ||
| echo ">>> Pod $pod has issues - gathering detailed diagnostics <<<" | ||
| echo "=== Full pod status (JSON) ===" | ||
| oc get pod -n openshift-gitops $pod -o json || true | ||
| echo "=== Describe pod: $pod ===" | ||
| oc describe pod -n openshift-gitops $pod || true | ||
| echo "=== Container Statuses with Detailed State for pod: $pod ===" | ||
| oc get pod -n openshift-gitops $pod -o jsonpath='{range .status.containerStatuses[*]}{.name}{":\n"}{" ready="}{.ready}{"\n"}{" restartCount="}{.restartCount}{"\n"}{" state="}{.state}{"\n"}{" lastState="}{.lastState}{"\n"}{end}' || true | ||
| echo "=== Container Waiting States (if any containers are waiting) ===" | ||
| oc get pod -n openshift-gitops $pod -o jsonpath='{range .status.containerStatuses[?(@.state.waiting)]}{.name}{": waiting - reason="}{.state.waiting.reason}{" message="}{.state.waiting.message}{"\n"}{end}' || echo "No containers in waiting state" | ||
| echo "=== Readiness Probe Status ===" | ||
| oc get pod -n openshift-gitops $pod -o jsonpath='{range .status.containerStatuses[*]}{.name}{": started="}{.started}{" ready="}{.ready}{"\n"}{end}' || true | ||
| echo "=== Init Container Statuses for pod: $pod ===" | ||
| oc get pod -n openshift-gitops $pod -o jsonpath='{range .status.initContainerStatuses[*]}{.name}{": "}{"ready="}{.ready}{" state="}{.state}{"\n"}{end}' || true | ||
| echo "=== Current Logs from pod: $pod (all containers) ===" | ||
| oc logs -n openshift-gitops $pod --all-containers=true --tail=200 || true | ||
| echo "=== Previous container logs (if crashed): $pod ===" | ||
| oc logs -n openshift-gitops $pod --all-containers=true --previous --tail=200 2>/dev/null || echo "No previous logs available" | ||
| echo "" | ||
| fi | ||
| done |
There was a problem hiding this comment.
Extract the duplicated diagnostic block into a step-registry ref.
Lines 104–164 (kuttl-sequential sequential-e2e-steps) and lines 216–276 (kuttl-parallel parallel-e2e-steps) are byte-identical ~60-line diagnostic preambles copy-pasted twice, and the e2e test at 297–298 would likely benefit from the same instrumentation. This is a lot of embedded shell that will drift out of sync on the next edit.
Consider moving it into a dedicated step under ci-operator/step-registry/ (e.g. gitops-operator/collect-diagnostics) and referencing it via chain/ref, matching the pattern used elsewhere (see ci-operator/step-registry/jobset/install/operator/jobset-install-operator-commands.sh). That also lets you gate it with || true at the step level and avoids embedding multi-hundred-line jsonpath strings inside YAML.
Minor cleanup inside the block while you're at it:
container_stateis assigned on lines 141 and 253 but never referenced.- The
CrashLoopBackOff/Errorcheck on lines 144/256 compares$pod_phaseagainst container-state strings — podphaseis only one ofPending|Running|Succeeded|Failed|Unknown.CrashLoopBackOffis a container waiting-reason, not a phase, so that branch never fires on phase. CheckcontainerStatuses[*].state.waiting.reason(or just rely on theready_status != "True"/restart_count != "0"conditions already there).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yaml`
around lines 104 - 164, The diagnostic shell block is duplicated and should be
extracted into a reusable step-registry script (e.g. create
ci-operator/step-registry/gitops-operator/collect-diagnostics and expose it as a
step ref like gitops-operator/collect-diagnostics), then replace the duplicated
inline blocks in the kuttl-sequential `sequential-e2e-steps` and kuttl-parallel
`parallel-e2e-steps` (and the e2e test) with chain/ref to that step; inside the
extracted script remove the unused variable `container_state` (from where
`container_state=$(oc get pod ... .status.containerStatuses[0].state)` is set),
and fix the faulty check that compares `pod_phase` to container waiting reasons
by either removing the `CrashLoopBackOff`/`Error` comparisons against
`pod_phase` or switching that check to inspect `oc get pod -o
jsonpath='{.status.containerStatuses[*].state.waiting.reason}'` (keeping the
existing `ready_status != "True"` and `restart_count != "0"` checks).
Signed-off-by: Varsha B <vab@redhat.com>
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
|
/pj-rehearse more |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
[REHEARSALNOTIFIER]
Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
@coderabbitai help |
ChatThere are 3 ways to chat with CodeRabbit:
CodeRabbit commands
Other keywords and placeholders
Status, support, documentation and community
|
|
/pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.14-kuttl-sequential |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
ci-operator/jobs/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master-presubmits.yaml (1)
512-512:⚠️ Potential issue | 🟠 MajorAsymmetric
optionalhandling between v4.14 and v4.19 presubmits.The v4.14 jobs
pull-ci-...-v4.14-e2e(Line 146),...-v4.14-kuttl-parallel(Line 287), and...-v4.14-kuttl-sequential(Line 372) are now alloptional: true, but the corresponding v4.19 jobs (Lines 512, 652, 736) remain required. Given that this PR flips these suites to arm64 for the first time (new release image, new architecture on thegitops-awscluster profile), the v4.19 jobs will block merges on any arm64 provisioning/install flake. If the arm64 switch is expected to be unstable enough on v4.14 to warrant marking it optional, the same likely applies to v4.19.Please either make the v4.19 e2e/kuttl-* jobs optional (matching v4.14) or explain why only v4.14 needs the relaxation.
Note: these
optionalflags are generated from the corresponding ci-operator config (redhat-developer-gitops-operator-master__v4.19.yamltest entries needoptional: true), not edited here directly.Also applies to: 652-652, 736-736
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/jobs/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master-presubmits.yaml` at line 512, The v4.19 presubmit jobs (pull-ci-redhat-developer-gitops-operator-master-v4.19-e2e, pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-parallel, pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-sequential) are currently required while the equivalent v4.14 jobs are optional; update the ci-operator config for the master v4.19 tests (redhat-developer-gitops-operator-master__v4.19.yaml) to set optional: true on those test entries so the generated presubmit YAML matches v4.14, or alternatively document why v4.19 must remain required if you intend to keep them blocking.
♻️ Duplicate comments (1)
ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yaml (1)
40-46:⚠️ Potential issue | 🔴 CriticalSame
workflow: ipi-awsvs arm64 release concern as in v4.14.Same pattern as in
redhat-developer-gitops-operator-master__v4.14.yaml:release:arm64-latest+OCP_ARCH: arm64is combined with the vanillaipi-awsworkflow andgitops-awscluster profile at Lines 112, 162, and 182. Please verify the installer actually picks arm64 node types under this workflow; otherwise the operator install will continue to fail on node/payload architecture mismatch.Also applies to: 66-72
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yaml` around lines 40 - 46, The arm64 release block releases.arm64-latest is being paired with workflow: ipi-aws and cluster_profile: gitops-aws while OCP_ARCH is set to arm64, which can cause node/payload architecture mismatch; update the pipeline to use an arm64-aware workflow or cluster profile (e.g., switch workflow: ipi-aws to an arm64 flavor such as ipi-aws-arm64 or change cluster_profile to an arm64-capable profile) or add explicit installer machineType/instanceProfile overrides so the installer provisions arm64 instance types; ensure the identifiers to update are releases.arm64-latest, OCP_ARCH, workflow: ipi-aws and cluster_profile: gitops-aws.
🧹 Nitpick comments (1)
ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.14.yaml (1)
165-185:e2etest has arm64 wiring but no failure diagnostics.The
e2esuite gets the same arm64capabilities/env/dependenciesas the kuttl suites, yet itse2e-stepscommand (scripts/openshiftci-presubmit-all-tests.sh) is not wrapped with the diagnostic gathering added to the kuttlinstallsteps. If the arm64 payload/node mismatch theory above is correct, this suite will hit the same install-time failures but produce less debug info. Consider running the same diagnostics (or, better, a shared step-registry ref — see the duplication comment) on e2e as well.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.14.yaml` around lines 165 - 185, The e2e suite (the block labeled "e2e" running the "e2e-steps" command that executes scripts/openshiftci-presubmit-all-tests.sh) lacks the diagnostic-gathering wrapper used by the kuttl install steps; update the e2e step to run the same diagnostic collection on failures (or refactor both kuttl install and e2e steps to call a shared step-registry entry) so that when arm64-related install failures occur you collect the same debug artifacts as the kuttl suites.
🤖 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/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.14.yaml`:
- Around line 40-46: Add arm64-specific AWS instance type environment variables
into the env sections for the three jobs kuttl-sequential, kuttl-parallel, and
e2e so the ipi-aws workflow provisions Graviton instances for the arm64 release;
specifically set CONTROL_PLANE_INSTANCE_TYPE (e.g., "m6g.xlarge") and
COMPUTE_NODE_TYPE (e.g., "g5g.2xlarge") under each job's env block when the
release candidate uses the arm64-latest / version "4.14" candidate so the
installer does not default to x86_64 EC2 types.
In
`@ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yaml`:
- Around line 62-65: The v4.19 job entries for the three tests
(kuttl-sequential, kuttl-parallel, and e2e) were changed to target arm64 but do
not include optional: true like the v4.14 equivalents; update each of the three
test blocks (the kuttl-sequential, kuttl-parallel, and e2e job definitions) to
add optional: true so they match v4.14 behavior (or alternatively add a short
comment/justification in those same blocks explaining why they must be
required), ensuring you modify the same three sections around the kuttl-* and
e2e job names.
---
Outside diff comments:
In
`@ci-operator/jobs/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master-presubmits.yaml`:
- Line 512: The v4.19 presubmit jobs
(pull-ci-redhat-developer-gitops-operator-master-v4.19-e2e,
pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-parallel,
pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-sequential) are
currently required while the equivalent v4.14 jobs are optional; update the
ci-operator config for the master v4.19 tests
(redhat-developer-gitops-operator-master__v4.19.yaml) to set optional: true on
those test entries so the generated presubmit YAML matches v4.14, or
alternatively document why v4.19 must remain required if you intend to keep them
blocking.
---
Duplicate comments:
In
`@ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yaml`:
- Around line 40-46: The arm64 release block releases.arm64-latest is being
paired with workflow: ipi-aws and cluster_profile: gitops-aws while OCP_ARCH is
set to arm64, which can cause node/payload architecture mismatch; update the
pipeline to use an arm64-aware workflow or cluster profile (e.g., switch
workflow: ipi-aws to an arm64 flavor such as ipi-aws-arm64 or change
cluster_profile to an arm64-capable profile) or add explicit installer
machineType/instanceProfile overrides so the installer provisions arm64 instance
types; ensure the identifiers to update are releases.arm64-latest, OCP_ARCH,
workflow: ipi-aws and cluster_profile: gitops-aws.
---
Nitpick comments:
In
`@ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.14.yaml`:
- Around line 165-185: The e2e suite (the block labeled "e2e" running the
"e2e-steps" command that executes scripts/openshiftci-presubmit-all-tests.sh)
lacks the diagnostic-gathering wrapper used by the kuttl install steps; update
the e2e step to run the same diagnostic collection on failures (or refactor both
kuttl install and e2e steps to call a shared step-registry entry) so that when
arm64-related install failures occur you collect the same debug artifacts as the
kuttl suites.
🪄 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: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: aa5a6d67-9e0a-4ec6-9e9a-cac120f448ae
📒 Files selected for processing (3)
ci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.14.yamlci-operator/config/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master__v4.19.yamlci-operator/jobs/redhat-developer/gitops-operator/redhat-developer-gitops-operator-master-presubmits.yaml
|
/pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.19-kuttl-sequential pull-ci-redhat-developer-gitops-operator-master-v4.14-kuttl-sequential |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@varshab1210: job(s): either don't exist or were not found to be affected, and cannot be rehearsed |
|
/pj-rehearse pull-ci-redhat-developer-gitops-operator-master-v4.14-kuttl-sequential |
|
@varshab1210: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@varshab1210: 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. |
2 participants
Summary by CodeRabbit
New Features
Improvements