From f2dd7de221cd5fdf974d60e00047612aca4e322d Mon Sep 17 00:00:00 2001 From: Hongkai Liu Date: Tue, 2 Dec 2025 16:06:15 -0500 Subject: [PATCH] Skip a ClusterOperator test if a cluster upgrade is blocked If a cluster upgrade is blocked before co/machine-config starts to update (`Progressing=True`), then `machineConfigProgressingStart` is zero. In that case, the rule "each CO should stay `Progressing=False` while MCO is `Progressing=True`" is trivially valid, and thus we do not need to check it in the test. Without the guard introduced in this pull, the cases for COs that started update earlier in the upgrade would be failures by mistake which become noises on Component Readiness portal. See an example job [1]. There the upgrade was not complete because it is blocked by co/baremetal [2]. [1]. https://prow.ci.openshift.org/view/gs/test-platform-results/logs/periodic-ci-openshift-release-master-nightly-4.21-e2e-metal-ipi-upgrade-ovn-ipv6/1995270013593849856 [2]. https://issues.redhat.com/browse/OCPBUGS-66134 --- .../legacycvomonitortests/operators.go | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/pkg/monitortests/clusterversionoperator/legacycvomonitortests/operators.go b/pkg/monitortests/clusterversionoperator/legacycvomonitortests/operators.go index 82ef439824a1..9eae38e7a799 100644 --- a/pkg/monitortests/clusterversionoperator/legacycvomonitortests/operators.go +++ b/pkg/monitortests/clusterversionoperator/legacycvomonitortests/operators.go @@ -828,6 +828,15 @@ func testUpgradeOperatorProgressingStateTransitions(events monitorapi.Intervals) }) continue } + if machineConfigProgressingStart.IsZero() { + ret = append(ret, &junitapi.JUnitTestCase{ + Name: testName, + SkipMessage: &junitapi.SkipMessage{ + Message: "Test skipped as clusteroperator/machine-config never reported Progressing=True which is probably caused by a blocked upgrade", + }, + }) + continue + } var excepted, fatal []string for _, operatorEvent := range operatorEvents {