DPTP-5158: Move tls-scanner 5.0 periodics to a release-specific variant config - #83621
Conversation
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
openshift-ci
Bot
added
the
approved
|
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 ignored due to path filters (6)
📒 Files selected for processing (3)
💤 Files with no reviewable changes (1)
🚧 Files skipped from review as they are similar to previous changes (1)
Included review availability: Your plan provides up to 12 included reviews per hour; 11 remain after this review. WalkthroughThe change adds release-specific TLS Scanner periodic configurations for releases 5.0 and 5.1. It removes the previous 5.0 periodic definition and adds AWS, GCP, Azure, and bare-metal TLS 1.3 adherence tests. ChangesTLS Scanner periodic configurations
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to This change reorganizes release-specific periodic configuration and adds platform variants; no actionable merge-blocking risk remains beyond normal checks and review. Sequence Diagram(s)sequenceDiagram
participant PeriodicScheduler
participant TestCluster
participant TLSScanner
PeriodicScheduler->>TestCluster: Provision platform-specific cluster
TestCluster->>TLSScanner: Run TLS 1.3 adherence test
TLSScanner-->>PeriodicScheduler: Report periodic result
Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 15✅ Passed checks (15 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
|
/lgtm |
Sippy and Component Readiness only attribute periodic runs to a release when the jobs come from release-specific configuration. The 5.0 TLSAdherence periodic added by DPTP-5088 lived in the default release-5.0 config, which is owned by config-brancher (derived from main), so it was invisible to release dashboards and conflicted with every branching pass. Move it into openshift-tls-scanner-release-5.0__periodics.yaml per the variant periodics pattern, and add the gcp, azure, and metal adherence variants so all four platforms report into the 5.0 release view. Also add openshift-tls-scanner-release-5.1__periodics.yaml: 5.1 is now the active development release, and feature promotion tooling queries the latest development release, so the same four adherence periodics must report into the 5.1 view. The 5.1 jobs run at 24h (vs 72h for 5.0) to accumulate the 14 runs per variant required by the promotion checks within ~2 weeks.
f7553ad to
7ae227d
Compare
|
Note GitHub couldn't provide a complete incremental comparison for this pull request, so CodeRabbit is performing a full review instead. This review may take a little longer. |
|
[REHEARSALNOTIFIER]
Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: richardsonnick, smith-xyz 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 |
|
/pj-rehearse |
|
@richardsonnick: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse ack |
|
@richardsonnick: 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
|
/pj-rehearse |
|
@richardsonnick: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse ack |
|
@richardsonnick: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse cancel |
|
@richardsonnick: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@richardsonnick: job(s): cancel either don't exist or were not found to be affected, and cannot be rehearsed |
|
/pj-rehearse |
|
@richardsonnick: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
f90fd6d
into
openshift:main
|
@richardsonnick: The following tests 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. |
richardsonnick
changed the title
The periodic-tls13-adherence-* jobs (added via openshift/release#83621 and expanded in #83763) were never being ingested by Sippy: neither release's generated config listed them under jobs: or regexp:, so matchRelease() dropped every run before it reached the DB despite the jobs actually running on their 24h schedule. config/openshift.yaml is generated by sippy-config-generator and overwritten on every run, so the selectors are added to config/openshift-customizations.yaml, the overlay the generator reads for cases its auto-discovery misses (see config/README.md).
2 participants
Sippy and Component Readiness only attribute periodic runs to a release when the jobs come from release-specific configuration. The 5.0 TLSAdherence periodic added by DPTP-5088 lived in the default release-5.0 config, which is owned by config-brancher (derived from main), so it was invisible to release dashboards and conflicted with every branching pass.
Move it into openshift-tls-scanner-release-5.0__periodics.yaml per the variant periodics pattern, and add the gcp, azure, and metal adherence variants so all four platforms report into the 5.0 release view.
Summary by CodeRabbit