OCPBUGS-86662: Optimize CPO deployment polling interval in tests of additional trust bundle propagation#8617
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: LGTM mode |
openshift-ci-robot
added
jira/severity-low
|
@YamunadeviShanmugam: This pull request references Jira Issue OCPBUGS-86662, which is valid. The bug has been moved to the POST state. 3 validation(s) were run on this bug
The bug has been updated to refer to the pull request using the external bug tracker. DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
Bot
added
area/testing
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughThis PR centralizes E2E test polling and timeout values by adding shared constants in test/e2e/nodepool_additionalTrustBundlePropagation_test.go and applying them to all related waits. It increases the NodePool condition wait in test/e2e/nodepool_test.go from 20 to 30 minutes. Dockerfile.e2e is updated to install azure-cli via dnf with added flags: --nobest and --setopt=install_weak_deps=False. 🚥 Pre-merge checks | ✅ 10 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (10 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 |
|
@YamunadeviShanmugam: This pull request references Jira Issue OCPBUGS-86662, which is valid. 3 validation(s) were run on this bug
DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
/pipeline required |
|
Scheduling tests matching the |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
test/e2e/nodepool_additionalTrustBundlePropagation_test.go (1)
137-137: ⚡ Quick winExtract hardcoded timeout to a constant for consistency.
Both locations use a hardcoded
5*time.Minutetimeout for user-ca-bundle operations, which is inconsistent with the PR's stated objective to "replace hardcoded time constraints with constants." Consider extracting this value asuserCABundleTimeoutin the const block (lines 57-62) and referencing it here.♻️ Suggested refactor
Add to the const block:
const ( nodePoolConfigUpdateStartTimeout = 5 * time.Minute nodePoolConfigUpdateFinishTimeout = 30 * time.Minute nodePoolConfigUpdatePollInterval = 15 * time.Second cpoDeploymentUpdateTimeout = 10 * time.Minute + userCABundleTimeout = 5 * time.Minute )Then update both call sites:
- e2eutil.WithInterval(nodePoolConfigUpdatePollInterval), e2eutil.WithTimeout(5*time.Minute), + e2eutil.WithInterval(nodePoolConfigUpdatePollInterval), e2eutil.WithTimeout(userCABundleTimeout),Also applies to: 219-219
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/e2e/nodepool_additionalTrustBundlePropagation_test.go` at line 137, Replace the hardcoded 5*time.Minute timeout used in e2eutil.WithTimeout calls with a named constant by adding userCABundleTimeout to the existing const block (currently containing other timeouts) and then change the e2eutil.WithTimeout(5*time.Minute) call sites (e.g., the call that currently uses e2eutil.WithInterval(nodePoolConfigUpdatePollInterval), e2eutil.WithTimeout(5*time.Minute)) to use e2eutil.WithTimeout(userCABundleTimeout) so both locations reference the new constant.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@test/e2e/nodepool_additionalTrustBundlePropagation_test.go`:
- Line 137: Replace the hardcoded 5*time.Minute timeout used in
e2eutil.WithTimeout calls with a named constant by adding userCABundleTimeout to
the existing const block (currently containing other timeouts) and then change
the e2eutil.WithTimeout(5*time.Minute) call sites (e.g., the call that currently
uses e2eutil.WithInterval(nodePoolConfigUpdatePollInterval),
e2eutil.WithTimeout(5*time.Minute)) to use
e2eutil.WithTimeout(userCABundleTimeout) so both locations reference the new
constant.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 1a09827c-9c36-47e4-8c0e-6753421c9155
📒 Files selected for processing (2)
test/e2e/nodepool_additionalTrustBundlePropagation_test.gotest/e2e/nodepool_test.go
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8617 +/- ##
=======================================
Coverage 41.43% 41.43%
=======================================
Files 756 756
Lines 93647 93647
=======================================
Hits 38802 38802
Misses 52124 52124
Partials 2721 2721
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Test Resultse2e-aws
e2e-aks
|
|
/pipeline required |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
Dockerfile.e2e (3)
1-35:⚠️ Potential issue | 🟠 Major | ⚡ Quick winHEALTHCHECK is missing.
No HEALTHCHECK directive is defined. Container orchestrators cannot determine container health without it. As per coding guidelines, "HEALTHCHECK defined."
🏥 Proposed fix to add HEALTHCHECK
Add at the end of the Dockerfile:
dnf install -y azure-cli-2.85.0-1.el9 && \ dnf clean all + +HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ + CMD ["/hypershift/bin/hypershift", "version"] || exit 1Note: Adjust the health check command based on the most appropriate validation for your e2e container.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile.e2e` around lines 1 - 35, The Dockerfile is missing a HEALTHCHECK directive; add a HEALTHCHECK at the end of the file that runs an appropriate lightweight check (for example invoking /hypershift/hack/ci-test-e2e.sh or /hypershift/bin/test-e2e with a quick status subcommand) using CMD-SHELL, and include sensible options like --interval=30s --timeout=10s --retries=3; ensure the referenced script/binary (ci-test-e2e.sh or test-e2e) is executable in the image and that the health command exits with 0 on success so container orchestrators can detect unhealthy containers.
1-35:⚠️ Potential issue | 🔴 Critical | ⚡ Quick winContainer runs as root - critical security violation.
No USER directive is specified. The container will run as root, which violates the security guideline. E2E test containers should run as a non-root user. As per coding guidelines, "USER non-root; never run as root."
🔒 Proposed fix to add non-root user
Add before the final RUN instruction:
COPY --from=builder /hypershift/hack/run-reqserving-e2e.sh /hypershift/hack/run-reqserving-e2e.sh +RUN useradd -m -u 1001 -s /bin/bash hypershift && \ + chown -R 1001:1001 /hypershift + +USER 1001 + RUN rpm --import https://packages.microsoft.com/keys/microsoft.asc && \🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile.e2e` around lines 1 - 35, The image currently runs as root because there's no USER directive; before the final RUN that installs packages (the RUN starting with "rpm --import ...") add commands to create a non-root user and group (e.g., create "hypershift" with a fixed UID/GID), chown the WORKDIR and copied bins (refer to WORKDIR /hypershift and the copied paths like /hypershift/bin and /hypershift/hack), and then set USER hypershift so the remaining layers run unprivileged; ensure the created user has a valid shell and ownership of /hypershift to allow the subsequent scripts (ci-test-e2e.sh, run-reqserving-e2e.sh) and binaries (test-e2e, hypershift, etc.) to be executable by that user.
10-12:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftBuild tools present in final image.
The final stage reuses the golang builder image, which includes the Go compiler and build toolchain. This violates the security guideline. Consider extracting only the necessary runtime dependencies or using a minimal base image for the final stage. As per coding guidelines, "Multi-stage builds; no build tools in final image."
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile.e2e` around lines 10 - 12, The final image currently reuses the full Go builder image (the FROM line referencing registry.ci.openshift.org/openshift/release:rhel-9-release-golang-1.25-openshift-4.23) which leaves build tools in the runtime image; change the Dockerfile to use a proper multi-stage build: keep a builder stage that compiles artifacts, then add a distinct final stage FROM a minimal runtime base (e.g., ubi-minimal or scratch/ubi) and COPY only the built binaries, configs and any runtime dependencies into that final stage; if ci-test-e2e.sh truly requires the go tool at runtime, either modify the script to avoid needing go or include only the minimal Go runtime binary/artifacts copied from the builder into the final stage rather than inheriting the entire builder image, and remove any leftover compiler/toolchain files so no build tools remain in the final image.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Dockerfile.e2e`:
- Line 33: Replace the current version-only dnf install of azure-cli (the line
installing "azure-cli-2.85.0-1.el9") with a digest-pinned workflow: download the
exact Microsoft RPM artifact for azure-cli-2.85.0-1.el9, verify its SHA256 (and
signature if available), install the verified local RPM (instead of installing
from repos), then lock the exact NEVRA with the package manager (e.g., dnf
versionlock) so the exact build is fixed; remove the plain "dnf install
azure-cli-2.85.0-1.el9" step and add a final step to re-run your
vulnerability/support scanner against that specific RPM build to record its
advisories.
---
Outside diff comments:
In `@Dockerfile.e2e`:
- Around line 1-35: The Dockerfile is missing a HEALTHCHECK directive; add a
HEALTHCHECK at the end of the file that runs an appropriate lightweight check
(for example invoking /hypershift/hack/ci-test-e2e.sh or
/hypershift/bin/test-e2e with a quick status subcommand) using CMD-SHELL, and
include sensible options like --interval=30s --timeout=10s --retries=3; ensure
the referenced script/binary (ci-test-e2e.sh or test-e2e) is executable in the
image and that the health command exits with 0 on success so container
orchestrators can detect unhealthy containers.
- Around line 1-35: The image currently runs as root because there's no USER
directive; before the final RUN that installs packages (the RUN starting with
"rpm --import ...") add commands to create a non-root user and group (e.g.,
create "hypershift" with a fixed UID/GID), chown the WORKDIR and copied bins
(refer to WORKDIR /hypershift and the copied paths like /hypershift/bin and
/hypershift/hack), and then set USER hypershift so the remaining layers run
unprivileged; ensure the created user has a valid shell and ownership of
/hypershift to allow the subsequent scripts (ci-test-e2e.sh,
run-reqserving-e2e.sh) and binaries (test-e2e, hypershift, etc.) to be
executable by that user.
- Around line 10-12: The final image currently reuses the full Go builder image
(the FROM line referencing
registry.ci.openshift.org/openshift/release:rhel-9-release-golang-1.25-openshift-4.23)
which leaves build tools in the runtime image; change the Dockerfile to use a
proper multi-stage build: keep a builder stage that compiles artifacts, then add
a distinct final stage FROM a minimal runtime base (e.g., ubi-minimal or
scratch/ubi) and COPY only the built binaries, configs and any runtime
dependencies into that final stage; if ci-test-e2e.sh truly requires the go tool
at runtime, either modify the script to avoid needing go or include only the
minimal Go runtime binary/artifacts copied from the builder into the final stage
rather than inheriting the entire builder image, and remove any leftover
compiler/toolchain files so no build tools remain in the final image.
🪄 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 YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 22f8217c-50b2-43f3-a324-993080a88d86
📒 Files selected for processing (1)
Dockerfile.e2e
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Dockerfile.e2e`:
- Around line 32-34: The final image's RUN that installs python3-pip (the shown
"RUN dnf install -y python3-pip && pip3 install --no-cache-dir azure-cli && dnf
clean all") must not leave build tools in runtime; move the pip installation and
"pip3 install --no-cache-dir azure-cli" into the builder stage, install
azure-cli there, then copy only the runtime artifacts (eg. /usr/local/bin/az and
the installed site-packages or relevant azure-cli files) into the final stage
and remove "python3-pip" and any pip invocation from the final stage's RUN so
the final image contains no build tools.
🪄 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 YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 415cdd0b-56f3-4f0e-95d4-eed965d53f02
📒 Files selected for processing (1)
Dockerfile.e2e
|
/pipeline required |
|
Scheduling tests matching the |
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 (2)
Dockerfile.e2e (2)
1-34:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd USER directive to run as non-root.
The Dockerfile does not set a USER directive, so the container runs as root by default. This violates the container security guideline requiring non-root execution.
🔒 Proposed fix
COPY --from=builder /hypershift/hack/ci-test-e2e.sh /hypershift/hack/ci-test-e2e.sh COPY --from=builder /hypershift/hack/run-reqserving-e2e.sh /hypershift/hack/run-reqserving-e2e.sh +RUN useradd -r -u 1001 -g root e2euser && \ + chown -R 1001:root /hypershift && \ + chmod -R g+rwX /hypershift + RUN rpm --import https://packages.microsoft.com/keys/microsoft.asc && \ dnf install -y https://packages.microsoft.com/config/rhel/9/packages-microsoft-prod.rpm && \ mv /etc/yum.repos.d/microsoft-prod.repo /etc/yum.repos.d/ci/ && \ dnf install -y azure-cli --setopt=install_weak_deps=False && \ dnf clean all +USER 1001 +As per coding guidelines, "USER non-root; never run as root".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile.e2e` around lines 1 - 34, The Dockerfile runs as root; create a non-root user and switch to it by adding steps in the final stage to create a dedicated user/group (e.g., "hypershift" or UID 1000), chown the application dirs and binaries under /hypershift (all files copied from builder, and /hypershift/bin and /hypershift/hack), set a sensible HOME, and add a USER directive (USER hypershift or USER 1000) before the image entrypoint; ensure any install steps that require root remain in the builder or are done before changing ownership so run-time does not require root.
1-34:⚠️ Potential issue | 🟠 Major | ⚡ Quick winAdd HEALTHCHECK directive.
The Dockerfile does not define a HEALTHCHECK, which is required by the container security guidelines. While this is an e2e test image (ephemeral workload), the guideline mandates a health check for all containers.
🏥 Proposed fix
USER 1001 +HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ + CMD ["/hypershift/bin/hypershift", "version"] || exit 1 +As per coding guidelines, "HEALTHCHECK defined".
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile.e2e` around lines 1 - 34, Add a HEALTHCHECK directive to the Dockerfile (at the end of the final image stage) so the container reports liveness; for example, add a line like HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3 CMD-SHELL "test -x /hypershift/bin/hypershift || exit 1" (or point it at an existing probe script such as /hypershift/hack/ci-test-e2e.sh if you prefer); ensure the directive is placed after the last RUN/COPY in the final stage so the image builds with the healthcheck baked in.
♻️ Duplicate comments (1)
Dockerfile.e2e (1)
33-33:⚠️ Potential issue | 🟠 Major | 🏗️ Heavy liftPin azure-cli by digest and version.
The azure-cli package is installed from a third-party (Microsoft) repository without digest or version pinning, violating the guideline that non-Red Hat images must be pinned by digest. This creates supply-chain and reproducibility risks.
As per coding guidelines, "non-RH images: pin by digest".
Run the following script to identify the exact azure-cli RPM and its digest/checksum:
#!/bin/bash # Description: Query the Microsoft repo for available azure-cli versions and checksums echo "=== Available azure-cli packages from Microsoft repo ===" # List recent azure-cli RPMs curl -s https://packages.microsoft.com/yumrepos/azure-cli/Packages/a/ | \ grep -oP 'href="azure-cli-[0-9]+\.[0-9]+\.[0-9]+-[0-9]+\.el9[^"]*"' | \ sed 's/href="//;s/"//' | sort -V | tail -10 echo "" echo "=== Example: Fetch SHA256 for a specific RPM ===" echo "# Download the RPM to compute its digest:" echo "# curl -sO https://packages.microsoft.com/yumrepos/azure-cli/Packages/a/azure-cli-VERSION.el9.x86_64.rpm" echo "# sha256sum azure-cli-VERSION.el9.x86_64.rpm"🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Dockerfile.e2e` at line 33, The Dockerfile currently installs "azure-cli" without pinning; replace the generic dnf install line that references azure-cli with a deterministic installation: download the exact azure-cli RPM for a specific version/release (azure-cli-VERSION.el9.x86_64.rpm) from the Microsoft repo, verify its SHA256 digest matches the pinned checksum, and then install that RPM (or install the exact package name including version-release) instead of the floating package; update the Dockerfile.e2e azure-cli install step to use the pinned version and checksum so the build is reproducible and supply-chain safe.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Dockerfile.e2e`:
- Line 33: Remove the --nobest flag from the dnf install invocation to avoid
silent downgrades; locate the RUN line that contains "dnf install -y azure-cli
--nobest --setopt=install_weak_deps=False" and change it to install azure-cli
without --nobest (keeping -y and --setopt=install_weak_deps=False), so
dependency conflicts surface as build failures instead of allowing older package
versions.
- Line 32: The mv command in Dockerfile.e2e currently moves microsoft-prod.repo
to a mistyped directory `/etc/yum.repos.art/ci/`; update the destination to the
correct yum repo directory `/etc/yum.repos.d/` (and ensure the target exists by
creating it with mkdir -p if your Dockerfile sequence might require it) so the
mv in the line showing "mv /etc/yum.repos.d/microsoft-prod.repo
/etc/yum.repos.art/ci/ && \" correctly places the repo file where dnf/yum will
find it.
---
Outside diff comments:
In `@Dockerfile.e2e`:
- Around line 1-34: The Dockerfile runs as root; create a non-root user and
switch to it by adding steps in the final stage to create a dedicated user/group
(e.g., "hypershift" or UID 1000), chown the application dirs and binaries under
/hypershift (all files copied from builder, and /hypershift/bin and
/hypershift/hack), set a sensible HOME, and add a USER directive (USER
hypershift or USER 1000) before the image entrypoint; ensure any install steps
that require root remain in the builder or are done before changing ownership so
run-time does not require root.
- Around line 1-34: Add a HEALTHCHECK directive to the Dockerfile (at the end of
the final image stage) so the container reports liveness; for example, add a
line like HEALTHCHECK --interval=30s --timeout=5s --start-period=10s --retries=3
CMD-SHELL "test -x /hypershift/bin/hypershift || exit 1" (or point it at an
existing probe script such as /hypershift/hack/ci-test-e2e.sh if you prefer);
ensure the directive is placed after the last RUN/COPY in the final stage so the
image builds with the healthcheck baked in.
---
Duplicate comments:
In `@Dockerfile.e2e`:
- Line 33: The Dockerfile currently installs "azure-cli" without pinning;
replace the generic dnf install line that references azure-cli with a
deterministic installation: download the exact azure-cli RPM for a specific
version/release (azure-cli-VERSION.el9.x86_64.rpm) from the Microsoft repo,
verify its SHA256 digest matches the pinned checksum, and then install that RPM
(or install the exact package name including version-release) instead of the
floating package; update the Dockerfile.e2e azure-cli install step to use the
pinned version and checksum so the build is reproducible and supply-chain safe.
🪄 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 YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: b7ce2411-ba0e-4ee7-aaf9-b439d9d0a716
📒 Files selected for processing (1)
Dockerfile.e2e
|
/test e2e-aws |
YamunadeviShanmugam
force-pushed
the
fix-e2e-tests-inconsistent-timeout-agressive-api-polling
branch
2 times, most recently
from
f312239 to
b7e4283
Compare
|
/approve |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jparrill, YamunadeviShanmugam 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 |
openshift-ci
Bot
added
the
approved
|
/lgtm |
|
Tests from second stage were triggered manually. Pipeline can be controlled only manually, until HEAD changes. Use command to trigger second stage. |
|
/pipeline required |
|
Scheduling tests matching the |
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
/verified by CI |
openshift-ci-robot
added
the
verified
|
@YamunadeviShanmugam: This PR has been marked as verified by DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
|
The optional CI jobs are failing due to the issue with payload |
|
/retest |
|
/retest |
|
/hold Revision 3b08f70 was retested 3 times: holding |
openshift-ci
Bot
added
the
do-not-merge/hold
|
/retest |
|
The analysis is complete. Both jobs failed with the identical infrastructure error. Here is my report: Test Failure Analysis CompleteJob Information
Test Failure AnalysisErrorSummaryBoth CI jobs ( Root CauseThe root cause is a stale release payload reference in the CI configuration. The CI job is configured to import two 4.22 release payloads:
The Key facts proving this is infrastructure/registry, not PR-related:
Recommendations
Evidence
|
|
/retest |
openshift-ci
Bot
removed
the
do-not-merge/hold
|
/retest |
|
@YamunadeviShanmugam: 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. |
|
@YamunadeviShanmugam: Jira Issue Verification Checks: Jira Issue OCPBUGS-86662 Jira Issue OCPBUGS-86662 has been moved to the MODIFIED state and will move to the VERIFIED state when the change is available in an accepted nightly payload. 🕓 DetailsIn response to this:
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 openshift-eng/jira-lifecycle-plugin repository. |
6 participants
This PR addresses inconsistent test timeouts in the trust bundle propagation tests. The root cause was aggressive API polling during the CPO deployment check, which lacked an explicit interval configuration and defaulted to the global 3s threshold.
By explicitly setting this check to 15s, we reduce API polling frequency by 5x, preventing API throttling
Summary by CodeRabbit