fix(ci): mount real conditional policies in operator RBAC deployments [release-1.9] - #5441
gustavolira wants to merge 6 commits into
Conversation
create_conditional_policies_operator extracted the conditional policies from .upstream.backstage.initContainers in values_showcase-rbac.yaml, but that section was removed in February (redhat-developer#4162) when the policies moved to the static resources/config_map/conditional-policies.yaml. Since then the yq path resolves to null and every operator-based RBAC deployment (OCP, OSD, GKE, AKS, EKS) mounts an EMPTY conditional-policies.yaml, while Helm deployments mount the real file. With no conditional policies, test users lose their conditional catalog.entity read/update/delete grants: the RBAC role pages show 0 permissions and the catalog looks empty to them, which is exactly the failure mode of the rbac.spec.ts $currentUser, $ownerRefs and policyDecisionPrecedence tests in the gke-operator nightly (RHDHBUGS-3773 evidence trail). Align with main: always mount the static conditional-policies.yaml and drop the dead helper and its call sites. Also fix the default RBAC GitHub App env block: PRIVATE_KEY_RBAC was reading the CLIENT_SECRET secret (an app JWT can never be minted from that), and CLIENT_SECRET_RBAC was missing entirely. The defaults are used whenever the per-run prefix rotation finds an incomplete secret set, and then break GitHub discovery/bulk-import with 401s. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
/test ? |
|
/test e2e-gke-operator-nightly |
|
/test e2e-ocp-operator-nightly |
|
Validation run of showcase-rbac went from 8 failures (last nightly on release-1.9) to 2, and every test this PR targets now passes:
The 2 remaining failures are the known, independent Kubernetes plugin |
verifyPodLogs located the deployment's pod-count chip with a page-wide span[aria-label="Status ok"] nth(4). The page-wide chip count depends on what the cluster happens to contain and on the user's RBAC visibility; the current Kubernetes tab renders only 4 chips (2 on the cluster summary, 2 on the deployment), so nth(4) waits for a fifth chip that no longer exists and both kubernetes-rbac tests time out (RHDHBUGS-3775). Locate the chip inside the deployment's own accordion summary button instead, matched by its accessible name, so the assertion is unaffected by other resources appearing or disappearing. Verified against the accessibility snapshots (error-context.md) of the failed release-1.9-e2e-gke-operator-nightly runs: the scoped locator resolves in both the permitted and the restricted user scenarios. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
… accordion Review hardening: exact accessible-name matching, and filter the nested same-named buttons by the chip they must contain instead of taking the first DOM match. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Folded #5445 (the Kubernetes pod-status locator fix) into this PR so a single /test e2e-gke-operator-nightly |
|
The /test e2e-ocp-operator-nightly |
…r install install-rhdh-catalog-source.sh patches the cluster image registry and immediately reads the default-route, which OpenShift takes a few seconds to create — the known RHDHBUGS-3758 race that intermittently fails the operator install with 'routes.route.openshift.io "default-route" not found'. Expose the registry up front and wait for the route so the script's own read finds it; warn-only on timeout so the existing retry loop keeps its chance. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
/test e2e-ocp-operator-nightly |
The Route object existing is not enough: right after creation the router/registry data path can still refuse blob uploads (EOF on the operator bundle push, RHDHBUGS-3759). Poll the registry API through the route until it answers 200/401 before handing off to the install script. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…role 'Create and edit a role from the roles list page' intermittently fails with the Save button never appearing: the edit wizard's stepper re-renders between steps, so the single click on nextButton-2 can land on a stale node and silently not advance — the accessibility snapshot of the failed runs shows the wizard still on the permission-policies step showing Back/Next. The failure then cascades: test-role leaks past the test's own cleanup and breaks the GET-comparison and IsOwner tests. - RbacPo.advanceFromPermissionsToReview(): retry the Next click until the review step's Save button is visible/enabled (toPass), replacing the three copies of the blind click pattern. - Pre-clean role:default/test-role before creating it in the two tests that own it, so retries do not inherit a leaked role. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
/test e2e-ocp-operator-nightly |
|
|
The container image build workflow finished with status: |
|
@gustavolira: The following test failed, say
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. |
1 participant
Description
The
release-1.9showcase-rbacproject has been failing on operator-based nightlies (gke-operator et al.) with RBAC tests seeing 0 permissions and an empty catalog (RHDHBUGS-3773, RHDHBUGS-3538).Root cause
create_conditional_policies_operatorextracts the conditional policies from.upstream.backstage.initContainers[0].command[2]invalues_showcase-rbac.yaml— but that section was removed in February by #4162, which moved the policies to the staticresources/config_map/conditional-policies.yaml. Since then theyqpath resolves tonulland every operator RBAC deployment mounts an emptyconditional-policies.yaml(Helm deployments mount the real file, which is why helm RBAC passes).Without conditional policies, the test users lose their conditional
catalog.entityread/update/delete grants: role pages show 0 permissions and the catalog renders empty — exactly the$currentUser/$ownerRefs/policyDecisionPrecedencefailures in the nightly (verified against the 2026-09-18 gke-operator run artifacts).Fix
Backport main's behavior: always create the
rbac-policyConfigMap from the staticconditional-policies.yaml, and remove the dead helper plus its five call sites.Also fixes the default RBAC GitHub App env block in
env_variables.sh:GITHUB_APP_PRIVATE_KEY_RBACread the client secret (JWT minting can never succeed) andGITHUB_APP_CLIENT_SECRET_RBACwas missing. These defaults kick in whenever the per-run prefix rotation finds an incomplete secret set, then GitHub discovery/bulk-import fail with 401s.Verification
bash -non all touched scripts,yarn shellcheckandyarn prettier:checkgreen; no references to the removed helper remain.🤖 Generated with Claude Code