Bug 1754924 - CI: fix verify tools build failure
Summary: CI: fix verify tools build failure
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Machine Config Operator
Version: 4.1.z
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 4.1.z
Assignee: Antonio Murdaca
QA Contact: Michael Nguyen
Depends On: 1756384
TreeView+ depends on / blocked
Reported: 2019-09-24 11:27 UTC by Antonio Murdaca
Modified: 2019-10-16 18:08 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1756384 (view as bug list)
Last Closed: 2019-10-16 18:07:59 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Github openshift machine-config-operator pull 1132 None None None 2019-09-24 11:28:21 UTC
Red Hat Product Errata RHBA-2019:3004 None None None 2019-10-16 18:08:09 UTC

Description Antonio Murdaca 2019-09-24 11:27:02 UTC
Description of problem:

in MCO release-4.1 branch we aren't pinning verify tools and always pulling from latest master for tools caused a bad breakage where we cannot compile those tools with go1.10 anymore (1.10 is what 4.1 is pinned to).

Seen in https://github.com/openshift/machine-config-operator/pull/1121 and https://github.com/openshift/machine-config-operator/pull/1119

The fix is pinning the tools as doing in https://github.com/openshift/machine-config-operator/pull/1132 and https://github.com/openshift/release/pull/5162

Version-Release number of selected component (if applicable):

4.1 release branch

How reproducible:


Steps to Reproduce:
1. open a PR against 4.1 release branch in MCO

Actual results:


Expected results:


Additional info:

Comment 2 chris alfonso 2019-09-26 19:57:20 UTC
Please clone the bug to 4.1.z, ensure it doesn't need to be fixed in 4.2 and 4.3. If it's confirmed the issue doesn't exist in any release > 4.1.z, go ahead and close those clones after the fix is verified from 4.1.z onward.

Comment 3 Antonio Murdaca 2019-09-27 06:15:56 UTC
We've been discussing this on slack for the past few days - this bug is _only_ in the 4.1 CI and it doesn't make sense to have a 4.2 or later BZ cause it's of course working - do we really need fake BZs just to track something it's not even in >4.1 releases for a bug which is just 4.1? I find that time-wasting. I understand perfectly the process but this doesn't fall into the process per-se since we're not risking a regression in newer releases (or old ones for that matter). This is again just a 4.1 issue and 4.2/master CI is _of course_ working well.

Comment 4 Kirsten Garrison 2019-09-27 18:52:52 UTC
the label on the pr is failing bc this doesn't target 4.1.z, can we update @Antonio?

Comment 5 Kirsten Garrison 2019-09-27 21:21:56 UTC
This BZ is now blocking another PR: https://github.com/openshift/machine-config-operator/pull/1140

Comment 6 Antonio Murdaca 2019-09-27 21:41:10 UTC
Ian created the other BZs as well

Comment 7 Antonio Murdaca 2019-09-27 21:48:21 UTC
This now has a 4.2.z BZ in Depends on, moving to 4.1.z

Comment 9 Micah Abbott 2019-10-10 12:52:01 UTC
Checking a PR to `release-4.1` after this fix was merged shows that the verify job is working properly - https://github.com/openshift/machine-config-operator/pull/1121

Comment 11 errata-xmlrpc 2019-10-16 18:07:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.