refactor(e2e): refactor runtime tests into TypeScript

[zdrapela]

Goal

Consolidate SHOWCASE_RUNTIME_DB into SHOWCASE_RUNTIME — a single Playwright project that deploys RHDH from TypeScript (runtime-deploy.ts) and runs all runtime tests sequentially (workers: 1).

What the runtime tests actually test

All 4 test files are infrastructure-level tests that only need a basic RHDH instance up and serving the UI:

Test	What it validates
config-map.spec.ts	ConfigMap app.title change propagates after deployment restart
verify-schema-mode.spec.ts	RHDH boots with pluginDivisionMode: schema on a restricted (NOCREATEDB) DB user
verify-tls-config-with-external-rds.spec.ts	RHDH connects to 4 AWS RDS PostgreSQL versions over TLS
verify-tls-config-with-external-azure-db.spec.ts	RHDH connects to 4 Azure DB PostgreSQL versions over TLS

None exercise catalog, scaffolder, TechDocs, search, Kubernetes, ArgoCD, or any other domain-specific plugin. They only need guest auth and the core backend serving the UI.

Key changes

Single source of truth (runtime-config.ts)

All deployment configuration is generated from a single TypeScript module — no static YAML files. The same config produces both Helm values and Operator Backstage CR, ensuring the two install methods stay in sync.

