Bug 1754924

Summary:	CI: fix verify tools build failure
Product:	OpenShift Container Platform	Reporter:	Antonio Murdaca <amurdaca>
Component:	Machine Config Operator	Assignee:	Antonio Murdaca <amurdaca>
Status:	CLOSED ERRATA	QA Contact:	Michael Nguyen <mnguyen>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	4.1.z	CC:	calfonso, kgarriso, miabbott
Target Milestone:	---
Target Release:	4.1.z
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1756384 (view as bug list)		Environment:
Last Closed:	2019-10-16 18:07:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1756384
Bug Blocks:

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:

always

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

Actual results:

fail


Expected results:

pass

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.

https://access.redhat.com/errata/RHBA-2019:3004