feat: enable pluginDivisionMode schema tests for OCP Operator nightly jobs

[Fortune-Ndlovu]

Description

• Enable pluginDivisionMode: schema E2E tests for OCP Operator deployments by wiring up the CI pipeline
  to deploy a real Crunchy PostgreSQL cluster and configure SCHEMA_MODE_* environment variables
• Replace placeholder database secrets ("tmp"/"tmp") in the operator runtime namespace with real Crunchy
  PostgreSQL credentials via configure_external_postgres_db
• Parameterize schema-mode-env.sh log messages to distinguish Helm vs Operator in CI output

Which issue(s) does this PR fix

• Fixes #? https://redhat.atlassian.net/browse/RHIDP-13221

PR acceptance criteria

Please make sure that the following steps are complete:

• GitHub Actions are completed and successful
• Unit Tests are updated and passing
• E2E Tests are updated and passing
• Documentation is updated if necessary (requirement for new features)
• Add a screenshot if the change is UX/UI related

How to test changes / Special notes to the reviewer

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

Context used

✅ Tickets: RHIDP-13221

1. Errexit breaks schema-mode skip 🐞 Bug ☼ Reliability

Description

configure_schema_mode_runtime_env runs an unguarded oc get pods inside command-substitution;
under the pipeline's set -o errexit this can terminate the entire job instead of returning 1 to
skip schema-mode tests. This becomes a real failure mode because ocp-operator.sh now invokes this
function during operator nightly runtime tests.

Code

.ci/pipelines/lib/schema-mode-env.sh[R73-76]

Relevance

⭐⭐⭐ High

Repo often guards noncritical oc/kubectl failures under errexit (e.g., || true) to allow opt-in
skips.

PR-#4288
PR-#3835
PR-#2397

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The top-level CI entrypoint enables errexit, so a non-zero exit from the oc get pods command
substitution in configure_schema_mode_runtime_env will exit the script before the caller’s `if
...; then ... else ... fi can handle the failure as an opt-in skip. ocp-operator.sh` now calls
this function as part of operator runtime tests, making this crash path newly reachable in operator
nightly jobs.

.ci/pipelines/openshift-ci-tests.sh[1-6]
.ci/pipelines/jobs/ocp-operator.sh[87-114]
.ci/pipelines/lib/schema-mode-env.sh[60-85]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`configure_schema_mode_runtime_env` uses `postgres_service=$(oc get pods ...)` without `|| true` / error handling. With `set -o errexit` enabled by the CI entrypoint, any transient `oc` failure will abort the whole job instead of letting the function return non-zero (so schema-mode tests can skip).

### Issue Context
This function is now called from the operator nightly runtime test path, so the failure mode will affect operator jobs.

### Fix Focus Areas
- .ci/pipelines/lib/schema-mode-env.sh[60-85]

### Suggested fix
Wrap the `oc get pods` assignment in a non-fatal form, e.g.:
- `postgres_service=$(oc get pods ... 2>/dev/null || true)` and keep the existing empty-string check, **or**
- `if ! postgres_service=$(oc get pods ... 2>/dev/null); then postgres_service=""; fi`

Also consider applying the same pattern to any other command substitutions that are meant to be “best-effort/opt-in” under errexit.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Transient PVC masks other failures 🐞 Bug ☼ Reliability ⭐ New

Description

KubeClient.checkPodFailureStates returns null as soon as it encounters a single
PodScheduled=False condition mentioning PVC creation, which exits the function and stops scanning
the remaining pods for real failure states. This can prevent waitForDeploymentReady from failing
fast on actual pod errors and instead only fail later via the overall timeout/diagnostics path.

Code

e2e-tests/playwright/utils/kube-client.ts[R606-615]

Relevance

⭐⭐⭐ High

