CM-1225: Run tls-13 before Feature:TLSProfile e2e in tls-scanner - #84731
openshift-merge-bot[bot] merged 1 commit into
Conversation
tls-13 enables the TLSAdherence feature gate. The e2e patches apiserver.spec.tlsAdherence, which kube-apiserver drops as unknown until that gate is on. Keep deploy-operand after the e2e so TrustManager is recreated for tls-scanner-run.
|
@arun717: This pull request references CM-1225 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.1.0" version, but no target version was set. 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. |
|
[REHEARSALNOTIFIER]
Prior to this PR being merged, you will need to either run and acknowledge or opt to skip these rehearsals. Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
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)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. WalkthroughThe ChangesTLS scanner test ordering
Estimated code review effort: 1 (Trivial) | ~5 minutes Merge Risk: ⚪ Minimal · up to The TLS scanner workflows now run tls-13 before the TLS profile test while retaining operand deployment before the scanner run. No current merge-blocking risk remains. Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
bharath-b-rh
left a comment
There was a problem hiding this comment.
/lgtm
/approve
/pj-rehearse ack
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: arun717, bharath-b-rh 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 |
|
@arun717: 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 |
|
@arun717: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
Summary
TLSAdherence(tls-13) beforetest-tls-profileon the cert-manager-operatortls-scannerjob.deploy-operandafter the e2e so TrustManager is recreated fortls-scanner-run.Why
#83643 moved
test-tls-profileahead of TrustManager deploy (to avoidAlreadyExists/ AfterEach deleting the CR before the scanner). That also placed the e2e beforetls-13.Feature:TLSProfilepatchesapiserver.spec.tlsAdherence. That field is feature-gated; withouttls-13kube-apiserver drops it (unknown field "spec.tlsAdherence") and the spec times out waiting for operand TLS args.Seen on openshift/cert-manager-operator#466:
Jira: https://redhat.atlassian.net/browse/CM-1225
Test plan
/pj-rehearse pull-ci-openshift-cert-manager-operator-master-tls-scanner(or wait for merge, then/test tls-scanneron cert-manager-operator#466)tls-13→test-tls-profile→deploy-operand→tls-scanner-runtls-13logsTLSAdherenceenabled before the e2e startsSummary by CodeRabbit
tls-scannerjobs.tls-13beforetest-tls-profile.deploy-operandbeforetls-scanner-runso TrustManager is recreated before scanning.