Skip to content

Conversation

wking
Copy link
Member

@wking wking commented Jun 18, 2025

When I added the:

Update to 4.18.6 Recommended=False:
...

block in c1ef328 (#1897), there was no subsequent output in this "--version has conditional risks" case, so the earlier lack-of-blank-line made sense.

But then 2d7e004 (#2023) gave the option for a subsequent:

error: issues that apply to this cluster but which were not included in --accept: ...

or:

Update to %s has no known issues relevant...

This commit adds a new line to standard output, to offset those summaries from the possibly-long Message:

...
Update to 4.18.6 Recommended=False:
Image: quay.io/openshift-release-dev/ocp-release@sha256:61fdad894f035a8b192647c224faf565279518255bdbf60a91db4ee0479adaa6
Release URL: https://access.redhat.com/errata/RHSA-2025:3066
Reason: CRIOLayerCompressionPulls
Message: The CRI-O container runtime may fail to pull images with certain layer compression characteristics https://issues.redhat.com/browse/OCPNODE-3074

error: issues that apply to this cluster but which were not included in --accept: ConditionalUpdateRisk,KubeContainerWaiting

instead of cramming that error: ... or ... has no known issues... right onto the end of the output. Although the error is getting written to standard error instead of the standard output, so in that case, the newline will only matter for terminal users and others who are flattening those two streams together.

@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Jun 18, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jun 18, 2025

@wking: This pull request references OTA-1576 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.20.0" version, but no target version was set.

In response to this:

When I added the:

Update to 4.18.6 Recommended=False:
...

block in c1ef328 (#1897), there was no subsequent output in this "--version has conditional risks" case, so the earlier lack-of-blank-line made sense.

But then 2d7e004 (#2023) gave the option for a subsequent:

error: issues that apply to this cluster but which were not included in --accept: ...

or:

Update to %s has no known issues relevant...

This commit adds a new line to standard output, to offset those summaries from the possibly-long Message:

...
Update to 4.18.6 Recommended=False:
Image: quay.io/openshift-release-dev/ocp-release@sha256:61fdad894f035a8b192647c224faf565279518255bdbf60a91db4ee0479adaa6
Release URL: https://access.redhat.com/errata/RHSA-2025:3066
Reason: CRIOLayerCompressionPulls
Message: The CRI-O container runtime may fail to pull images with certain layer compression characteristics https://issues.redhat.com/browse/OCPNODE-3074

error: issues that apply to this cluster but which were not included in --accept: ConditionalUpdateRisk,KubeContainerWaiting

instead of cramming that error: ... or ... has no known issues... right onto the end of the output. Although the error is getting written to standard error instead of the standard output, so in that case, the newline will only matter for terminal users and others who are flattening those two streams together.

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 openshift-ci bot requested review from deads2k and ingvagabund June 18, 2025 22:28
Copy link
Contributor

openshift-ci bot commented Jun 18, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: wking

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

The pull request process is described here

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 Jun 18, 2025
}
unaccepted := issues.Difference(accept)
if unaccepted.Len() > 0 {
if !o.quiet {

Choose a reason for hiding this comment

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

Won't it be duplicate with line 327 to 329?

Choose a reason for hiding this comment

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

let me create a OC client from this pr to test it. I need to set up a cluster, I will submit my test result, maybe 2 hours later.

@JianLi-RH
Copy link

JianLi-RH commented Jun 19, 2025

I am using following OC client test this PR:

[jianl@jianl-thinkpadt14gen4 420]$ oc version
Client Version: 4.20.0-0.nightly-2025-06-16-162515
Kustomize Version: v5.5.0
Server Version: 4.20.0-0.nightly-2025-06-15-170256
Kubernetes Version: v1.32.5
[jianl@jianl-thinkpadt14gen4 420]$ ./oc version
Client Version: oc_dev
Kustomize Version: v5.5.0
Server Version: 4.20.0-0.nightly-2025-06-15-170256
Kubernetes Version: v1.32.5
[jianl@jianl-thinkpadt14gen4 420]$ 

There is an extra string &{0xc0001520c0} when I use new OC:

[jianl@jianl-thinkpadt14gen4 420]$ ./oc adm upgrade recommend --version 4.20.0-0.nightly-2025-06-16-011145
Upstream update service: https://github.com/raw/JianLi-RH/ota/refs/heads/main/OCP-82705.json
Channel: stable-4.18

Update to 4.20.0-0.nightly-2025-06-16-011145 Recommended=False:
Image: registry.ci.openshift.org/ocp/release@sha256:c00dbb768955694cabe901e12aa5c6ac2121fcc77d2c376e2806a07942da5966
Release URL: https://amd64.ocp.releases.ci.openshift.org/releasestream/4.20.0-0.nightly/release/4.20.0-0.nightly-2025-06-16-162515
Reason: MultipleReasons
Message: Too many CI failures on this release, so do not update to it https://amd64.ocp.releases.ci.openshift.org/releasestream/4.19.0-0.nightly/release/4.19.0-0.nightly-2025-06-16-060026
  
  On clusters on default invoker user, this imaginary bug can happen. https://bug.example.com/a
&{0xc0001520c0}
error: issues that apply to this cluster but which were not included in --accept: ConditionalUpdateRisk
[jianl@jianl-thinkpadt14gen4 420]$ 

Compare to the new OC, the old oc client will output:

[jianl@jianl-thinkpadt14gen4 420]$ oc adm upgrade recommend --version 4.20.0-0.nightly-2025-06-16-011145
Upstream update service: https://github.com/raw/JianLi-RH/ota/refs/heads/main/OCP-82705.json
Channel: stable-4.18

Update to 4.20.0-0.nightly-2025-06-16-011145 Recommended=False:
Image: registry.ci.openshift.org/ocp/release@sha256:c00dbb768955694cabe901e12aa5c6ac2121fcc77d2c376e2806a07942da5966
Release URL: https://amd64.ocp.releases.ci.openshift.org/releasestream/4.20.0-0.nightly/release/4.20.0-0.nightly-2025-06-16-162515
Reason: MultipleReasons
Message: Too many CI failures on this release, so do not update to it https://amd64.ocp.releases.ci.openshift.org/releasestream/4.19.0-0.nightly/release/4.19.0-0.nightly-2025-06-16-060026
  
  On clusters on default invoker user, this imaginary bug can happen. https://bug.example.com/a
error: issues that apply to this cluster but which were not included in --accept: ConditionalUpdateRisk
[jianl@jianl-thinkpadt14gen4 420]$ 

@JianLi-RH
Copy link

After accept all risks, the output looks good:

[jianl@jianl-thinkpadt14gen4 420]$ ./oc adm upgrade recommend --version 4.20.0-0.nightly-2025-06-16-011145 --accept ConditionalUpdateRisk,FailedToCompletePrecheck
Failed to check for at least some preconditions: failed to get alerts from Thanos: no token is currently in use for this session
Upstream update service: https://github.com/raw/JianLi-RH/ota/refs/heads/main/OCP-82705.json
Channel: stable-4.18

Update to 4.20.0-0.nightly-2025-06-16-011145 Recommended=False:
Image: registry.ci.openshift.org/ocp/release@sha256:c00dbb768955694cabe901e12aa5c6ac2121fcc77d2c376e2806a07942da5966
Release URL: https://amd64.ocp.releases.ci.openshift.org/releasestream/4.20.0-0.nightly/release/4.20.0-0.nightly-2025-06-16-162515
Reason: accepted MultipleReasons
Message: Too many CI failures on this release, so do not update to it https://amd64.ocp.releases.ci.openshift.org/releasestream/4.19.0-0.nightly/release/4.19.0-0.nightly-2025-06-16-060026
  
  On clusters on default invoker user, this imaginary bug can happen. https://bug.example.com/a

Update to 4.20.0-0.nightly-2025-06-16-011145 has no known issues relevant to this cluster other than the accepted ConditionalUpdateRisk,FailedToCompletePrecheck.
[jianl@jianl-thinkpadt14gen4 420]$ 

@petr-muller
Copy link
Member

/cc

@openshift-ci openshift-ci bot requested a review from petr-muller June 19, 2025 10:51
@wking wking force-pushed the blank-line-after-recommend-version-conditional-risk branch from 4e93466 to f3de5e0 Compare July 8, 2025 16:58
unaccepted := issues.Difference(accept)
if unaccepted.Len() > 0 {
if !o.quiet {
fmt.Fprintln(o.Out)
Copy link
Member Author

Choose a reason for hiding this comment

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

testing with f3de5e0:

$  export OC_ENABLE_CMD_UPGRADE_RECOMMEND=true
$  export OC_ENABLE_CMD_UPGRADE_RECOMMEND_ACCEPT=true
$  export OC_ENABLE_CMD_UPGRADE_RECOMMEND_PRECHECK=true
$ ./oc adm upgrade recommend --version 4.18.19
The following conditions found no cause for concern in updating this cluster to later releases: recommended/CriticalAlerts (AsExpected), recommended/NodeAlerts (AsExpected), recommended/PodDisruptionBudgetAlerts (AsExpected)

The following conditions found cause for concern in updating this cluster to later releases: recommended/PodImagePullAlerts/KubeContainerWaiting/0

recommended/PodImagePullAlerts/KubeContainerWaiting/0=False:

  Reason: Alert:firing
  Message: warning alert KubeContainerWaiting firing, which may slow workload redistribution during rolling node updates. Pod container waiting longer than 1 hour. The alert description is: pod/nfd-gc-6cdb49f845-2plm7 in namespace openshift-nfd on container nfd-gc has been in waiting state for longer than 1 hour. <alert does not have a runbook_url annotation>

Upstream update service is unset, so the cluster will use an appropriate default.
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.20, eus-4.18, fast-4.18, fast-4.19, stable-4.18)

Update to 4.18.19 has no known issues relevant to this cluster.
Image: quay.io/openshift-release-dev/ocp-release@sha256:e6d80b9ab85b17b47e90cb8de1b9ad0e3fe457780148629d329d532ef902d222
Release URL: https://access.redhat.com/errata/RHSA-2025:9725

error: issues that apply to this cluster but which were not included in --accept: KubeContainerWaiting

So that has the blank line before the error: ... 👍

return fmt.Errorf("issues that apply to this cluster but which were not included in --accept: %s", strings.Join(sets.List(unaccepted), ","))
} else if issues.Len() > 0 && !o.quiet {
fmt.Fprintf(o.Out, "Update to %s has no known issues relevant to this cluster other than the accepted %s.\n", update.Release.Version, strings.Join(sets.List(issues), ","))
fmt.Fprintf(o.Out, "\nUpdate to %s has no known issues relevant to this cluster other than the accepted %s.\n", update.Release.Version, strings.Join(sets.List(issues), ","))
Copy link
Member Author

Choose a reason for hiding this comment

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

testing with f3de5e0:

$  export OC_ENABLE_CMD_UPGRADE_RECOMMEND=true
$  export OC_ENABLE_CMD_UPGRADE_RECOMMEND_ACCEPT=true
$  export OC_ENABLE_CMD_UPGRADE_RECOMMEND_PRECHECK=true
$ ./oc adm upgrade recommend --version 4.18.19 --accept KubeContainerWaiting
The following conditions found no cause for concern in updating this cluster to later releases: recommended/CriticalAlerts (AsExpected), recommended/NodeAlerts (AsExpected), recommended/PodDisruptionBudgetAlerts (AsExpected)

The following conditions found cause for concern in updating this cluster to later releases, but were explicitly accepted via --accept: recommended/PodImagePullAlerts/KubeContainerWaiting/0

Upstream update service is unset, so the cluster will use an appropriate default.
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.20, eus-4.18, fast-4.18, fast-4.19, stable-4.18)

Update to 4.18.19 has no known issues relevant to this cluster.
Image: quay.io/openshift-release-dev/ocp-release@sha256:e6d80b9ab85b17b47e90cb8de1b9ad0e3fe457780148629d329d532ef902d222
Release URL: https://access.redhat.com/errata/RHSA-2025:9725

Update to 4.18.19 has no known issues relevant to this cluster other than the accepted KubeContainerWaiting.

So that has the blank line before the ...other than the accepted... 👍 The two, similar has no known issues relevant to this cluster lines are a bit weird, but that predates this newline-adding change, and we can decide if it's worth addressing in follow-up work.

Copy link
Member Author

@wking wking Oct 3, 2025

Choose a reason for hiding this comment

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

Testing with ecf80c8:

$ ./oc adm upgrade recommend
The following conditions found no cause for concern in updating this cluster to later releases: recommended/CriticalAlerts (AsExpected), recommended/NodeAlerts (AsExpected), recommended/PodDisruptionBudgetAlerts (AsExpected)

The following conditions found cause for concern in updating this cluster to later releases: recommended/PodImagePullAlerts/KubeContainerWaiting/0

recommended/PodImagePullAlerts/KubeContainerWaiting/0=False:

  Reason: Alert:firing
  Message: warning alert KubeContainerWaiting firing, which may slow workload redistribution during rolling node updates. Pod container waiting longer than 1 hour. The alert description is: pod/nfd-gc-6cdb49f845-pgm7g in namespace openshift-nfd on container nfd-gc has been in waiting state for longer than 1 hour. <alert does not have a runbook_url annotation>

Upstream update service is unset, so the cluster will use an appropriate default.
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.20, eus-4.18, fast-4.18, fast-4.19, stable-4.18, stable-4.19)

Updates to 4.18:
  VERSION     ISSUES
  4.18.25     no known issues relevant to this cluster
  4.18.24     no known issues relevant to this cluster

And 19 older 4.18 updates you can see with '--show-outdated-releases' or '--version VERSION'.
$ ./oc adm upgrade recommend --version 4.18.25
The following conditions found no cause for concern in updating this cluster to later releases: recommended/CriticalAlerts (AsExpected), recommended/NodeAlerts (AsExpected), recommended/PodDisruptionBudgetAlerts (AsExpected)

The following conditions found cause for concern in updating this cluster to later releases: recommended/PodImagePullAlerts/KubeContainerWaiting/0

recommended/PodImagePullAlerts/KubeContainerWaiting/0=False:

  Reason: Alert:firing
  Message: warning alert KubeContainerWaiting firing, which may slow workload redistribution during rolling node updates. Pod container waiting longer than 1 hour. The alert description is: pod/nfd-gc-6cdb49f845-pgm7g in namespace openshift-nfd on container nfd-gc has been in waiting state for longer than 1 hour. <alert does not have a runbook_url annotation>

Upstream update service is unset, so the cluster will use an appropriate default.
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.20, eus-4.18, fast-4.18, fast-4.19, stable-4.18, stable-4.19)

Update to 4.18.25 has no known issues relevant to this cluster.
Image: quay.io/openshift-release-dev/ocp-release@sha256:ba6f0f2eca65cd386a5109ddbbdb3bab9bb9801e32de56ef34f80e634a7787be
Release URL: https://access.redhat.com/errata/RHBA-2025:16732

error: issues that apply to this cluster but which were not included in --accept: KubeContainerWaiting
$ ./oc adm upgrade recommend --version 4.18.25 --accept KubeContainerWaiting
The following conditions found no cause for concern in updating this cluster to later releases: recommended/CriticalAlerts (AsExpected), recommended/NodeAlerts (AsExpected), recommended/PodDisruptionBudgetAlerts (AsExpected)

The following conditions found cause for concern in updating this cluster to later releases, but were explicitly accepted via --accept: recommended/PodImagePullAlerts/KubeContainerWaiting/0

Upstream update service is unset, so the cluster will use an appropriate default.
Channel: candidate-4.18 (available channels: candidate-4.18, candidate-4.19, candidate-4.20, eus-4.18, fast-4.18, fast-4.19, stable-4.18, stable-4.19)

Update to 4.18.25 has no known issues relevant to this cluster.
Image: quay.io/openshift-release-dev/ocp-release@sha256:ba6f0f2eca65cd386a5109ddbbdb3bab9bb9801e32de56ef34f80e634a7787be
Release URL: https://access.redhat.com/errata/RHBA-2025:16732

Update to 4.18.25 has no known issues relevant to this cluster other than the accepted KubeContainerWaiting.

So that has the blank line before the ...other than the accepted... 👍 The two, similar has no known issues relevant to this cluster lines are a bit weird, but that predates this newline-adding change, and we can decide if it's worth addressing in follow-up work.

@JianLi-RH
Copy link

Thank you @wking, it works normal now.

Here are some of my test sceanrios:

  1. --version not recommend version
[jianl@jianl-thinkpadt14gen4 420]$ ./oc adm upgrade recommend --version 4.999.999
Upstream update service: https://github.com/raw/JianLi-RH/ota/refs/heads/main/OCP-82705.json
Channel: stable-4.18

Update to 4.999.999 Recommended=False:
Image: quay.io/openshift-release-dev/ocp-release@sha256:9d24a8cdd67b8f18c99547d5910e4863e7aab5bd888e26670a00dbda0a9d4687
Release URL: 
Reason: MultipleReasons
Message: Too many CI failures on this release, so do not update to it https://amd64.ocp.releases.ci.openshift.org/releasestream/4.19.0-0.nightly/release/4.19.0-0.nightly-2025-06-16-060026
  
  On clusters on default invoker user, this imaginary bug can happen. https://bug.example.com/a

error: issues that apply to this cluster but which were not included in --accept: ConditionalUpdateRisk
[jianl@jianl-thinkpadt14gen4 420]$
  1. --accept risk
[jianl@jianl-thinkpadt14gen4 420]$ ./oc adm upgrade recommend --version 4.999.999 --accept ConditionalUpdateRisk
Upstream update service: https://github.com/raw/JianLi-RH/ota/refs/heads/main/OCP-82705.json
Channel: stable-4.18

Update to 4.999.999 Recommended=False:
Image: quay.io/openshift-release-dev/ocp-release@sha256:9d24a8cdd67b8f18c99547d5910e4863e7aab5bd888e26670a00dbda0a9d4687
Release URL: 
Reason: accepted MultipleReasons
Message: Too many CI failures on this release, so do not update to it https://amd64.ocp.releases.ci.openshift.org/releasestream/4.19.0-0.nightly/release/4.19.0-0.nightly-2025-06-16-060026
  
  On clusters on default invoker user, this imaginary bug can happen. https://bug.example.com/a

Update to 4.999.999 has no known issues relevant to this cluster other than the accepted ConditionalUpdateRisk.
[jianl@jianl-thinkpadt14gen4 420]$ 
  1. --quiet
[jianl@jianl-thinkpadt14gen4 420]$ ./oc adm upgrade recommend --version 4.999.999 --accept ConditionalUpdateRisk --quiet
[jianl@jianl-thinkpadt14gen4 420]$ 
[jianl@jianl-thinkpadt14gen4 420]$ ./oc adm upgrade recommend --version 4.999.999 --quiet
error: issues that apply to this cluster but which were not included in --accept: ConditionalUpdateRisk
[jianl@jianl-thinkpadt14gen4 420]$ 

@JianLi-RH
Copy link

/label qe-approved

@openshift-ci openshift-ci bot added the qe-approved Signifies that QE has signed off on this PR label Jul 9, 2025
@openshift-ci-robot
Copy link

openshift-ci-robot commented Jul 9, 2025

@wking: This pull request references OTA-1576 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.20.0" version, but no target version was set.

In response to this:

When I added the:

Update to 4.18.6 Recommended=False:
...

block in c1ef328 (#1897), there was no subsequent output in this "--version has conditional risks" case, so the earlier lack-of-blank-line made sense.

But then 2d7e004 (#2023) gave the option for a subsequent:

error: issues that apply to this cluster but which were not included in --accept: ...

or:

Update to %s has no known issues relevant...

This commit adds a new line to standard output, to offset those summaries from the possibly-long Message:

...
Update to 4.18.6 Recommended=False:
Image: quay.io/openshift-release-dev/ocp-release@sha256:61fdad894f035a8b192647c224faf565279518255bdbf60a91db4ee0479adaa6
Release URL: https://access.redhat.com/errata/RHSA-2025:3066
Reason: CRIOLayerCompressionPulls
Message: The CRI-O container runtime may fail to pull images with certain layer compression characteristics https://issues.redhat.com/browse/OCPNODE-3074

error: issues that apply to this cluster but which were not included in --accept: ConditionalUpdateRisk,KubeContainerWaiting

instead of cramming that error: ... or ... has no known issues... right onto the end of the output. Although the error is getting written to standard error instead of the standard output, so in that case, the newline will only matter for terminal users and others who are flattening those two streams together.

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.

@wking wking force-pushed the blank-line-after-recommend-version-conditional-risk branch from f3de5e0 to 2a2c132 Compare July 9, 2025 05:11
@petr-muller
Copy link
Member

Would lgtm but fails unit tests ;)

@JianLi-RH
Copy link

/retest

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 12, 2025
@wking wking changed the title OTA-1576: pkg/cli/admin/upgrade/recommend: Add a blank line after --version conditional risk OCPBUGS-61061: pkg/cli/admin/upgrade/recommend: Add a blank line after --version conditional risk Aug 29, 2025
@openshift-ci-robot openshift-ci-robot added the jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. label Aug 29, 2025
@openshift-ci-robot
Copy link

@wking: This pull request references Jira Issue OCPBUGS-61061, which is invalid:

  • expected the bug to target the "4.20.0" version, but no target version was set

Comment /jira refresh to re-evaluate validity if changes to the Jira bug are made, or edit the title of this pull request to link to a different bug.

The bug has been updated to refer to the pull request using the external bug tracker.

In response to this:

When I added the:

Update to 4.18.6 Recommended=False:
...

block in c1ef328 (#1897), there was no subsequent output in this "--version has conditional risks" case, so the earlier lack-of-blank-line made sense.

But then 2d7e004 (#2023) gave the option for a subsequent:

error: issues that apply to this cluster but which were not included in --accept: ...

or:

Update to %s has no known issues relevant...

This commit adds a new line to standard output, to offset those summaries from the possibly-long Message:

...
Update to 4.18.6 Recommended=False:
Image: quay.io/openshift-release-dev/ocp-release@sha256:61fdad894f035a8b192647c224faf565279518255bdbf60a91db4ee0479adaa6
Release URL: https://access.redhat.com/errata/RHSA-2025:3066
Reason: CRIOLayerCompressionPulls
Message: The CRI-O container runtime may fail to pull images with certain layer compression characteristics https://issues.redhat.com/browse/OCPNODE-3074

error: issues that apply to this cluster but which were not included in --accept: ConditionalUpdateRisk,KubeContainerWaiting

instead of cramming that error: ... or ... has no known issues... right onto the end of the output. Although the error is getting written to standard error instead of the standard output, so in that case, the newline will only matter for terminal users and others who are flattening those two streams together.

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.

@wking
Copy link
Member Author

wking commented Aug 29, 2025

/jira refresh

@openshift-ci-robot openshift-ci-robot added the jira/valid-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. label Aug 29, 2025
@openshift-ci-robot
Copy link

@wking: This pull request references Jira Issue OCPBUGS-61061, which is valid.

3 validation(s) were run on this bug
  • bug is open, matching expected state (open)
  • bug target version (4.20.0) matches configured target version for branch (4.20.0)
  • bug is in the state POST, which is one of the valid states (NEW, ASSIGNED, POST)

No GitHub users were found matching the public email listed for the QA contact in Jira ([email protected]), skipping review request.

In response to this:

/jira refresh

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-robot openshift-ci-robot removed the jira/invalid-bug Indicates that a referenced Jira bug is invalid for the branch this PR is targeting. label Aug 29, 2025
wking added 2 commits October 2, 2025 15:13
Since 8bdac16 (pkg/cli/admin/upgrade/recommend: Enable precheck and
accept gates, 2025-09-03, openshift#2088), this knob has always been enabled.
Save ourselves a no longer necessary level of indentation by removing
it completely.
…ditional risk

When I added the:

  Update to 4.18.6 Recommended=False:
  ...

block in c1ef328 (pkg/cli/admin/upgrade/recommend: Add --version
option for specific releases, 2024-10-14, openshift#1897), there was no
subsequent output in this "--version has conditional risks" case, so
the earlier lack-of-blank-line made sense.

But then 2d7e004 (pkg/cli/admin/upgrade/recommend: New,
feature-gated --accept, 2025-05-06, openshift#2023) gave the option for a
subsequent:

  error: issues that apply to this cluster but which were not included in --accept: ...

or:

  Update to %s has no known issues relevant...

This commit adds trackers to all the output blocks in the command for
"was there previous output on this stream?", so that a new block (or a
returned error) can be prefixed by the blank line needed to set off
the new block from the previous block.  For example, it now sets off
the error line from the previous, possibly-long message strings:

  ...
  Update to 4.18.6 Recommended=False:
  Image: quay.io/openshift-release-dev/ocp-release@sha256:61fdad894f035a8b192647c224faf565279518255bdbf60a91db4ee0479adaa6
  Release URL: https://access.redhat.com/errata/RHSA-2025:3066
  Reason: CRIOLayerCompressionPulls
  Message: The CRI-O container runtime may fail to pull images with certain layer compression characteristics https://issues.redhat.com/browse/OCPNODE-3074

  error: issues that apply to this cluster but which were not included in --accept: ConditionalUpdateRisk,KubeContainerWaiting

instead of cramming that 'error: ...' or '... has no known issues...'
right onto the end of the output.  The error is getting written to
standard error instead of the standard output, so there's still some
wiggle room for poor spacing for terminal users and others who are
flattening those two streams together.

And now that we have the additional newline handling in recommend.go,
I can drop the newline I'd been manually injecting in examples_test.go
to make the test fixtures more readable.  I should have noticed that
test-specific injection as a sign that the better recommend.go newline
handling was useful.  Oh well, better late than never.
@wking wking force-pushed the blank-line-after-recommend-version-conditional-risk branch from 2a2c132 to ecf80c8 Compare October 3, 2025 04:13
Copy link

coderabbitai bot commented Oct 3, 2025

Walkthrough

Updates the upgrade recommend command: removes precheck feature flag, refactors precheck invocation and error handling, restructures condition classification and output spacing, and adjusts user-facing messages. Test expectations are updated to match new error formatting and removal of precheck option usage.

Changes

Cohort / File(s) Summary of changes
CLI recommend logic and output flow
pkg/cli/admin/upgrade/recommend/recommend.go
Removed precheckEnabled field and guard; always invoke precheck. Added stdout/stderr tracking to control blank lines. Introduced happy/accepted/unhappy condition buckets and revised acceptance handling. Adjusted messaging, spacing, and newline behavior across update, channel, and risk reporting paths.
Examples tests alignment
pkg/cli/admin/upgrade/recommend/examples_test.go
Dropped assignment to removed precheck option. Updated expected error formatting to use "error: " without a leading newline; non-error path unchanged.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run `@coderabbitai generate docstrings` to improve docstring coverage.
✅ Passed checks (2 passed)
Check name Status Explanation
Title Check ✅ Passed The title clearly describes the primary change—adding a blank line after the --version conditional risk output—and directly references the affected component, making it specific and easily understood in the context of the changeset.
Description Check ✅ Passed The description thoroughly explains the rationale for the added newline and provides concrete before/after examples showing how it separates the summary lines in the --version conditional risk case, clearly relating to the changeset.
✨ Finishing touches
  • 📝 Generate Docstrings
🧪 Generate unit tests
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Cache: Disabled due to data retention organization setting

Knowledge base: Disabled due to Reviews -> Disable Knowledge Base setting

📥 Commits

Reviewing files that changed from the base of the PR and between a25e854 and ecf80c8.

📒 Files selected for processing (2)
  • pkg/cli/admin/upgrade/recommend/examples_test.go (1 hunks)
  • pkg/cli/admin/upgrade/recommend/recommend.go (9 hunks)
🔇 Additional comments (13)
pkg/cli/admin/upgrade/recommend/recommend.go (12)

142-142: LGTM!

The introduction of previousStdout and previousStderr booleans provides a clean mechanism to track output state and manage blank line insertion between sections. This aligns well with the PR objective of improving terminal output readability.


163-165: LGTM!

The removal of the extra blank line and addition of previousStdout = true correctly tracks that output was written to stdout. This ensures subsequent sections can insert a blank line if needed.


175-175: LGTM!

Correctly tracks that a warning was written to stderr, enabling proper spacing for subsequent stderr output.


186-192: LGTM!

The conditional blank line insertion based on previousStdout ensures proper spacing between the "Progressing" message and prior output. Setting previousStdout = true maintains correct state tracking.


195-220: LGTM!

The refactored precheck handling is cleaner:

  • Direct call to precheck without a guard
  • Clear error handling with output and state tracking
  • Structured classification into happyConditions, acceptedConditions, and unhappyConditions

This improves maintainability and aligns with the removal of the precheckEnabled field.


222-257: LGTM!

The condition output logic is well-structured:

  • Sorted output for each category (happy, accepted, unhappy)
  • Consistent blank line insertion based on previousStdout
  • Proper state tracking after each output section

This ensures clear separation between different condition categories in the terminal output.


261-266: LGTM!

Correctly handles spacing for the "Cannot refresh available updates" warning by checking previousStderr before inserting a blank line and updating the state afterward.


272-286: LGTM!

The channel information output properly checks previousStdout for spacing and updates the state after output. This maintains consistent formatting across different output sections.


295-300: LGTM!

SemVer parsing warnings consistently check previousStderr before inserting a blank line and update state afterward. This ensures proper spacing for warnings regardless of where they appear in the output flow.

Also applies to: 326-331


347-352: LGTM!

The Upgradeable condition warning follows the same pattern as other stderr messages, with proper spacing and state tracking.


358-428: LGTM! This implements the core PR objective.

The --version case now inserts blank lines appropriately:

  • Before error returns (lines 407-411, 423-427)
  • After conditional risk messages (line 401, 407-408, 414-415)
  • Between update info and summary messages

The logic correctly checks both previousStdout and previousStderr to determine which stream needs a blank line before returning errors. This directly addresses the PR objective of adding a blank line after the conditional risk message when --version has risks.


433-460: LGTM!

The general update listing output maintains consistent spacing by checking previousStdout before printing section headers and updating state afterward.

pkg/cli/admin/upgrade/recommend/examples_test.go (1)

100-100: LGTM!

The updated error output construction correctly concatenates stdout content with the error message prefixed by "error: ". This aligns with the changes in recommend.go where blank lines are now inserted conditionally within the Run method before returning errors, rather than relying on the test to add leading newlines.

The format matches the new output behavior where Run handles spacing internally and returns the error message without expecting callers to add newlines.


Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Oct 3, 2025
Copy link
Contributor

openshift-ci bot commented Oct 3, 2025

@wking: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/e2e-aws-ovn-serial-1of2 ecf80c8 link true /test e2e-aws-ovn-serial-1of2
ci/prow/okd-scos-e2e-aws-ovn ecf80c8 link false /test okd-scos-e2e-aws-ovn

Full PR test history. Your PR dashboard.

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.

@DavidHurta
Copy link
Contributor

/cc

@openshift-ci openshift-ci bot requested a review from DavidHurta October 6, 2025 17:11
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-bug Indicates that a referenced Jira bug is valid for the branch this PR is targeting. jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. qe-approved Signifies that QE has signed off on this PR

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants