OTA-1866: Add TLS scanner presubmit jobs to OSUS components#78981
Conversation
|
/test all |
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository YAML (base), Central YAML (inherited) Review profile: CHILL Plan: Enterprise Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (1)
WalkthroughAdds a tls-scanner base image and two optional TLS-scan CI integrations: an ChangesCincinnati-Operator TLS Scan
Cincinnati TLS Scan (olm-e2e)
Sequence Diagram(s)sequenceDiagram
participant CI as CI Job
participant Claim as Cluster Claim (ipi-aws)
participant Cluster as AWS OCP Cluster
participant Installer as operator-sdk / Bundle Installer
participant Operator as updateservice-operator
participant TLS as tls-scanner-run
CI->>Claim: request cluster (cluster_profile: openshift-org-aws)
Claim->>Cluster: provision cluster
CI->>Cluster: create namespace (install-osus-here / openshift-update-service)
CI->>Installer: run operator-sdk run bundle or start e2e job
Installer->>Cluster: deploy operator resources
Cluster->>Operator: start deployment
Operator->>Cluster: become Available
CI->>TLS: trigger tls-scanner-run (SCAN_NAMESPACE)
TLS->>Cluster: run scan against namespace
TLS-->>CI: report results
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 12✅ Passed checks (12 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
openshift-ci
Bot
added
the
approved
|
/pj-rehearse |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (1)
ci-operator/config/openshift/cincinnati-operator/openshift-cincinnati-operator-master.yaml (1)
119-133: ⚖️ Poor tradeoffDuplicated
installstep — consider extracting to a shared ref.The
installsub-step (lines 120–133) is an exact copy of the one already ininstall-bundle(lines 91–104). If the install logic ever changes (e.g., different operator-sdk flags, wait condition, or security context), both jobs will need to be updated in sync. Extracting it to a named ref (e.g.,cincinnati-operator-install) in the step registry would eliminate this drift risk.♻️ Sketch of the refactored test block
test: - - as: install - cli: latest - commands: | - oc create namespace install-osus-here - operator-sdk run bundle -n install-osus-here "$OO_BUNDLE" --security-context-config restricted - oc wait --for condition=Available -n install-osus-here deployment updateservice-operator - dependencies: - - env: OO_BUNDLE - name: cincinnati-bundle - from: operator-sdk - resources: - requests: - cpu: 500m - memory: 1000Mi + - ref: cincinnati-operator-install # shared ref extracted from install-bundle - ref: tls-scanner-run🤖 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 `@ci-operator/config/openshift/cincinnati-operator/openshift-cincinnati-operator-master.yaml` around lines 119 - 133, The install sub-step (the block with "as: install", "cli: latest", the operator-sdk run bundle/oc wait commands, dependency on OO_BUNDLE and resource requests) is duplicated; extract it to a named step ref (e.g., "cincinnati-operator-install") in your step registry and replace both occurrences with a reference to that ref, ensuring the ref contains the commands, dependencies (env: OO_BUNDLE, name: cincinnati-bundle), from: operator-sdk and resources entries so both places reuse the single source of truth.
🤖 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
`@ci-operator/config/openshift/cincinnati-operator/openshift-cincinnati-operator-master.yaml`:
- Around line 119-133: The install sub-step (the block with "as: install", "cli:
latest", the operator-sdk run bundle/oc wait commands, dependency on OO_BUNDLE
and resource requests) is duplicated; extract it to a named step ref (e.g.,
"cincinnati-operator-install") in your step registry and replace both
occurrences with a reference to that ref, ensuring the ref contains the
commands, dependencies (env: OO_BUNDLE, name: cincinnati-bundle), from:
operator-sdk and resources entries so both places reuse the single source of
truth.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: ce063e24-828f-466e-860d-fe32b272ddce
📒 Files selected for processing (2)
ci-operator/config/openshift/cincinnati-operator/openshift-cincinnati-operator-master.yamlci-operator/config/openshift/cincinnati/openshift-cincinnati-master.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- ci-operator/config/openshift/cincinnati/openshift-cincinnati-master.yaml
|
/pj-rehearse abort |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-openshift-cincinnati-operator-master-install-bundle-tls-scan |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-openshift-cincinnati-operator-master-install-bundle-tls-scan |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-openshift-cincinnati-operator-master-install-bundle-tls-scan |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-openshift-cincinnati-operator-master-install-bundle-tls-scan |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse ci/rehearse/openshift/cincinnati/master/olm-e2e-tls-scan |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@DavidHurta: job(s): ci/rehearse/openshift/cincinnati/master/olm-e2e-tls-scan either don't exist or were not found to be affected, and cannot be rehearsed |
|
/pj-rehearse ? |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse pull-ci-openshift-cincinnati-master-olm-e2e-tls-scan |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@DavidHurta: job(s): ? either don't exist or were not found to be affected, and cannot be rehearsed |
DavidHurta
force-pushed
the
add-tls-scanner-to-cincinnati
branch
2 times, most recently
from
59e9d9f to
17f7459
Compare
|
@coderabbitai resume |
✅ Actions performedReviews resumed. |
|
/pj-rehearse pull-ci-openshift-cincinnati-master-olm-e2e-tls-scan pull-ci-openshift-cincinnati-operator-master-install-bundle-tls-scan |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Add install-bundle-tls-scan test job to validate operator-only TLS configurations without Cincinnati deployment complexity. This provides targeted security validation of the operator's TLS profile running with PR changes. The test logic ensures that the component is applied in the cluster and is correctly running before proceeding to the TLS scan. Make the job optional and not run always. Currently, the tls-scanner step passes on failed tests, thus, no need to run on every run. Co-authored-by: Claude Code <claude@anthropic.com>
Add olm-e2e-tls-scan job to validate TLS configurations for Cincinnati update service running with PR changes. The test logic ensures that the component is applied in the cluster and is correctly running before proceeding to the TLS scan. Make the job optional and not run always. Currently, the tls-scanner step passes on failed tests, thus, no need to run on every run. Co-authored-by: Claude Code <claude@anthropic.com>
Otherwise, the jobs will fail due to limited resources. The job is optional and is not run always.
DavidHurta
force-pushed
the
add-tls-scanner-to-cincinnati
branch
from
ecf9a36 to
168d871
Compare
|
Rebased, rerun |
|
[REHEARSALNOTIFIER]
Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
@DavidHurta: 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. |
|
/pj-rehearse ack |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
openshift-merge-bot
Bot
added
the
rehearsals-ack
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: DavidHurta, wking 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 |
…t#78981) * feat(cincinnati-operator): Add isolated operator TLS scanning test Add install-bundle-tls-scan test job to validate operator-only TLS configurations without Cincinnati deployment complexity. This provides targeted security validation of the operator's TLS profile running with PR changes. The test logic ensures that the component is applied in the cluster and is correctly running before proceeding to the TLS scan. Make the job optional and not run always. Currently, the tls-scanner step passes on failed tests, thus, no need to run on every run. Co-authored-by: Claude Code <claude@anthropic.com> * feat(cincinnati): Add Cincinnati TLS scanning test Add olm-e2e-tls-scan job to validate TLS configurations for Cincinnati update service running with PR changes. The test logic ensures that the component is applied in the cluster and is correctly running before proceeding to the TLS scan. Make the job optional and not run always. Currently, the tls-scanner step passes on failed tests, thus, no need to run on every run. Co-authored-by: Claude Code <claude@anthropic.com> * fix(cincinnati): Use larger nodes for tls-scanner Otherwise, the jobs will fail due to limited resources. The job is optional and is not run always. * chore(cincinnati,cincinnati-operator): Update tls-scanner-tool version * Run `make update` --------- Co-authored-by: Claude Code <claude@anthropic.com>
3 participants
Add optional presubmit jobs for OSUS components to verify that the OSUS respects the centralized TLS configuration. The PR leverages existing e2e jobs to deploy the components and ensure that they are working correctly before proceeding to the TLS scanning. The introduction of these jobs will allow us in the future to run these tests as needed without the need to run the TLS-scanner manually.
Summary
This PR updates OpenShift CI configuration (openshift/release) for the OSUS components cincinnati and cincinnati-operator to add optional presubmit flows that run a TLS scanner after existing e2e deployment flows. The goal is to automatically validate that these components respect the centralized TLS configuration without changing runtime code.
Practical changes
A new tls-scanner-tool base image entry (namespace: ocp, name: "5.0", tag: tls-scanner-tool) was added to both:
cincinnati-operator:
cincinnati:
Behavior and rationale
Notable metadata