TRT-2506: Add OS version validation to prow job name test#30826
TRT-2506: Add OS version validation to prow job name test#30826petr-muller wants to merge 1 commit intoopenshift:mainfrom
Conversation
|
Pipeline controller notification For optional jobs, comment This repository is configured in: automatic mode |
openshift-ci-robot
added
the
jira/valid-reference
|
@petr-muller: This pull request references TRT-2506 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 "4.22.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. |
|
@petr-muller: This pull request references TRT-2506 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 "4.22.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. |
|
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:
WalkthroughAdds a test that validates job-name suffixes against detected RHEL OS version and a helper that identifies RHEL 10 by inspecting the worker MachineConfigPool's OSImageStream override or the cluster OSImageStreams DefaultStream; skips for MicroShift or missing CRD. Changes
Sequence Diagram(s)sequenceDiagram
participant TestRunner as Test Runner
participant Env as ENV (JOB_NAME)
participant ClusterAPI as Kubernetes API
participant MCP as MachineConfigPool (worker)
participant OSIS as OSImageStreams CR
TestRunner->>Env: read JOB_NAME
alt JOB_NAME unset
TestRunner->>TestRunner: skip test
else
TestRunner->>ClusterAPI: detect MicroShift
alt MicroShift
TestRunner->>TestRunner: skip test
else
TestRunner->>MCP: get worker MCP
MCP-->>TestRunner: MCP.osImageStreamOverride?
alt override present
TestRunner->>TestRunner: isRHCOS10 = (override == "rhel-10")
else
TestRunner->>OSIS: get singleton OSImageStreams
alt CRD exists
OSIS-->>TestRunner: DefaultStream
TestRunner->>TestRunner: isRHCOS10 = (DefaultStream == "rhel-10")
else
OSIS-->>TestRunner: CRD missing
TestRunner->>TestRunner: isRHCOS10 = false
end
end
TestRunner->>TestRunner: validate JOB_NAME contains expected "rhcos" fragment
alt validation fails
TestRunner->>TestRunner: fail with originalJobName message
else
TestRunner->>TestRunner: pass
end
end
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
/test ? |
|
[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
|
@petr-muller: This pull request references TRT-2506 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 "4.22.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. |
![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
🧹 Nitpick comments (1)
test/extended/machine_config/helpers.go (1)
167-168: Consider aligningskipOnRHEL10BeforeMar11with the same interface type.This helper still takes
*machineconfigclient.Clientset; usingmachineconfigclient.Interfacehere would keep the helper APIs consistent.♻️ Suggested consistency refactor
-func skipOnRHEL10BeforeMar11(machineConfigClient *machineconfigclient.Clientset, mcpName string) { +func skipOnRHEL10BeforeMar11(machineConfigClient machineconfigclient.Interface, mcpName string) { if IsRHEL10(machineConfigClient, mcpName) {🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/extended/machine_config/helpers.go` around lines 167 - 168, The helper skipOnRHEL10BeforeMar11 currently accepts a concrete *machineconfigclient.Clientset; change its first parameter to the interface machineconfigclient.Interface to match the other helpers and keep the API consistent, and update any calls passing a Clientset (which already implements machineconfigclient.Interface) to continue to work; ensure the IsRHEL10 function signature is compatible (it accepts machineconfigclient.Interface) and adjust imports if needed so skipOnRHEL10BeforeMar11(machineconfigclient.Interface, mcpName string) compiles.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@test/extended/ci/job_names.go`:
- Around line 186-188: The current substring check on jobName is too permissive;
update the logic in the validation block (the code that reads jobName and
originalJobName) to split jobName into tokens (e.g., strings.Split(jobName,
"-")) and then enforce that no token begins with "rhcos" unless that token is
exactly "rhcos9"; if any token startsWith "rhcos" and != "rhcos9" call e2e.Failf
with the same message using originalJobName. This ensures only an exact "rhcos9"
token is allowed and mixed/extended fragments are rejected.
---
Nitpick comments:
In `@test/extended/machine_config/helpers.go`:
- Around line 167-168: The helper skipOnRHEL10BeforeMar11 currently accepts a
concrete *machineconfigclient.Clientset; change its first parameter to the
interface machineconfigclient.Interface to match the other helpers and keep the
API consistent, and update any calls passing a Clientset (which already
implements machineconfigclient.Interface) to continue to work; ensure the
IsRHEL10 function signature is compatible (it accepts
machineconfigclient.Interface) and adjust imports if needed so
skipOnRHEL10BeforeMar11(machineconfigclient.Interface, mcpName string) compiles.
ℹ️ Review info
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Cache: Disabled due to data retention organization setting
Knowledge base: Disabled due to data retention organization setting
📒 Files selected for processing (2)
test/extended/ci/job_names.gotest/extended/machine_config/helpers.go
|
/payload-job periodic-ci-openshift-release-main-ci-4.22-e2e-azure-ovn-rhcos10-techpreview-serial |
|
@petr-muller: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/9ed573a0-16fa-11f1-9002-4371b3a38667-0 |
|
/test images |
1 similar comment
|
/test images |
|
/payload-job periodic-ci-openshift-release-main-ci-4.22-e2e-azure-ovn-rhcos10-techpreview-serial |
|
@petr-muller: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/28082b60-17cb-11f1-8193-85564dabd818-0 |
|
/pipeline required |
|
Scheduling required tests: |
test/extended/ci/job_names.go
Outdated
| e2eskipper.Skipf("JOB_NAME env var not set, skipping") | ||
| } | ||
|
|
||
| isRHCOS10 := machine_config.IsRHEL10(oc.MachineConfigurationClient(), "worker") |
There was a problem hiding this comment.
Having a look at how isRHEL10 is coded the check offer zero warranties of the pool to be running RHEL-10. In fact, the mcp can be perfectly pointing to an empty stream (that's allowed) and be running RHEL 10 if the global cluster stream is RHEL 10.
I suggest to use a different check, like checking the /etc/redhat-release of the nodes or the version reported in, iirc, the Node CR.
@isabella-janssen wrote the original code, any idea?
There was a problem hiding this comment.
Having a look at how isRHEL10 is coded the check offer zero warranties of the pool to be running RHEL-10. In fact, the mcp can be perfectly pointing to an empty stream (that's allowed) and be running RHEL 10 if the global cluster stream is RHEL 10.
I used the OSImageStream check for RHEL10 because this is a temporary function intended to be removed very soon (in OCPBUGS-77002 by next week) and for now I know (unless something has recently changed) that dual streams is being used to set up the RHEL10 env and, thus, the OSImageStream check in the MCP seemed sufficient for my need.
If this logic is to be extended to a more permanent functionality, I think the check could be
flowchart TD
A[Does the MCP have an OSImageStream value set?]
A -->|Yes| D[Use the OSImageStream value]
A -->|No| E[Check the cluster's default image stream]
or similar. The TLDR is that this function met the immediate need and was intended to be temporary.
There was a problem hiding this comment.
Thanks! I was also wondering about what is the best way to check RHEL10-ness, was a bit suspicious about the helper too, but wanted to run the change through the jobs to see if it is at least remotely viable. I'll spend more time checking what could be a good approach.
There was a problem hiding this comment.
@isabella-janssen @petr-muller One possible option is to check the reported OSImageStream status field of the MCPs, that should work is almost all cases (pools fully updated and not degraded).
The change merged yesterday: openshift/machine-config-operator#5689
There was a problem hiding this comment.
@pablintino I'm wondering whether I even need any MCP-level check at all. The TRT story intent is to make sure job names do match what is being tested, we basically care about cluster level, not individual MCP level. Which made me thought maybe I just need the default from OSImageStreams. But I guess we can have a default 9 there and then have a 10 in the MCP 🤔
Is there any obvious issue with current spec-based form that follows what @isabella-janssen suggested?
petr-muller
force-pushed
the
trt-2506-osversion-validate
branch
from
d700eb6 to
07a05d1
Compare
|
/payload-job periodic-ci-openshift-release-main-ci-4.22-e2e-azure-ovn-rhcos10-techpreview-serial |
|
@petr-muller: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/4d591770-17e5-11f1-83ae-271a2e285886-0 |
|
@petr-muller: This pull request references TRT-2506 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 "4.22.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. |
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 `@test/extended/ci/job_names.go`:
- Around line 181-185: Replace the slow exutil.IsMicroShiftCluster probe with a
one-shot ConfigMap existence check: remove the call to
exutil.IsMicroShiftCluster in test/extended/ci/job_names.go and instead perform
a single GET using oc.AdminKubeClient() to check for the MicroShift-specific
ConfigMap (e.g., the known MicroShift configmap in the kube-system namespace);
if the GET returns that the ConfigMap exists treat it as a MicroShift cluster
and call e2eskipper.Skipf("MicroShift clusters do not have MCPs or OSImageStream
resources, skipping"), otherwise continue; keep error handling for the GET and
ensure you do not poll or loop.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: e664c74e-2c77-4afc-9afc-0b2864c89ff6
📒 Files selected for processing (1)
test/extended/ci/job_names.go
|
/pipeline required |
|
Scheduling required tests: |
|
Risk analysis has seen new tests most likely introduced by this PR. New tests seen in this PR at sha: 07a05d1
|
petr-muller
force-pushed
the
trt-2506-osversion-validate
branch
from
07a05d1 to
4918a45
Compare
There was a problem hiding this comment.
♻️ Duplicate comments (1)
test/extended/ci/job_names.go (1)
186-194:⚠️ Potential issue | 🟠 MajorRHCOS9 path still allows invalid
rhcos*fragments.The non-RHCOS10 branch currently only rejects
rhcos10. Names like...-rhcos11or...-rhcosfoostill pass, which does not enforce the stated rule (“norhcos*fragment, or exactlyrhcos9”).🐛 Suggested tightening of token validation
clusterIsRHCOS10 := isRHCOS10(oc.MachineConfigurationClient()) jobIsRHCOS10 := strings.Contains(jobName, "rhcos10") + rhcosTokens := make([]string, 0, 1) + for _, token := range strings.Split(jobName, "-") { + if strings.HasPrefix(token, "rhcos") { + rhcosTokens = append(rhcosTokens, token) + } + } if clusterIsRHCOS10 && !jobIsRHCOS10 { e2e.Failf("cluster runs RHCOS10 so job name %q must contain 'rhcos10'", jobName) } - if !clusterIsRHCOS10 && jobIsRHCOS10 { - e2e.Failf("cluster does not run RHCOS10 so job name %q must not contain 'rhcos10')", jobName) + if !clusterIsRHCOS10 { + // RHCOS9: no rhcos token, or exactly one rhcos9 token. + if len(rhcosTokens) > 1 || (len(rhcosTokens) == 1 && rhcosTokens[0] != "rhcos9") { + e2e.Failf("job name %q contains an unexpected rhcos fragment for a cluster running RHCOS9", originalJobName) + } } })🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/extended/ci/job_names.go` around lines 186 - 194, The current check only rejects "rhcos10" but allows other "rhcos*" fragments; update the non-RHCOS10 branch to detect any "rhcos" fragment and fail unless it is exactly "rhcos9". Replace the simple strings.Contains(jobName, "rhcos10") check with a regexp search (e.g. match token pattern like `\brhcos[0-9]+\b` or `\brhcos[^\s-]+\b`) against jobName, then: when clusterIsRHCOS10 (isRHCOS10(...)) require the matched token == "rhcos10", otherwise if a token exists and token != "rhcos9" call e2e.Failf with the existing jobName message; reference variables/functions: jobName, clusterIsRHCOS10, isRHCOS10, and e2e.Failf.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@test/extended/ci/job_names.go`:
- Around line 186-194: The current check only rejects "rhcos10" but allows other
"rhcos*" fragments; update the non-RHCOS10 branch to detect any "rhcos" fragment
and fail unless it is exactly "rhcos9". Replace the simple
strings.Contains(jobName, "rhcos10") check with a regexp search (e.g. match
token pattern like `\brhcos[0-9]+\b` or `\brhcos[^\s-]+\b`) against jobName,
then: when clusterIsRHCOS10 (isRHCOS10(...)) require the matched token ==
"rhcos10", otherwise if a token exists and token != "rhcos9" call e2e.Failf with
the existing jobName message; reference variables/functions: jobName,
clusterIsRHCOS10, isRHCOS10, and e2e.Failf.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: c64571dc-9600-4f9e-9fc4-5f8846c69f39
📒 Files selected for processing (1)
test/extended/ci/job_names.go
|
@petr-muller: This pull request references TRT-2506 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 "4.22.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. |
There was a problem hiding this comment.
♻️ Duplicate comments (1)
test/extended/ci/job_names.go (1)
186-194:⚠️ Potential issue | 🟠 MajorNon-RHCOS10 validation is too permissive for
rhcos*fragments.On Line 192-Line 193, the check only rejects
rhcos10. It still allows invalid tokens likerhcos11, while the rule is “norhcos*token or exactlyrhcos9” for non-RHCOS10 clusters.🐛 Proposed fix
clusterIsRHCOS10 := isRHCOS10(oc.MachineConfigurationClient()) - jobIsRHCOS10 := strings.Contains(jobName, "rhcos10") + rhcosTokens := make([]string, 0, 1) + for _, token := range strings.Split(jobName, "-") { + if strings.HasPrefix(token, "rhcos") { + rhcosTokens = append(rhcosTokens, token) + } + } - if clusterIsRHCOS10 && !jobIsRHCOS10 { - e2e.Failf("cluster runs RHCOS10 so job name %q must contain 'rhcos10'", jobName) - } - if !clusterIsRHCOS10 && jobIsRHCOS10 { - e2e.Failf("cluster does not run RHCOS10 so job name %q must not contain 'rhcos10')", jobName) + if clusterIsRHCOS10 { + hasRHCOS10 := false + for _, token := range rhcosTokens { + if token == "rhcos10" { + hasRHCOS10 = true + break + } + } + if !hasRHCOS10 { + e2e.Failf("cluster runs RHCOS10 so job name %q must contain 'rhcos10'", jobName) + } + } else { + if len(rhcosTokens) > 1 || (len(rhcosTokens) == 1 && rhcosTokens[0] != "rhcos9") { + e2e.Failf("cluster does not run RHCOS10 so job name %q contains an unexpected rhcos fragment", jobName) + } }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/extended/ci/job_names.go` around lines 186 - 194, The current validation only detects "rhcos10" (jobIsRHCOS10) but permits other rhcos tokens (e.g., "rhcos11"); change the detection to look for any rhcos<N> token (use a regex or token scan on jobName, e.g. match `\brhcos(\d+)\b`) and then enforce: if clusterIsRHCOS10 then require the token equals "rhcos10", and if !clusterIsRHCOS10 then reject any rhcos token except allow exactly "rhcos9". Update the logic around isRHCOS10(oc.MachineConfigurationClient()), jobName and the checks that call e2e.Failf() to use this stricter rhcos token matching and comparison.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@test/extended/ci/job_names.go`:
- Around line 186-194: The current validation only detects "rhcos10"
(jobIsRHCOS10) but permits other rhcos tokens (e.g., "rhcos11"); change the
detection to look for any rhcos<N> token (use a regex or token scan on jobName,
e.g. match `\brhcos(\d+)\b`) and then enforce: if clusterIsRHCOS10 then require
the token equals "rhcos10", and if !clusterIsRHCOS10 then reject any rhcos token
except allow exactly "rhcos9". Update the logic around
isRHCOS10(oc.MachineConfigurationClient()), jobName and the checks that call
e2e.Failf() to use this stricter rhcos token matching and comparison.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository: openshift/coderabbit/.coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 5d3f078d-3b3f-4517-b520-6ad620478663
📒 Files selected for processing (1)
test/extended/ci/job_names.go
|
/payload-job periodic-ci-openshift-hypershift-release-4.22-periodics-e2e-aws-ovn-conformance kubernetes logo |
|
@petr-muller: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/726e5cf0-1966-11f1-9fd1-f13f9d24b5c1-0 |
|
/payload-job periodic-ci-openshift-hypershift-release-4.22-periodics-e2e-aws-ovn |
|
@petr-muller: trigger 1 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/a41eda40-1966-11f1-98bd-c5ae76f44315-0 |
|
/test ? |
|
/test e2e-hypershift-conformance |
|
/test ? |
|
/test e2e-aws-ovn-single-node-upgrade |
|
Risk analysis has seen new tests most likely introduced by this PR. New Test Risks for sha: 4abb04c
New tests seen in this PR at sha: 4abb04c
|
|
Risk analysis has seen new tests most likely introduced by this PR. New Test Risks for sha: 4abb04c
New tests seen in this PR at sha: 4abb04c
|
petr-muller
force-pushed
the
trt-2506-osversion-validate
branch
from
4abb04c to
bfe2752
Compare
|
/payload-job periodic-ci-openshift-release-main-ci-4.22-e2e-azure-ovn-rhcos10-techpreview-serial periodic-ci-openshift-hypershift-release-4.22-periodics-e2e-aws-ovn periodic-ci-openshift-hypershift-release-4.22-periodics-e2e-aws-ovn-conformance /test e2e-aws-ovn-single-node-upgrade |
|
/test ? |
|
@petr-muller: trigger 3 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/65402880-1bda-11f1-95e0-b8d60e1f1fcc-0 |
|
Scheduling required tests: |
petr-muller
force-pushed
the
trt-2506-osversion-validate
branch
from
bfe2752 to
2024332
Compare
|
/payload-job periodic-ci-openshift-release-main-ci-4.22-e2e-azure-ovn-rhcos10-techpreview-serial periodic-ci-openshift-hypershift-release-4.22-periodics-e2e-aws-ovn periodic-ci-openshift-hypershift-release-4.22-periodics-e2e-aws-ovn-conformance /test e2e-aws-ovn-single-node-upgrade /pipeline required |
|
Scheduling required tests: |
|
@petr-muller: trigger 3 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/80787e30-1bef-11f1-97b2-b244f75538a3-0 |
Ensure CI job names reflect the node OS version: RHCOS 10 clusters must have "rhcos10" in the job name and non-RHCOS10 must not. Detect RHEL 10 by checking the worker MCP's OSImageStream setting, falling back to the cluster-wide default stream from the OSImageStream v1alpha1 singleton when the MCP does not specify one. Currently we do not have HyperShift/MicroShift RHCOS10 jobs and it is still unknown how to check these clusters. The test will fail if a rhcos10 jobs is added for either of these, forcing us to figure out how to check these clusters. Another open question is whether we would ever have update jobs that start with rhcos9 and update to rhcos10. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
petr-muller
force-pushed
the
trt-2506-osversion-validate
branch
from
2024332 to
b82c27e
Compare
|
/payload-job periodic-ci-openshift-release-main-ci-4.22-e2e-azure-ovn-rhcos10-techpreview-serial periodic-ci-openshift-hypershift-release-4.22-periodics-e2e-aws-ovn periodic-ci-openshift-hypershift-release-4.22-periodics-e2e-aws-ovn-conformance /test e2e-aws-ovn-single-node-upgrade /pipeline required |
|
Scheduling required tests: |
|
@petr-muller: trigger 3 job(s) for the /payload-(with-prs|job|aggregate|job-with-prs|aggregate-with-prs) command
See details on https://pr-payload-tests.ci.openshift.org/runs/ci/16969ea0-1c05-11f1-921b-3f284e6414ea-0 |
|
@petr-muller: This pull request references TRT-2506 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 "4.22.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. |
|
Risk analysis has seen new tests most likely introduced by this PR. New Test Risks for sha: b82c27e
New tests seen in this PR at sha: b82c27e
|
|
Risk analysis has seen new tests most likely introduced by this PR. New tests seen in this PR at sha: b82c27e
|
4 participants
Ensure CI job names reflect the node OS version: RHCOS 10 clusters must have "rhcos10" in the job name and non-RHCOS10 must not.
Detect RHEL 10 by checking the worker MCP's OSImageStream setting, falling back to the cluster-wide default stream from the OSImageStream v1alpha1 singleton when the MCP does not specify one.
Currently we do not have HyperShift/MicroShift RHCOS10 jobs and it is still unknown how to check these clusters. The test will fail if a rhcos10 jobs is added for either of these, forcing us to figure out how to check these clusters.
Another open question is whether we would ever have update jobs that start with rhcos9 and update to rhcos10.
Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com
Summary by CodeRabbit