Team prioritizes fail-fast pod failure detection in kube-client; similar reliability fixes accepted
(PR #3830, #4414).

PR-#3830
PR-#4414

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new return null is inside the nested pod/condition loops, so it returns from
checkPodFailureStates() immediately on the first transient scheduling message; meanwhile
waitForDeploymentReady() only throws when it receives a non-null string failure reason, so
early-null prevents fail-fast behavior even if later pods are failing for real reasons.

e2e-tests/playwright/utils/kube-client.ts[588-617]
e2e-tests/playwright/utils/kube-client.ts[731-754]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`checkPodFailureStates()` exits early (`return null`) when it sees a transient PVC-related scheduling message for *one* pod, which prevents it from detecting failures in other pods.

### Issue Context
This method is used by `waitForDeploymentReady()` to fail fast when pods are in terminal failure states.

### Fix Focus Areas
- e2e-tests/playwright/utils/kube-client.ts[588-617]
- e2e-tests/playwright/utils/kube-client.ts[731-754]

### Implementation notes
- Replace the transient branch’s `return null` with logic that *skips reporting failure for that pod* but continues scanning other pods.
- For example, set a `transientScheduling=true` flag for the current pod and `continue` the outer pod loop, or use a labeled `continue` to move to the next pod.
- Only return `null` after all pods have been evaluated and no non-transient failure has been found.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Operator schema secret mismatch 🐞 Bug ≡ Correctness

Description

Operator schema-mode tests may not apply schema-mode credentials to the running Operator deployment
because the Playwright schema-mode setup always updates <release>-postgresql, while the Operator
runtime CR injects DB env vars from postgres-cred. Since the setup only adds missing env vars
(does not override existing ones), the Operator deployment can keep using postgres-cred values for
host/user/password, reducing test correctness/coverage or causing unexpected failures.

Code

.ci/pipelines/jobs/ocp-operator.sh[R105-112]

Relevance

⭐⭐⭐ High

Team previously expanded schema-mode secret candidates to include postgres-cred; mismatch would
reduce coverage.

PR-#4288
PR-#2463
PR-#4649

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The operator runtime Backstage CR uses extraEnvs.secrets: postgres-cred to supply database env
vars. The schema-mode setup logic, however, updates a Helm-style secret name
${releaseName}-postgresql and only patches the Deployment when env vars are missing; it returns
early when vars already exist, meaning existing Operator-provided vars will not be redirected to the
schema-mode secret. Additionally, postgres-cred is explicitly created/populated by CI with
POSTGRES_HOST/USER/PASSWORD/..., making it likely these vars are already present and thus won’t be
overridden by schema-mode setup.

.ci/pipelines/jobs/ocp-operator.sh[103-112]
.ci/pipelines/resources/rhdh-operator/rhdh-start-runtime.yaml[27-43]
e2e-tests/playwright/e2e/plugin-division-mode-schema/schema-mode-setup.ts[46-176]
e2e-tests/playwright/e2e/plugin-division-mode-schema/schema-mode-setup.ts[178-214]
.ci/pipelines/utils.sh[202-226]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Schema-mode Playwright setup updates `${releaseName}-postgresql`, but the Operator deployment consumes DB env vars from `postgres-cred`. Because the setup only adds missing env vars (and does not override existing ones), Operator runs may continue using `postgres-cred` for key DB vars, making schema-mode operator coverage incorrect or flaky.

### Issue Context
This PR enables operator nightly schema-mode execution (`INSTALL_METHOD=operator` + schema-mode env auto-config). That makes this mismatch impactful for CI behavior.

### Fix Focus Areas
- e2e-tests/playwright/e2e/plugin-division-mode-schema/schema-mode-setup.ts[46-214]
- .ci/pipelines/resources/rhdh-operator/rhdh-start-runtime.yaml[27-43]

### Suggested fix options
**Option A (preferred):** In `SchemaModeTestSetup`, when `installMethod === "operator"`, update `postgres-cred` (using `POSTGRES_*` keys) instead of `${releaseName}-postgresql`, and ensure the deployment env vars point to `postgres-cred` (override if needed, not only add when missing).

**Option B:** Change the operator runtime CR to consume `${releaseName}-postgresql` instead of `postgres-cred` (so Helm and Operator converge on one secret name), and ensure CI creates/populates that secret consistently.

Either way, make sure the schema-mode user/password (`SCHEMA_MODE_DB_USER`/`SCHEMA_MODE_DB_PASSWORD`) are actually what the Operator deployment uses for DB connections during the test.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Previous review results

Review updated until commit 3dcb114

Results up to commit ec6a15d

🐞 Bugs (2) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. Errexit breaks schema-mode skip 🐞 Bug ☼ Reliability

Description

configure_schema_mode_runtime_env runs an unguarded oc get pods inside command-substitution;
under the pipeline's set -o errexit this can terminate the entire job instead of returning 1 to
skip schema-mode tests. This becomes a real failure mode because ocp-operator.sh now invokes this
function during operator nightly runtime tests.

Code

.ci/pipelines/lib/schema-mode-env.sh[R73-76]

Relevance

⭐⭐⭐ High

Repo often guards noncritical oc/kubectl failures under errexit (e.g., || true) to allow opt-in
skips.

PR-#4288
PR-#3835
PR-#2397

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The top-level CI entrypoint enables errexit, so a non-zero exit from the oc get pods command
substitution in configure_schema_mode_runtime_env will exit the script before the caller’s `if
...; then ... else ... fi can handle the failure as an opt-in skip. ocp-operator.sh` now calls
this function as part of operator runtime tests, making this crash path newly reachable in operator
nightly jobs.

.ci/pipelines/openshift-ci-tests.sh[1-6]
.ci/pipelines/jobs/ocp-operator.sh[87-114]
.ci/pipelines/lib/schema-mode-env.sh[60-85]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`configure_schema_mode_runtime_env` uses `postgres_service=$(oc get pods ...)` without `|| true` / error handling. With `set -o errexit` enabled by the CI entrypoint, any transient `oc` failure will abort the whole job instead of letting the function return non-zero (so schema-mode tests can skip).

### Issue Context
This function is now called from the operator nightly runtime test path, so the failure mode will affect operator jobs.

### Fix Focus Areas
- .ci/pipelines/lib/schema-mode-env.sh[60-85]

### Suggested fix
Wrap the `oc get pods` assignment in a non-fatal form, e.g.:
- `postgres_service=$(oc get pods ... 2>/dev/null || true)` and keep the existing empty-string check, **or**
- `if ! postgres_service=$(oc get pods ... 2>/dev/null); then postgres_service=""; fi`

Also consider applying the same pattern to any other command substitutions that are meant to be “best-effort/opt-in” under errexit.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Operator schema secret mismatch 🐞 Bug ≡ Correctness

Description

Operator schema-mode tests may not apply schema-mode credentials to the running Operator deployment
because the Playwright schema-mode setup always updates <release>-postgresql, while the Operator
runtime CR injects DB env vars from postgres-cred. Since the setup only adds missing env vars
(does not override existing ones), the Operator deployment can keep using postgres-cred values for
host/user/password, reducing test correctness/coverage or causing unexpected failures.

Code

.ci/pipelines/jobs/ocp-operator.sh[R105-112]

Relevance

⭐⭐⭐ High

Team previously expanded schema-mode secret candidates to include postgres-cred; mismatch would
reduce coverage.

PR-#4288
PR-#2463
PR-#4649

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The operator runtime Backstage CR uses extraEnvs.secrets: postgres-cred to supply database env
vars. The schema-mode setup logic, however, updates a Helm-style secret name
${releaseName}-postgresql and only patches the Deployment when env vars are missing; it returns
early when vars already exist, meaning existing Operator-provided vars will not be redirected to the
schema-mode secret. Additionally, postgres-cred is explicitly created/populated by CI with
POSTGRES_HOST/USER/PASSWORD/..., making it likely these vars are already present and thus won’t be
overridden by schema-mode setup.

.ci/pipelines/jobs/ocp-operator.sh[103-112]
.ci/pipelines/resources/rhdh-operator/rhdh-start-runtime.yaml[27-43]
e2e-tests/playwright/e2e/plugin-division-mode-schema/schema-mode-setup.ts[46-176]
e2e-tests/playwright/e2e/plugin-division-mode-schema/schema-mode-setup.ts[178-214]
.ci/pipelines/utils.sh[202-226]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Schema-mode Playwright setup updates `${releaseName}-postgresql`, but the Operator deployment consumes DB env vars from `postgres-cred`. Because the setup only adds missing env vars (and does not override existing ones), Operator runs may continue using `postgres-cred` for key DB vars, making schema-mode operator coverage incorrect or flaky.

### Issue Context
This PR enables operator nightly schema-mode execution (`INSTALL_METHOD=operator` + schema-mode env auto-config). That makes this mismatch impactful for CI behavior.

### Fix Focus Areas
- e2e-tests/playwright/e2e/plugin-division-mode-schema/schema-mode-setup.ts[46-214]
- .ci/pipelines/resources/rhdh-operator/rhdh-start-runtime.yaml[27-43]

### Suggested fix options
**Option A (preferred):** In `SchemaModeTestSetup`, when `installMethod === "operator"`, update `postgres-cred` (using `POSTGRES_*` keys) instead of `${releaseName}-postgresql`, and ensure the deployment env vars point to `postgres-cred` (override if needed, not only add when missing).

**Option B:** Change the operator runtime CR to consume `${releaseName}-postgresql` instead of `postgres-cred` (so Helm and Operator converge on one secret name), and ensure CI creates/populates that secret consistently.

Either way, make sure the schema-mode user/password (`SCHEMA_MODE_DB_USER`/`SCHEMA_MODE_DB_PASSWORD`) are actually what the Operator deployment uses for DB connections during the test.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[github-actions]

The container image build workflow finished with status: cancelled.

[Fortune-Ndlovu]

/test e2e-ocp-operator-nightly

[Fortune-Ndlovu]

/test e2e-ocp-helm-nightly

[rhdh-qodo-merge]

Review Summary by Qodo

(Agentic_describe updated until commit 3dcb114)

Enable pluginDivisionMode schema tests for OCP Operator with external PostgreSQL

✨ Enhancement 🧪 Tests

Walkthroughs

Description

• Enable pluginDivisionMode schema E2E tests for OCP Operator deployments
• Update secret handling to use operator-managed postgres-cred instead of patching Deployment
• Add retry logic for deployment restarts with transient PVC creation handling
• Wire up real Crunchy PostgreSQL and configure schema-mode environment variables
• Parameterize log messages to distinguish Helm vs Operator deployment methods

Diagram

flowchart LR
  A["OCP Operator Deployment"] -->|"configure external PostgreSQL"| B["Crunchy PostgreSQL Setup"]
  B -->|"create postgres-cred secret"| C["Schema Mode Test Setup"]
  C -->|"update secret instead of Deployment"| D["Avoid operator reconciliation conflicts"]
  D -->|"configure schema-mode env vars"| E["Enable E2E Tests"]
  E -->|"retry with PVC handling"| F["Deployment Restart"]

Loading

File Changes

1. e2e-tests/playwright/e2e/plugin-division-mode-schema/schema-mode-setup.ts ✨ Enhancement +36/-6

Operator-aware secret handling and restart retry logic

• Return postgres-cred secret name for operator deployments instead of ${releaseName}-postgresql
• Skip ensureDeploymentEnvVars() for operator since env vars are injected via extraEnvs.secrets in
 Backstage CR
• Add retry logic (up to 3 attempts) for deployment restart with 30s delays between attempts
• Handle transient PVC creation failures gracefully during restart

e2e-tests/playwright/e2e/plugin-division-mode-schema/schema-mode-setup.ts

---

2. e2e-tests/playwright/e2e/plugin-division-mode-schema/verify-schema-mode.spec.ts ✨ Enhancement +1/-1

Increase test timeout for external PostgreSQL setup

• Increase test timeout from 300s to 900s to accommodate external PostgreSQL setup and retry logic

e2e-tests/playwright/e2e/plugin-division-mode-schema/verify-schema-mode.spec.ts

---

3. e2e-tests/playwright/utils/kube-client.ts Error handling +11/-1

Handle transient PVC scheduling failures gracefully

• Detect transient PVC-related scheduling failures and return null instead of error
• Log transient PVC creation issues as informational messages
• Distinguish between transient (ephemeral volume/PVC) and permanent scheduling failures

e2e-tests/playwright/utils/kube-client.ts

---

View more (4)

4. .ci/pipelines/jobs/ocp-operator.sh ✨ Enhancement +43/-7

Wire up external PostgreSQL and schema-mode configuration

• Source schema-mode-env.sh library for schema-mode environment configuration
• Export INSTALL_METHOD=operator for correct deployment naming and test behavior
• Set up real external Crunchy PostgreSQL via configure_external_postgres_db in runtime tests
• Configure schema-mode environment variables with fallback to placeholder secrets
• Update dynamic plugins config file reference to values-showcase-postgres.yaml
• Add conditional schema-mode environment configuration based on PostgreSQL setup success

.ci/pipelines/jobs/ocp-operator.sh

---

5. .ci/pipelines/lib/schema-mode-env.sh ✨ Enhancement +7/-6

Parameterize log messages with install method

• Add install_method parameter (defaults to helm) to distinguish deployment types
• Replace hardcoded helm references in log messages with parameterized ${install_method}
• Update all log messages to show deployment method for better CI output clarity

.ci/pipelines/lib/schema-mode-env.sh

---

6. docs/e2e-tests/CI-medic-guide.md 📝 Documentation +1/-1

Update documentation for enabled operator schema tests

• Update OCP Operator nightly job documentation to reflect enabled runtime config tests
• Remove reference to [RHDHBUGS-2608](https://redhat.atlassian.net/browse/RHDHBUGS-2608) tracking issue for disabled operator tests
• Document that pluginDivisionMode schema tests now run with external Crunchy PostgreSQL

docs/e2e-tests/CI-medic-guide.md

---

7. e2e-tests/playwright/e2e/plugin-division-mode-schema/README.md 📝 Documentation +1/-1

Update schema-mode test documentation for operator support

• Update CI behavior documentation to reflect enabled schema tests for OCP Operator nightly jobs
• Remove reference to [RHDHBUGS-2608](https://redhat.atlassian.net/browse/RHDHBUGS-2608) tracking issue
• Document that tests now run with operator install method

e2e-tests/playwright/e2e/plugin-division-mode-schema/README.md

---

[github-actions]

Image was built and published successfully. It is available at:

• quay.io/rhdh-community/rhdh:pr-4685
• quay.io/rhdh-community/rhdh:pr-4685-8428bc4b

[Fortune-Ndlovu]

/test e2e-ocp-operator-nightly

[github-actions]

Image was built and published successfully. It is available at:

• quay.io/rhdh-community/rhdh:pr-4685
• quay.io/rhdh-community/rhdh:pr-4685-acfb7a8a

[Fortune-Ndlovu]

/test e2e-ocp-helm

[Fortune-Ndlovu]

/test e2e-ocp-operator-nightly

[github-actions]

Image was built and published successfully. It is available at:

• quay.io/rhdh-community/rhdh:pr-4685
• quay.io/rhdh-community/rhdh:pr-4685-6b2bf456

[Fortune-Ndlovu]

/test e2e-ocp-operator-nightly

[Fortune-Ndlovu]

/test e2e-ocp-helm-nightly

[github-actions]

The container image build and publish workflows were skipped (either due to [skip-build] tag or no relevant changes with existing image).

[Fortune-Ndlovu]

/review

[rhdh-qodo-merge]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

🎫 Ticket compliance analysis 🔶 RHIDP-13221 - Partially compliant Compliant requirements: Enable schema-mode tests for Operator-based OCP nightly jobs Wire CI pipeline to use a real Crunchy PostgreSQL cluster for schema-mode tests Configure SCHEMA_MODE_* environment variables for schema-mode tests (opt-in/skip behavior preserved) Non-compliant requirements: Add/enable E2E test coverage for pluginDivisionMode: schema for Operator-based OCP deployments (nightly CI context). Requires further human verification: Add/enable E2E test coverage for pluginDivisionMode: schema for Operator-based OCP deployments (nightly CI context). Wire CI pipeline to deploy/consume a real PostgreSQL instance (Crunchy PostgreSQL) for schema-mode tests. Configure the necessary SCHEMA_MODE_* environment variables so schema-mode tests can run (and skip when not configured).

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 Security concerns Potential secret exposure: configure_schema_mode_runtime_env exports database admin credentials into environment variables (SCHEMA_MODE_DB_ADMIN_PASSWORD). While this is common for CI, ensure downstream logging (e.g., Playwright debug output, set -x, or any env dumps) does not print these values. Additionally, oc patch secret ... -p "{...${runtime_url}...}" is safe, but verify no commands echo secret contents to logs.

⚡ Recommended focus areas for review Possible Issue The oc patch secret postgres-cred assumes the secret already exists in the runtime namespace. If configure_external_postgres_db fails, is delayed, or uses a different secret name, this patch will fail and may break the operator runtime flow. Consider validating existence (or creating it) before patching and/or failing fast with a clearer error. # Add RHDH_RUNTIME_URL to postgres-cred (configure_external_postgres_db doesn't include it, # but rds-app-config.yaml references it for app/backend baseUrl) local runtime_url="https://backstage-${RELEASE_NAME}-${NAME_SPACE_RUNTIME}.${K8S_CLUSTER_ROUTER_BASE}" oc patch secret postgres-cred -n "${NAME_SPACE_RUNTIME}" --type merge \ -p "{\"stringData\":{\"RHDH_RUNTIME_URL\":\"${runtime_url}\"}}" deploy_rhdh_operator "${NAME_SPACE_RUNTIME}" "${DIR}/resources/rhdh-operator/rhdh-start-runtime.yaml" "true" export INSTALL_METHOD=operator # Configure schema-mode environment (opt-in: tests skip if env not configured) if configure_schema_mode_runtime_env "${NAME_SPACE_RUNTIME}" "${RELEASE_NAME}" operator; then log::info "Schema-mode environment configured successfully; schema-mode tests will run" else log::warn "Schema-mode environment not configured; schema-mode tests will skip (this is expected if PostgreSQL is not available)" fi Naming/Config Risk Hard-coded/default resource names appear to use postgress-external-db / postgress-external-db-primary (note spelling). If the actual namespace/service/cluster name differs (or is spelled postgres-*), schema-mode auto-configuration will silently opt out and tests will skip. Consider aligning defaults with the real Crunchy deployment naming and/or making the service name configurable via env. local pdb="${NAME_SPACE_POSTGRES_DB:-postgress-external-db}" local crunchy_cluster="${SCHEMA_MODE_CRUNCHY_CLUSTER_NAME:-postgress-external-db}" if oc get svc postgress-external-db-primary -n "${pdb}" &> /dev/null; then forward_namespace="${pdb}" log::info "Schema-mode (${install_method}): no in-cluster Postgres Service in ${runtime_namespace}; using Crunchy cluster in ${pdb}" local crunchy_admin_secret="${crunchy_cluster}-pguser-janus-idp" if oc get secret "${crunchy_admin_secret}" -n "${pdb}" &> /dev/null; then admin_password=$(oc get secret "${crunchy_admin_secret}" -n "${pdb}" -o jsonpath='{.data.password}' 2> /dev/null | base64 -d || true) fi if [[ -z "${admin_password}" ]]; then log::warn "Schema-mode (${install_method}): could not read ${crunchy_admin_secret} password in ${pdb}; schema tests remain opt-in." return 1 fi postgres_service=$(oc get pods -n "${pdb}" \ -l "postgres-operator.crunchydata.com/cluster=${crunchy_cluster},postgres-operator.crunchydata.com/data=postgres" \ --field-selector=status.phase=Running \ -o jsonpath='{.items[0].metadata.name}' 2> /dev/null) if [[ -z "${postgres_service}" ]]; then log::warn "Schema-mode (${install_method}): no Running Postgres pod in ${pdb} for cluster ${crunchy_cluster}; schema tests remain opt-in." return 1 fi forward_via_pod=1 else log::warn "Schema-mode (${install_method}): PostgreSQL service not found in ${runtime_namespace} and no postgress-external-db-primary in ${pdb}; schema tests remain opt-in." return 1 fi CI Reliability testing::run_tests ... || true will mask failures (including schema-mode tests) and could undermine the goal of “enable tests” in nightly. If the intent is to keep the pipeline green, consider limiting the ignore-failure behavior or ensuring schema-mode failures are surfaced in a dedicated step/report. testing::run_tests "${RELEASE_NAME}" "${NAME_SPACE_RUNTIME}" "${PW_PROJECT_SHOWCASE_RUNTIME}" "${runtime_url}" || true }

📄 References No matching references available

[Fortune-Ndlovu]

/agentic_review

[rhdh-qodo-merge]

Persistent review updated to latest commit 68dfd51

[Fortune-Ndlovu]

/test e2e-ocp-operator-nightly

[Fortune-Ndlovu]

/test e2e-ocp-helm

[github-actions]

The container image build and publish workflows were skipped (either due to [skip-build] tag or no relevant changes with existing image).

[Fortune-Ndlovu]

/retest

[Fortune-Ndlovu]

/test e2e-ocp-operator-nightly

[Fortune-Ndlovu]

/test e2e-ocp-operator-nightly

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Fortune-Ndlovu]

/test e2e-ocp-operator-nightly

[zdrapela]

/lgtm

[Fortune-Ndlovu]

/test e2e-ocp-helm

[Fortune-Ndlovu]

/test e2e-ocp-helm-nightly

[Fortune-Ndlovu]

/override e2e-ocp-helm-nightly

[openshift-ci]

@Fortune-Ndlovu: Fortune-Ndlovu unauthorized: /override is restricted to Repo administrators, approvers in top level OWNERS file, and the following github teams:.

Details

In response to this:

/override e2e-ocp-helm-nightly

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 kubernetes-sigs/prow repository.

[Fortune-Ndlovu]

/test e2e-ocp-helm-nightly

[Fortune-Ndlovu]

/override e2e-ocp-helm

[openshift-ci]

@Fortune-Ndlovu: Fortune-Ndlovu unauthorized: /override is restricted to Repo administrators, approvers in top level OWNERS file, and the following github teams:.

Details

In response to this:

/override e2e-ocp-helm

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 kubernetes-sigs/prow repository.

[Fortune-Ndlovu]

/test e2e-ocp-helm

[Fortune-Ndlovu]

/test e2e-ocp-helm

[openshift-ci]

@Fortune-Ndlovu: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-ocp-helm-nightly	3dcb114	link	false	/test e2e-ocp-helm-nightly

Full PR test history. Your PR dashboard.

Details

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 kubernetes-sigs/prow repository. I understand the commands that are listed here.

[Fortune-Ndlovu]

/test e2e-ocp-helm

[Fortune-Ndlovu]

/test e2e-ocp-helm-nightly

[Fortune-Ndlovu]

/cherrypick release-1.1.0

[Fortune-Ndlovu]

/cherrypick release-1.10

[Fortune-Ndlovu]

/cherry-pick release-1.10

[openshift-cherrypick-robot]

@Fortune-Ndlovu: cannot checkout release-1.1.0: error checking out "release-1.1.0": exit status 1 error: pathspec 'release-1.1.0' did not match any file(s) known to git

Details

In response to this:

/cherrypick release-1.1.0

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 kubernetes-sigs/prow repository.

[openshift-cherrypick-robot]

@Fortune-Ndlovu: #4685 failed to apply on top of branch "release-1.10":

Applying: docs(ci): clarify operator runtime test deployment method
Applying: feat(e2e): enable pluginDivisionMode schema tests for OCP Operator nightly
Using index info to reconstruct a base tree...
M	.ci/pipelines/jobs/ocp-operator.sh
Falling back to patching base and 3-way merge...
Auto-merging .ci/pipelines/jobs/ocp-operator.sh
CONFLICT (content): Merge conflict in .ci/pipelines/jobs/ocp-operator.sh
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0002 feat(e2e): enable pluginDivisionMode schema tests for OCP Operator nightly

Details

In response to this:

/cherrypick release-1.10

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 kubernetes-sigs/prow repository.

[openshift-cherrypick-robot]

@Fortune-Ndlovu: #4685 failed to apply on top of branch "release-1.10":

Applying: docs(ci): clarify operator runtime test deployment method
Applying: feat(e2e): enable pluginDivisionMode schema tests for OCP Operator nightly
Using index info to reconstruct a base tree...
M	.ci/pipelines/jobs/ocp-operator.sh
Falling back to patching base and 3-way merge...
Auto-merging .ci/pipelines/jobs/ocp-operator.sh
CONFLICT (content): Merge conflict in .ci/pipelines/jobs/ocp-operator.sh
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0002 feat(e2e): enable pluginDivisionMode schema tests for OCP Operator nightly

Details

In response to this:

/cherry-pick release-1.10

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 kubernetes-sigs/prow repository.

[Fortune-Ndlovu]

/cherrypick release-1.10

[openshift-cherrypick-robot]

@Fortune-Ndlovu: #4685 failed to apply on top of branch "release-1.10":

Applying: docs(ci): clarify operator runtime test deployment method
Applying: feat(e2e): enable pluginDivisionMode schema tests for OCP Operator nightly
Using index info to reconstruct a base tree...
M	.ci/pipelines/jobs/ocp-operator.sh
Falling back to patching base and 3-way merge...
Auto-merging .ci/pipelines/jobs/ocp-operator.sh
CONFLICT (content): Merge conflict in .ci/pipelines/jobs/ocp-operator.sh
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config set advice.mergeConflict false"
Patch failed at 0002 feat(e2e): enable pluginDivisionMode schema tests for OCP Operator nightly

Details

In response to this:

/cherrypick release-1.10

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 kubernetes-sigs/prow repository.