Skip to content

MCO-1985: Move boot image skew enforcement to Default#2758

Merged
openshift-merge-bot[bot] merged 1 commit intoopenshift:masterfrom
djoshy:promo-skew-final
Mar 11, 2026
Merged

MCO-1985: Move boot image skew enforcement to Default#2758
openshift-merge-bot[bot] merged 1 commit intoopenshift:masterfrom
djoshy:promo-skew-final

Conversation

@djoshy
Copy link
Contributor

@djoshy djoshy commented Mar 10, 2026

This PR promotes the BootImageSkewEnforcement feature gate to default.

Notes on feature promotion tests:

  • baremetal clusters: Automatic tests are disabled as the MCO does not manage boot image updates for this platform.
  • SNO clusters: This feature is disabled as a whole in this case as these clusters do not scale.
  • vSphere clusters: The Verify Automatic mode permits other machine managers test is disabled as vSphere does not currently support control plane boot image updates.

@openshift-ci-robot
Copy link

Pipeline controller notification
This repo is configured to use the pipeline controller. Second-stage tests will be triggered either automatically or after lgtm label is added, depending on the repository configuration. The pipeline controller will automatically detect which contexts are required and will utilize /test Prow commands to trigger the second stage.

For optional jobs, comment /test ? to see a list of all defined jobs. To trigger manually all jobs from second stage use /pipeline required command.

This repository is configured in: LGTM mode

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Mar 10, 2026
@openshift-ci openshift-ci bot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 10, 2026
@openshift-ci-robot
Copy link

openshift-ci-robot commented Mar 10, 2026

@djoshy: This pull request references MCO-1985 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.

Details

In response to this:

This PR promotes the BootImageSkewEnforcement feature gate to default.

Notes on feature promotion tests:

  • baremetal clusters: Automatic tests are disabled as the MCO does not manage boot image updates for this platform.
  • SNO clusters: This feature is disabled as a whole in this case as these clusters do not scale.
  • vSphere clusters: The Verify Automatic mode permits other machine managers test is disabled as vSphere does not currently support control plane boot image updates.

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.

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 10, 2026

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 10, 2026

Hello @djoshy! Some important instructions when contributing to openshift/api:
API design plays an important part in the user experience of OpenShift and as such API PRs are subject to a high level of scrutiny to ensure they follow our best practices. If you haven't already done so, please review the OpenShift API Conventions and ensure that your proposed changes are compliant. Following these conventions will help expedite the api review process for your PR.

@openshift-ci openshift-ci bot added the size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. label Mar 10, 2026
@coderabbitai
Copy link

coderabbitai bot commented Mar 10, 2026

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration

Configuration used: Repository YAML (base), Central YAML (inherited)

Review profile: CHILL

Plan: Pro

Run ID: f7a8ef22-b712-40fa-b202-cc8ef2f42b0c

📥 Commits

Reviewing files that changed from the base of the PR and between c9c9ac0 and 34a2ae9.

