o/release: bump some stray 4.22 occurences in 5.0 configs#77792
o/release: bump some stray 4.22 occurences in 5.0 configs#77792petr-muller wants to merge 1 commit intoopenshift:mainfrom
Conversation
I am not sure how these were missed in openshift@a7b9af3f67b051335f79a653e328 ad1db60cba27 because other envvars in the same file were apparently migrated just fine. I have validated that the tooling used (`generated-release-gating-jobs`) will not miss any occurrences in a hypothetical 5.0->5.1 pre-branching which feels like a sufficient assurrance that this omission should not repeat in the future.
WalkthroughUpdated CI environment variables in the nightly 5.0 OpenShift release configuration file. Changed Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes 🚥 Pre-merge checks | ✅ 10✅ Passed checks (10 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: petr-muller 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
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@ci-operator/config/openshift/release/openshift-release-main__nightly-5.0.yaml`:
- Line 1429: The T5CI_VERSION value "5.0" is incompatible with the telco5g step
scripts; either revert/set T5CI_VERSION back to "4.22" in the YAML or
concurrently update the step-registry scripts
(ci-operator/step-registry/telco5g/origin/tests/telco5g-origin-tests-commands.sh
and ci-operator/step-registry/telco5g/cnf/tests/telco5g-cnf-tests-commands.sh)
to handle "5.0" (add a new case in the version dispatch and adjust any
4.22-specific branch/image logic), and ensure the new branches/images are
covered in the same PR so jobs don’t hard-fail.
🪄 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: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 26309acb-5bd1-4fe6-9efa-046c5286d8e5
📒 Files selected for processing (1)
ci-operator/config/openshift/release/openshift-release-main__nightly-5.0.yaml
| env: | ||
| T5CI_JOB_TYPE: network-flow-matrix-bm | ||
| T5CI_VERSION: "4.22" | ||
| T5CI_VERSION: "5.0" |
There was a problem hiding this comment.
T5CI_VERSION: "5.0" is incompatible with current telco5g step scripts
This change can hard-fail these jobs. The current telco5g-origin-tests-commands.sh only has cases up to 4.22 and falls into Unsupported T5CI_VERSION for 5.0 (see ci-operator/step-registry/telco5g/origin/tests/telco5g-origin-tests-commands.sh, Line 116+). Additional 4.22-specific branch/image logic also exists in ci-operator/step-registry/telco5g/origin/tests/telco5g-origin-tests-commands.sh (Line 37+) and ci-operator/step-registry/telco5g/cnf/tests/telco5g-cnf-tests-commands.sh (Line 563+).
Please land/update those step-registry scripts in the same change (or keep this at 4.22 until they are updated) to avoid immediate job failures.
Suggested temporary guard (if script updates are not part of this PR)
- T5CI_VERSION: "5.0"
+ T5CI_VERSION: "4.22"
...
- T5CI_VERSION: "5.0"
+ T5CI_VERSION: "4.22"Also applies to: 1442-1442
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@ci-operator/config/openshift/release/openshift-release-main__nightly-5.0.yaml`
at line 1429, The T5CI_VERSION value "5.0" is incompatible with the telco5g step
scripts; either revert/set T5CI_VERSION back to "4.22" in the YAML or
concurrently update the step-registry scripts
(ci-operator/step-registry/telco5g/origin/tests/telco5g-origin-tests-commands.sh
and ci-operator/step-registry/telco5g/cnf/tests/telco5g-cnf-tests-commands.sh)
to handle "5.0" (add a new case in the version dispatch and adjust any
4.22-specific branch/image logic), and ensure the new branches/images are
covered in the same PR so jobs don’t hard-fail.
|
[REHEARSALNOTIFIER]
The following jobs are not rehearsable without the
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: |
|
/pj-rehearse periodic-ci-openshift-release-main-nightly-5.0-fips-payload-scan |
|
@petr-muller: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse network-access-allowed |
|
@petr-muller: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@petr-muller: PR author isn't allowed to allow network access rehearsals. This must be done by a different member of the |
that sounds dumb /pj-rehearse network-access-allowed |
|
@sosiouxme: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
/pj-rehearse periodic-ci-openshift-release-main-nightly-5.0-telco5g-network-flow-matrix-single-node-bm periodic-ci-openshift-release-main-nightly-5.0-telco5g-network-flow-matrix-bm |
|
@petr-muller: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@petr-muller: 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. |
2 participants
I am not sure how these were missed in a7b9af3f67b051335f79a653e328 because other envvars in the same file were apparently migrated just fine.
I have validated that the tooling used (
generated-release-gating-jobs) will not miss any occurrences in a hypothetical 5.0->5.1 pre-branching which feels like a sufficient assurrance that this omission should not repeat in the future.Summary by CodeRabbit