• Helm path: generates values YAML as a temp file with only chart-default overrides + --set flags for image/cluster. Lightspeed disabled via global.lightspeed.enabled: false. PVC for dynamic-plugins-root persists plugins across restarts.
• Operator path: generates app-config ConfigMap, dynamic-plugins ConfigMap (includes: [], plugins: []), and Backstage CR programmatically. Lightspeed disabled via flavours: [].
• CATALOG_INDEX_IMAGE: opt-in override. Helm uses global.catalogIndex.image.* (matching CI's helm::get_image_params()); Operator pushes env var with containers: ["install-dynamic-plugins"]. When not set, chart/operator defaults apply.

Deployment moved from shell to TypeScript

CI scripts (ocp-nightly.sh, ocp-operator.sh) are reduced to thin wrappers that set env vars and invoke Playwright. All deployment logic lives in runtime-deploy.ts:

• ensureRuntimeDeployed() — idempotent, called from the first test's beforeAll
• Supports both Helm (helm upgrade -i) and Operator (Backstage CR) install methods
• Discovers PostgreSQL service/secret for schema-mode env vars
• External DB tests (postgres-config.ts) reconfigure the running instance at runtime

Shared utilities extracted

• resolveInstallMethod(), base64Encode/Decode() → helper.ts
• patchAppConfig(), restartDeploymentWithRetry(), jsonPatchDeployment() → KubeClient
• AppConfigYaml interface, ImageRef type, imageRefToString() → runtime-config.ts
• getDeploymentName() in schema-mode-setup now delegates to getRhdhDeploymentName()
• run(), discoverRouterBase() exported from runtime-deploy.ts

Files deleted (replaced by TypeScript generation)

• .ci/pipelines/resources/postgres-db/values-showcase-postgres.yaml → generated by generateHelmValuesYaml()
• .ci/pipelines/resources/postgres-db/rds-app-config.yaml → generated by generateAppConfigYaml()
• .ci/pipelines/resources/rhdh-operator/rhdh-start-runtime.yaml → generated by generateBackstageCR()

Jira: https://redhat.atlassian.net/browse/RHIDP-9140
Jira: https://redhat.atlassian.net/browse/RHIDP-9141

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[zdrapela]

/review

[zdrapela]

/test e2e-ocp-operator-nightly

[zdrapela]

/test e2e-ocp-v4-18-helm-nightly

[rhdh-qodo-merge]

PR Reviewer Guide 🔍

Warning

/review is deprecated. Use /agentic_review instead (removal date not yet scheduled).

Here are some key observations to aid the review process:

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

🧪 PR contains tests

🔒 Security concerns TLS verification disabled: .ci/pipelines/resources/rhdh-operator/rhdh-start-runtime-local.yaml sets NODE_TLS_REJECT_UNAUTHORIZED=0, which disables TLS certificate verification for Node.js. This weakens transport security and can hide real certificate/hostname problems. It should be avoided or tightly scoped to CI-only scenarios, preferring proper CA configuration (e.g., postgres-crt + NODE_EXTRA_CA_CERTS) instead.

⚡ Recommended focus areas for review Security The operator CR injects NODE_TLS_REJECT_UNAUTHORIZED=0, which disables TLS certificate verification for Node.js. This can mask real TLS issues in the external DB tests and is risky if it ever leaks beyond CI/test contexts. Consider removing it, scoping it to only the specific test pod/job that needs it, or relying on NODE_EXTRA_CA_CERTS/proper CA injection instead. envs: - name: NODE_TLS_REJECT_UNAUTHORIZED value: "0" secrets: - name: rhdh-runtime-config route: enabled: true # Disable all default flavours (e.g. lightspeed) to avoid unnecessary sidecar # containers and init containers that slow down startup and restarts. # Runtime tests don't need lightspeed — they only test ConfigMap changes and DB connectivity. flavours: []

📚 Focus areas based on broader codebase context Possible Issue prepareForExternalDatabase() patches app-config to set backend.database with only a connection block (host/port/user/password) and omits key fields like client, database (name), and any SSL configuration. This may leave runtime behavior dependent on whatever defaults/previous config exists, and can cause external DB tests to fail or be flaky depending on the base deployment config. (Ref 4) export async function prepareForExternalDatabase( kubeClient: KubeClient, namespace: string, deploymentName: string, ): Promise<void> { // --- 1. Remove stale POSTGRES_* env vars patched onto the deployment --- // Schema-mode tests may have added individual secretKeyRef env vars pointing // to a *-postgresql secret. These override the bulk envFrom injection from // postgres-cred and must be removed before external DB tests. await removeSchemaModePatchedEnvVars(kubeClient, deploymentName, namespace); // --- 2. Patch app-config ConfigMap to use external DB connection --- const configMapName = await kubeClient.findAppConfigMap(namespace); const configMapResponse = await kubeClient.getConfigMap( configMapName, namespace, ); const configMap = configMapResponse.body; const configKey = Object.keys(configMap.data || {}).find((key) => key.includes("app-config"), ); if (!configKey || !configMap.data) { throw new Error( `No app-config data key found in ConfigMap '${configMapName}'`, ); } const appConfig = yaml.load(configMap.data[configKey]) as AppConfigYaml; console.log( "Patching app-config to use external database connection (env var placeholders)...", ); appConfig.backend = appConfig.backend || {}; appConfig.backend.database = { connection: { host: "${POSTGRES_HOST}", port: "${POSTGRES_PORT}", user: "${POSTGRES_USER}", password: "${POSTGRES_PASSWORD}", }, }; configMap.data[configKey] = yaml.dump(appConfig); delete configMap.metadata?.creationTimestamp; delete configMap.metadata?.resourceVersion; await kubeClient.coreV1Api.replaceNamespacedConfigMap( configMapName, namespace, configMap, ); console.log("App-config patched for external database connection"); // --- 3. Add POSTGRES_* env vars to the deployment via secretKeyRef --- // The deployment starts with internal DB (no postgres-cred env vars). // Add individual env vars pointing to the postgres-cred secret so the // app-config ${POSTGRES_HOST} etc. placeholders resolve correctly. await ensurePostgresCredEnvVars(kubeClient, deploymentName, namespace); } Reference reasoning: The existing schema-mode setup shows a more complete and explicit backend.database config, including client: "pg", connection.database: "${POSTGRES_DB}", and ssl settings. Aligning the external-db patch to include these fields would make the external DB switch deterministic and consistent with how the repo configures DB connections elsewhere.

📄 References redhat-developer/rhdh/e2e-tests/playwright/e2e/external-database/verify-tls-config-with-external-crunchy.spec.ts [1-37] redhat-developer/rhdh/e2e-tests/playwright.config.ts [205-217] redhat-developer/rhdh/e2e-tests/playwright/e2e/plugin-division-mode-schema/verify-schema-mode.spec.ts [78-186] redhat-developer/rhdh/e2e-tests/playwright/e2e/plugin-division-mode-schema/schema-mode-setup.ts [27-354]

[zdrapela]

/agentic_review

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (4) 📘 Rule violations (0) 📎 Requirement gaps (0) 📜 Skill insights (0)

Context used

✅ Tickets: RHIDP-9140

1. KubeClient ignores env token 🐞 Bug ☼ Reliability

Description

KubeClient now calls loadFromDefault() and no longer builds a client config from
K8S_CLUSTER_URL/K8S_CLUSTER_TOKEN, so Playwright utilities may authenticate using the developer’s
current kubeconfig identity instead of the exported service-account token. This breaks
local-test-setup flows (and any environment relying on those env vars) with RBAC/permission failures
during namespace/deployment/configmap mutations.

Code

e2e-tests/playwright/utils/kube-client.ts[R123-129]

  constructor() {
    try {
      this.kc = new k8s.KubeConfig();
-      this.kc.loadFromOptions({
-        clusters: [
-          {
-            name: "my-openshift-cluster",
-            server: process.env.K8S_CLUSTER_URL,
-            skipTLSVerify: true,
-          },
-        ],
-        users: [
-          {
-            name: "ci-user",
-            token: process.env.K8S_CLUSTER_TOKEN,
-          },
-        ],
-        contexts: [
-          {
-            name: "default-context",
-            user: "ci-user",
-            cluster: "my-openshift-cluster",
-          },
-        ],
-        currentContext: "default-context",
-      });
+      this.kc.loadFromDefault();

      this.appsApi = this.kc.makeApiClient(k8s.AppsV1Api);
      this.coreV1Api = this.kc.makeApiClient(k8s.CoreV1Api);

Relevance

⭐⭐⭐ High

Recent work depends on exported K8S_CLUSTER_TOKEN for local/CI; likely to restore env-token auth. PR
4542.

PR-#4542
PR-#4023

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The local headed setup explicitly exports a fresh service-account token for tests, but does not
update kubeconfig with that token. With loadFromDefault(), KubeClient no longer uses the
exported token and will instead use the user’s existing kubeconfig identity, which can lack the
required permissions for runtime deployment and config patching.

e2e-tests/playwright/utils/kube-client.ts[123-131]
e2e-tests/local-test-setup.sh[98-121]

Agent prompt

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

## Issue description
`KubeClient` was changed to always use `kc.loadFromDefault()`, which ignores `K8S_CLUSTER_URL`/`K8S_CLUSTER_TOKEN`. The local headed workflow (`e2e-tests/local-test-setup.sh`) exports a fresh service-account token but does **not** log in / rewrite kubeconfig, so the TS code now runs as whatever user/context is already in kubeconfig and can fail on cluster-admin operations.

## Issue Context
The repo already provisions and exports `K8S_CLUSTER_URL`/`K8S_CLUSTER_TOKEN` specifically for test automation. `KubeClient` should keep supporting those env vars as the primary auth mechanism when present, and only fall back to default kubeconfig when they’re absent.

## Fix Focus Areas
- e2e-tests/playwright/utils/kube-client.ts[123-137]

### Concrete fix
- In `KubeClient` constructor:
 - If both `process.env.K8S_CLUSTER_URL` and `process.env.K8S_CLUSTER_TOKEN` are set, call `kc.loadFromOptions(...)` (the previous behavior) using those values.
 - Else, call `kc.loadFromDefault()`.
- Keep `skipTLSVerify: true` parity with the previous options-based config (or make it configurable if needed).

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

---

2. Duplicate plugin disable entries 🐞 Bug ≡ Correctness

Description

run_operator_runtime_config_change_tests() appends new dynamic-plugin entries with disabled: true
for GitHub/Keycloak modules, but those same packages already exist in the generated config (from
values_showcase.yaml) with disabled: false, creating conflicting duplicates. Depending on how
the dynamic plugin loader resolves duplicates, the plugins may remain enabled and still fail at
runtime due to missing configuration in the minimal runtime namespace.

Code

.ci/pipelines/jobs/ocp-operator.sh[R104-111]

+  # Disable plugins that require external configuration (GitHub org, Keycloak, etc.)
+  # not available in the minimal runtime namespace.
+  cat >> /tmp/configmap-dynamic-plugins-runtime.yaml << 'RUNTIME_PLUGINS_EOF'
+      - package: ./dynamic-plugins/dist/backstage-plugin-catalog-backend-module-github-dynamic
+        disabled: true
+      - package: ./dynamic-plugins/dist/backstage-community-plugin-catalog-backend-module-keycloak-dynamic
+        disabled: true
+RUNTIME_PLUGINS_EOF

Relevance

⭐⭐⭐ High

Team previously fixed CI issues from duplicate/Conflicting dynamic-plugin entries by adding
dedupe/override logic in values merging.

PR-#2417
PR-#4791

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The runtime dynamic-plugins ConfigMap is generated from values_showcase.yaml (per
HELM_CHART_VALUE_FILE_NAME) and that file already includes both packages with disabled: false;
the operator job then appends the same packages with disabled: true, resulting in duplicates with
conflicting flags.

.ci/pipelines/jobs/ocp-operator.sh[85-114]
.ci/pipelines/env_variables.sh[28-32]
.ci/pipelines/lib/config.sh[73-99]
.ci/pipelines/value_files/values_showcase.yaml[20-49]

Agent prompt

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

## Issue description
`ocp-operator.sh` generates the runtime `dynamic-plugins` ConfigMap from `values_showcase.yaml` (which already includes the GitHub + Keycloak catalog backend modules as `disabled: false`) and then appends *additional* entries for the same packages marked `disabled: true`. This produces conflicting duplicate entries for the same package and relies on unspecified “last one wins” behavior.

## Issue Context
- Runtime dynamic-plugins ConfigMap is produced from `.global.dynamic` in the base values file, so the runtime file already contains these plugin entries.
- Appending duplicates makes the effective state ambiguous and can result in the plugins still being enabled.

## Fix Focus Areas
- .ci/pipelines/jobs/ocp-operator.sh[103-112]
- .ci/pipelines/value_files/values_showcase.yaml[20-49]
- .ci/pipelines/env_variables.sh[28-31]
- .ci/pipelines/lib/config.sh[73-99]

## Suggested fix approach
1. After generating `/tmp/configmap-dynamic-plugins-runtime.yaml`, *edit* the YAML to set `disabled: true` for existing entries whose `.package` matches the two packages (use `yq`), rather than appending new list items.
2. Alternatively, generate runtime dynamic-plugins from a dedicated runtime values file (with those packages removed/disabled) instead of mutating the generated ConfigMap via `cat >>`.

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

---

3. PVC failures treated transient 🐞 Bug ☼ Reliability

Description

checkPodFailureStates() treats PodScheduled=False as transient when the condition message contains
the substring persistentvolumeclaim, which can match genuine unbound-PVC scheduling failures and
suppress fast-fail detection. This can convert real infra failures into long waits until the outer
deployment-ready timeout expires.

Code

e2e-tests/playwright/utils/kube-client.ts[R630-640]

+            // Ephemeral volume PVC provisioning causes a brief Unschedulable state
+            // that resolves once the PVC is created. Treat as transient, not fatal.
+            if (
+              condition.message?.includes("ephemeral volume controller") ||
+              condition.message?.includes("persistentvolumeclaim")
+            ) {
+              console.log(
+                `Pod ${podName} waiting for ephemeral volume provisioning (transient)`,
+              );
+              continue;
+            }

Relevance

⭐⭐ Medium

Repo favors fast-fail pod scheduling/startup errors, but no prior guidance on treating
'persistentvolumeclaim' as transient.

PR-#3830
PR-#4414

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new conditional explicitly continues (suppresses the error return) for any
PodScheduled=False with a message containing persistentvolumeclaim; since
waitForDeploymentReady() loops until timeout, this can delay failure reporting significantly.

e2e-tests/playwright/utils/kube-client.ts[623-642]
e2e-tests/playwright/utils/kube-client.ts[719-822]

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()` now considers any `PodScheduled=False` condition whose message contains `persistentvolumeclaim` as transient and continues waiting. This substring is broad and can match real scheduling failures (e.g., PVC never binds / no storage class), which should remain fast-fail.

## Issue Context
This logic runs inside `waitForDeploymentReady()`. When a real PVC bind failure is masked, the loop continues until the overall timeout, slowing CI feedback and making failures less actionable.

## Fix Focus Areas
- e2e-tests/playwright/utils/kube-client.ts[623-642]
- e2e-tests/playwright/utils/kube-client.ts[719-822]

## Suggested fix approach
- Restrict the transient condition to a more specific message pattern tied to ephemeral volume provisioning (e.g., match only `ephemeral volume controller`), OR
- Gate the transient path behind additional checks (e.g., only for pods known to use `ephemeral.volumeClaimTemplate`, or only for messages that explicitly indicate PVC creation is in progress), and keep other `persistentvolumeclaim` scheduling failures as fatal.

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

---

4. Runtime deploy reuses stale 🐞 Bug ☼ Reliability

Description

ensureRuntimeDeployed() skips deployment when it finds an existing Deployment with readyReplicas >=
1, but the CI wrappers no longer delete/recreate the runtime namespace before running the project.
This can cause reruns to execute against a previous job’s already-running image/config and return
misleading test results (false positives) or flaky behavior from leftover state.

Code

e2e-tests/playwright/utils/runtime-deploy.ts[R410-462]

+export async function ensureRuntimeDeployed(): Promise<void> {
+  if (deployed) {
+    console.log("Runtime deployment already completed in this process");
+    return;
+  }
+
+  const installMethod = resolveInstallMethod();
+  const routerBase =
+    process.env.K8S_CLUSTER_ROUTER_BASE || (await discoverRouterBase());
+
+  const config = resolveConfig(routerBase);
+  const { namespace, releaseName } = config;
+
+  console.log(
+    `\n=== Runtime deployment (${installMethod}) ===\n` +
+      `  namespace:    ${namespace}\n` +
+      `  releaseName:  ${releaseName}\n` +
+      `  routerBase:   ${routerBase}\n` +
+      `  image:        ${config.image.registry}/${config.image.repository}:${config.image.tag}\n` +
+      (config.catalogIndex
+        ? `  catalogIndex: ${imageRefToString(config.catalogIndex)}\n`
+        : `  catalogIndex: (chart/operator default)\n`),
+  );
+
+  const kubeClient = new KubeClient();
+
+  // Check if deployment already exists and is ready
+  const deploymentName = getRhdhDeploymentName();
+  try {
+    const dep = await kubeClient.appsApi.readNamespacedDeployment(
+      deploymentName,
+      namespace,
+    );
+    const ready = dep.body.status?.readyReplicas ?? 0;
+    if (ready >= 1) {
+      console.log(
+        `Deployment ${deploymentName} already running (${ready} ready replicas) — skipping deploy`,
+      );
+      deployed = true;
+      // Still configure schema-mode env if not already set
+      if (!process.env.SCHEMA_MODE_DB_ADMIN_PASSWORD) {
+        await configureSchemaMode(
+          kubeClient,
+          namespace,
+          releaseName,
+          installMethod,
+        );
+      }
+      return;
+    }
+  } catch {
+    // Deployment doesn't exist — proceed with fresh deploy
+  }

Relevance

⭐ Low

Team often rejects extra teardown/cleanup; idempotent reuse preferred. Similar cleanup request
rejected in PR 3987.

PR-#3987

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The TS deploy helper explicitly returns early when it sees a ready Deployment, and the nightly
runtime wrapper no longer performs any namespace cleanup before invoking Playwright. Together, that
makes runtime tests dependent on whatever is already running in the shared runtime namespace.

e2e-tests/playwright/utils/runtime-deploy.ts[410-462]
.ci/pipelines/jobs/ocp-nightly.sh[49-62]

Agent prompt

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

## Issue description
`ensureRuntimeDeployed()` treats an existing ready deployment as a no-op and returns early. After this PR, `.ci/pipelines/jobs/ocp-nightly.sh` and `.ci/pipelines/jobs/ocp-operator.sh` no longer clean the runtime namespace up-front, so reruns can silently reuse an old deployment (wrong image/tag, old ConfigMaps/Secrets, old DB state).

## Issue Context
Previously the wrapper scripts performed `namespace::configure` + uninstall/reinstall, ensuring a clean environment per CI run. That behavior is now effectively conditional on whether a prior deployment still exists and is ready.

## Fix Focus Areas
- e2e-tests/playwright/utils/runtime-deploy.ts[436-468]
- .ci/pipelines/jobs/ocp-nightly.sh[49-62]

### Concrete fix options
Pick one (preferred is A):

A) Default to clean deploy unless explicitly opted out:
- Add env var like `RUNTIME_DEPLOY_SKIP_IF_READY=true`.
- In CI, do not set it (so runtime deploy always deletes/recreates namespace).
- For local iteration, developers may set it to speed up runs.

B) Validate “same deployment” before skipping:
- If skipping, first verify deployed image tag matches `TAG_NAME` (and install method), otherwise redeploy.

Also consider: even when skipping deploy, still ensure required runtime test prerequisites exist (e.g., placeholder secrets) and set `BASE_URL` if missing.

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

---

[zdrapela]

/test e2e-ocp-helm-nightly

[github-actions]

The container image build workflow finished with status: cancelled.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 54.77%. Comparing base (8ba9f0e) to head (ac701b4).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4809      +/-   ##
==========================================
- Coverage   55.39%   54.77%   -0.62%     
==========================================
  Files         122      110      -12     
  Lines        2365     2147     -218     
  Branches      563      518      -45     
==========================================
- Hits         1310     1176     -134     
+ Misses       1048      970      -78     
+ Partials        7        1       -6     

Flag	Coverage Δ
rhdh	54.77% <ø> (-0.62%)	⬇️

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 8ba9f0e...ac701b4. Read the comment docs.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[zdrapela]

/test e2e-ocp-operator-nightly

[zdrapela]

/test e2e-ocp-helm-nightly

[github-actions]

The container image build workflow finished with status: cancelled.

[github-actions]

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

• quay.io/rhdh-community/rhdh:pr-4809
• quay.io/rhdh-community/rhdh:pr-4809-af1c9110

[zdrapela]

/retest

[zdrapela]

/test e2e-ocp-operator-nightly

[zdrapela]

/test e2e-ocp-helm-nightly

[github-actions]

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

• quay.io/rhdh-community/rhdh:pr-4809
• quay.io/rhdh-community/rhdh:pr-4809-91c4806c

[zdrapela]

/test e2e-ocp-helm-nightly

[zdrapela]

/test e2e-ocp-operator-nightly
/test e2e-ocp-helm-nightly

[github-actions]

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

• quay.io/rhdh-community/rhdh:pr-4809
• quay.io/rhdh-community/rhdh:pr-4809-ac701b4f

[openshift-ci]

@zdrapela: The following tests 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-operator-auth-providers-nightly	5c292df	link	false	/test e2e-ocp-operator-auth-providers-nightly
ci/prow/e2e-ocp-operator-nightly	ac701b4	link	false	/test e2e-ocp-operator-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.

[sonarqubecloud]

Quality Gate passed

Issues
2 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