⛔ Files ignored due to path filters (2)
  • operator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
  • operator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml is excluded by !**/zz_generated.crd-manifests/*
📒 Files selected for processing (8)
  • features.md
  • features/features.go
  • payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml
  • payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml
  • payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml
  • payload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yaml
  • payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml
  • payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml

📝 Walkthrough

Walkthrough

This pull request enables the BootImageSkewEnforcement feature across multiple environments and cluster profiles. Changes include activating the feature gate in Default and OKD cluster profiles in features.go, moving BootImageSkewEnforcement from disabled to enabled lists in multiple featureGate YAML files, and adding comprehensive spec and status field definitions to MachineConfiguration CRDs with validation rules for boot image version skew enforcement modes (Automatic, Manual, None). The feature table in features.md is updated to reflect the enabled state.

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and specifically describes the main change: promoting BootImageSkewEnforcement to Default, which aligns with the extensive changes across feature gates, CRDs, and configuration files throughout the changeset.
Description check ✅ Passed The description is directly related to the changeset, explaining the promotion of BootImageSkewEnforcement to default and documenting platform-specific test considerations that correspond to the feature gate changes.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Stable And Deterministic Test Names ✅ Passed All Ginkgo test names in the PR are stable and deterministic, containing only static descriptive strings without dynamic identifiers, timestamps, or generated values.
Test Structure And Quality ✅ Passed This pull request does not include any Ginkgo test code files. All changes are configuration and schema files.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.5.0)

Error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented
The command is terminated due to an error: build linters: unable to load custom analyzer "kubeapilinter": tools/_output/bin/kube-api-linter.so, plugin: not implemented

Tip

Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs).
Share your feedback on Discord.


Comment @coderabbitai help to get the list of available commands and usage tips.

@djoshy djoshy marked this pull request as ready for review March 11, 2026 06:14
@openshift-ci openshift-ci bot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 11, 2026
@qodo-code-review
Copy link

ⓘ You are approaching your monthly quota for Qodo. Upgrade your plan

Review Summary by Qodo

Promote BootImageSkewEnforcement feature gate to default

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Promote BootImageSkewEnforcement feature gate to default
• Enable feature for Default and OKD cluster profiles
• Update CRD manifests with boot image skew enforcement configuration
• Reorganize feature gate documentation and manifests
Diagram
flowchart LR
  A["BootImageSkewEnforcement<br/>Feature Gate"] -->|enable inDefault<br/>inOKD| B["Default & OKD<br/>Profiles"]
  C["CRD Manifests"] -->|add spec &<br/>status fields| D["Boot Image Skew<br/>Configuration"]
  E["Feature Gate<br/>Documentation"] -->|reorganize| F["Enabled by Default<br/>Section"]
Loading

Grey Divider

File Changes

1. features/features.go ✨ Enhancement +7/-7

Enable BootImageSkewEnforcement for default profiles

features/features.go


2. features.md 📝 Documentation +1/-1

Move BootImageSkewEnforcement to default section

features.md


3. operator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml ✨ Enhancement +252/-0

Add boot image skew enforcement spec and status

operator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml


View more (7)
4. operator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml ✨ Enhancement +252/-0

Add boot image skew enforcement spec and status

operator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml


5. payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml ✨ Enhancement +252/-0

Add boot image skew enforcement spec and status

payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml


6. payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml ✨ Enhancement +252/-0

Add boot image skew enforcement spec and status

payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml


7. payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml ⚙️ Configuration changes +3/-3

Move BootImageSkewEnforcement to enabled section

payload-manifests/featuregates/featureGate-4-10-Hypershift-Default.yaml


8. payload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yaml ⚙️ Configuration changes +3/-3

Move BootImageSkewEnforcement to enabled section

payload-manifests/featuregates/featureGate-4-10-Hypershift-OKD.yaml


9. payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml ⚙️ Configuration changes +3/-3

Move BootImageSkewEnforcement to enabled section

payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-Default.yaml


10. payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml ⚙️ Configuration changes +3/-3

Move BootImageSkewEnforcement to enabled section

payload-manifests/featuregates/featureGate-4-10-SelfManagedHA-OKD.yaml


Grey Divider

Qodo Logo

@qodo-code-review
Copy link

qodo-code-review bot commented Mar 11, 2026

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (1) 📎 Requirement gaps (0)

Grey Divider


Action required

1. Machinesets status bypass 🐞 Bug ✓ Correctness
Description
The new CEL rule that is supposed to ensure managedBootImagesStatus contains a MachineSet
MachineManager with selection.mode='All' when bootImageSkewEnforcementStatus.mode is Automatic
explicitly passes when status.managedBootImagesStatus.machineManagers is absent, so the rule does
not actually enforce its own message in that case.
Code

payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml[R1507-1513]

+        - message: when skew enforcement is in Automatic mode, managedBootImagesStatus
+            must contain a MachineManager opting in all MachineAPI MachineSets
+          rule: 'self.?status.bootImageSkewEnforcementStatus.mode.orValue("") == ''Automatic''
+            ? !(self.?status.managedBootImagesStatus.machineManagers.hasValue()) ||
+            self.status.managedBootImagesStatus.machineManagers.exists(m, m.selection.mode
+            == ''All'' && m.resource == ''machinesets'' && m.apiGroup == ''machine.openshift.io''):
+            true'
Evidence
The CRD validation for Automatic mode uses a negated hasValue() check, meaning it short-circuits to
true when machineManagers is missing, even though the message says it "must contain" an opting-in
MachineSet manager; the same logic is generated from the API type annotations.

payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml[1488-1513]
operator/v1/types_machineconfiguration.go[20-23]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The MachineConfiguration CRD CEL validation for `bootImageSkewEnforcementStatus.mode == &quot;Automatic&quot;` currently passes when `status.managedBootImagesStatus.machineManagers` is missing, despite the error message stating it *must contain* an opting-in MachineSet MachineManager.

### Issue Context
This rule is now active in the Default/OKD feature sets and should enforce that Automatic skew enforcement has an explicit MachineSet opt-in (`selection.mode == &quot;All&quot;`) in status.

### Fix Focus Areas
- payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml[1507-1513]
- payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml[1507-1513]
- operator/v1/types_machineconfiguration.go[20-23]

### Implementation notes
- Change the rule shape from `!(hasValue()) || exists(...)` to `hasValue() &amp;&amp; exists(...)` (or equivalent) so absence fails validation in Automatic mode.
- Regenerate the CRD manifests after updating the source annotations (so operator/v1 and payload-manifests stay in sync).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

2. ocpVersion omission undocumented 📘 Rule violation ✓ Correctness
Description
The newly surfaced optional fields status.bootImageSkewEnforcementStatus.automatic.ocpVersion and
rhcosVersion do not document what happens when each field is omitted. This violates the
requirement that optional API fields explicitly describe omitted-field behavior, which can lead to
ambiguous client usage.
Code

operator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml[R769-793]

+                      ocpVersion:
+                        description: |-
+                          ocpVersion provides a string which represents the OCP version of the boot image.
+                          This field must match the OCP semver compatible format of x.y.z. This field must be between
+                          5 and 10 characters long.
+                        maxLength: 10
+                        minLength: 5
+                        type: string
+                        x-kubernetes-validations:
+                        - message: ocpVersion must match the OCP semver compatible
+                            format of x.y.z
+                          rule: self.matches('^[0-9]+\\.[0-9]+\\.[0-9]+$')
+                      rhcosVersion:
+                        description: |-
+                          rhcosVersion provides a string which represents the RHCOS version of the boot image
+                          This field must match rhcosVersion formatting of [major].[minor].[datestamp(YYYYMMDD)]-[buildnumber] or the legacy
+                          format of [major].[minor].[timestamp(YYYYMMDDHHmm)]-[buildnumber]. This field must be between
+                          14 and 21 characters long.
+                        maxLength: 21
+                        minLength: 14
+                        type: string
+                        x-kubernetes-validations:
+                        - message: rhcosVersion must match format [major].[minor].[datestamp(YYYYMMDD)]-[buildnumber]
+                            or must match legacy format [major].[minor].[timestamp(YYYYMMDDHHmm)]-[buildnumber]
+                          rule: self.matches('^[0-9]+\\.[0-9]+\\.([0-9]{8}|[0-9]{12})-[0-9]+$')
Evidence
PR Compliance ID 7 requires every optional API field to explain behavior when omitted. In the
generated CRD schema now added for default, the ocpVersion and rhcosVersion property
descriptions list formatting constraints but do not explain omitted-field behavior; in the Go type,
both fields are marked +optional without per-field omitted-field behavior text.

AGENTS.md
operator/v1/zz_generated.crd-manifests/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml[769-793]
operator/v1/types_machineconfiguration.go[202-219]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Optional API fields must explicitly document behavior when omitted. The fields `ClusterBootImageAutomatic.OCPVersion` and `ClusterBootImageAutomatic.RHCOSVersion` are marked `+optional` but their per-field comments do not describe omitted-field behavior.

## Issue Context
This PR promotes `BootImageSkewEnforcement` to default, causing the schema to be surfaced in default CRDs. Documentation for optional fields should be unambiguous for API consumers.

## Fix Focus Areas
- operator/v1/types_machineconfiguration.go[202-219]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Config presence check ineffective 🐞 Bug ✓ Correctness
Description
The Automatic-mode CEL rule that claims a "boot image configuration is required" only checks whether
the managedBootImages objects exist, not whether any machineManagers configuration exists, so an
empty {} managedBootImages/managedBootImagesStatus satisfies the requirement without providing
actionable boot-image manager selection.
Code

payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml[R1489-1493]

+        - message: when skew enforcement is in Automatic mode, a boot image configuration
+            is required
+          rule: 'self.?status.bootImageSkewEnforcementStatus.mode.orValue("") == ''Automatic''
+            ? self.?spec.managedBootImages.hasValue() || self.?status.managedBootImagesStatus.hasValue()
+            : true'
Evidence
The CRD rule for "boot image configuration is required" treats object presence (hasValue() on the
object) as sufficient. The API types model both spec.managedBootImages and
status.managedBootImagesStatus as non-pointer, non-omitempty struct fields, which can legitimately
be present as empty objects without any machineManagers entries, meaning this rule does not
guarantee that any boot-image manager selection is actually provided.

payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml[1488-1493]
operator/v1/types_machineconfiguration.go[40-52]
operator/v1/types_machineconfiguration.go[288-292]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The Automatic-mode CEL validation currently considers the managedBootImages *object* sufficient (`hasValue()`), which allows empty objects to satisfy the &quot;boot image configuration is required&quot; rule.

### Issue Context
In Automatic skew enforcement mode, the system needs a concrete machine manager selection to reason about / manage boot images. Object presence alone does not ensure any manager selection exists.

### Fix Focus Areas
- payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml[1489-1493]
- payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml[1489-1493]
- operator/v1/types_machineconfiguration.go[20-21]
- operator/v1/types_machineconfiguration.go[40-52]
- operator/v1/types_machineconfiguration.go[288-292]

### Implementation notes
- Consider changing the rule to validate `machineManagers` presence/content instead of object presence, e.g. require `spec.managedBootImages.machineManagers` or `status.managedBootImagesStatus.machineManagers` to have a value (and optionally size &gt; 0) in Automatic mode.
- Regenerate CRD manifests after updating the annotation source so both operator/v1 and payload-manifests remain consistent.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

ⓘ The new review experience is currently in Beta. Learn more

Grey Divider

Qodo Logo

Comment on lines +1507 to +1513
- message: when skew enforcement is in Automatic mode, managedBootImagesStatus
must contain a MachineManager opting in all MachineAPI MachineSets
rule: 'self.?status.bootImageSkewEnforcementStatus.mode.orValue("") == ''Automatic''
? !(self.?status.managedBootImagesStatus.machineManagers.hasValue()) ||
self.status.managedBootImagesStatus.machineManagers.exists(m, m.selection.mode
== ''All'' && m.resource == ''machinesets'' && m.apiGroup == ''machine.openshift.io''):
true'

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

1. Machinesets status bypass 🐞 Bug ✓ Correctness

The new CEL rule that is supposed to ensure managedBootImagesStatus contains a MachineSet
MachineManager with selection.mode='All' when bootImageSkewEnforcementStatus.mode is Automatic
explicitly passes when status.managedBootImagesStatus.machineManagers is absent, so the rule does
not actually enforce its own message in that case.
Agent Prompt
### Issue description
The MachineConfiguration CRD CEL validation for `bootImageSkewEnforcementStatus.mode == "Automatic"` currently passes when `status.managedBootImagesStatus.machineManagers` is missing, despite the error message stating it *must contain* an opting-in MachineSet MachineManager.

### Issue Context
This rule is now active in the Default/OKD feature sets and should enforce that Automatic skew enforcement has an explicit MachineSet opt-in (`selection.mode == "All"`) in status.

### Fix Focus Areas
- payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-Default.crd.yaml[1507-1513]
- payload-manifests/crds/0000_80_machine-config_01_machineconfigurations-OKD.crd.yaml[1507-1513]
- operator/v1/types_machineconfiguration.go[20-23]

### Implementation notes
- Change the rule shape from `!(hasValue()) || exists(...)` to `hasValue() && exists(...)` (or equivalent) so absence fails validation in Automatic mode.
- Regenerate the CRD manifests after updating the source annotations (so operator/v1 and payload-manifests stay in sync).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

@djoshy
Copy link
Contributor Author

djoshy commented Mar 11, 2026

/pipeline required

@openshift-ci-robot
Copy link

Scheduling tests matching the pipeline_run_if_changed or not excluded by pipeline_skip_if_only_changed parameters:
/test e2e-aws-ovn
/test e2e-aws-ovn-hypershift
/test e2e-aws-ovn-hypershift-conformance
/test e2e-aws-ovn-techpreview
/test e2e-aws-serial-1of2
/test e2e-aws-serial-2of2
/test e2e-aws-serial-techpreview-1of2
/test e2e-aws-serial-techpreview-2of2
/test e2e-azure
/test e2e-gcp
/test e2e-upgrade
/test e2e-upgrade-out-of-change
/test minor-e2e-upgrade-minor

@JoelSpeed
Copy link
Contributor

/lgtm
/override ci/prow/verify-feature-promotion

Passing well aside from the notes in the PR description, LGTM

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 11, 2026

@JoelSpeed: Overrode contexts on behalf of JoelSpeed: ci/prow/verify-feature-promotion

Details

In response to this:

/lgtm
/override ci/prow/verify-feature-promotion

Passing well aside from the notes in the PR description, LGTM

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 kubernetes-sigs/prow repository.

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Mar 11, 2026
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 11, 2026

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JoelSpeed

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci openshift-ci bot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 11, 2026
@openshift-ci-robot
Copy link

Tests from second stage were triggered manually. Pipeline can be controlled only manually, until HEAD changes. Use command to trigger second stage.

@djoshy
Copy link
Contributor Author

djoshy commented Mar 11, 2026

/verified by CI and promotion tests

@openshift-ci-robot openshift-ci-robot added the verified Signifies that the PR passed pre-merge verification criteria label Mar 11, 2026
@openshift-ci-robot
Copy link

@djoshy: This PR has been marked as verified by CI and promotion tests.

Details

In response to this:

/verified by CI and promotion tests

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.

@djoshy
Copy link
Contributor Author

djoshy commented Mar 11, 2026

/retest

@openshift-ci
Copy link
Contributor

openshift-ci bot commented Mar 11, 2026

@djoshy: all tests passed!

Full PR test history. Your PR dashboard.

Details

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 kubernetes-sigs/prow repository. I understand the commands that are listed here.

@openshift-merge-bot openshift-merge-bot bot merged commit 1d84ab4 into openshift:master Mar 11, 2026
28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. lgtm Indicates that a PR is ready to be merged. size/XXL Denotes a PR that changes 1000+ lines, ignoring generated files. verified Signifies that the PR passed pre-merge verification criteria

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants