MCD RPM and os container builds for 4.2+ branches#5572
MCD RPM and os container builds for 4.2+ branches#5572openshift-merge-robot merged 1 commit intoopenshift:masterfrom
Conversation
openshift-ci-robot
added
the
size/S
|
MCD should be built from |
|
See also #5557 |
|
Doesn't it make sense to also add MCD builds for OCP on Prow either way? I was under the impression we were missing those so far. |
LorbusChris
changed the title
openshift-ci-robot
added
the
do-not-merge/work-in-progress
|
Do I need to add the missing image ref manually or how is that done? |
|
If we’re gokng to have separate branches let’s make the branch name “fcos”. Then we can stitch those in as replacements for the others |
|
so I think we need #5603 as a prerequisite then |
|
Oooooo.... I understand now why you're doing this. This is because oc shimmed in to origin, rather than splitting. Hrm.... this might still be the right thing to do then. Let me look. |
LorbusChris
changed the title
openshift-ci-robot
removed
the
do-not-merge/work-in-progress
|
let's get this working on the fcos branch first (#5659) |
openshift-ci-robot
added
the
do-not-merge/hold
openshift-ci-robot
added
size/L
LorbusChris
changed the title
openshift-ci-robot
added
the
do-not-merge/work-in-progress
LorbusChris
changed the title
|
/retest |
LorbusChris
force-pushed
the
mco-rpms
branch
2 times, most recently
from
045bf60 to
b36f703
Compare
|
/retest |
LorbusChris
force-pushed
the
mco-rpms
branch
from
b36f703 to
db7287f
Compare
Porting openshift#5659 openshift#5681 openshift#5695 to all branches from 4.2 to master
LorbusChris
force-pushed
the
mco-rpms
branch
from
db7287f to
7a3ebbf
Compare
|
/retest |
1 similar comment
|
/retest |
|
/hold cancel |
openshift-ci-robot
removed
the
do-not-merge/hold
|
/retest |
1 similar comment
|
/retest |
|
@LorbusChris: The following tests failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. DetailsInstructions 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/test-infra repository. I understand the commands that are listed here. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: LorbusChris, vrutkovs The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
@LorbusChris: Updated the following 13 configmaps:
DetailsIn response to this:
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/test-infra repository. |
|
Reverting, looks like machine-config-operator is being used as machine-os-content (likely a cut and paste error). |
|
@smarterclayton can you specify what exactly went wrong here? |
|
Why was this merged without having anyone from the MCO team look at it? @LorbusChris |
|
Besides why this was merged w/o any of the MCO members looking at it, we'd need a better process for the fcos branch and better code ownership (using tide?) to avoid this happening in the future. |
|
Thank you @runcom for the update. The failing is not the PR itself -- the point of a PR is to have a process to catch the problems before they land. In this case, the merge happened because:
So even if an MCO member had looked at it, the merge could have happened anyway. The PR was not the problem, it was tooling around it. The relevant question that needs to be answered now is who is in a position to make those changes? |
|
As a point of overall teamwork, in the MCO repo (for example) we do not merge things directly affecting other groups without having them give the LGTM. This isn't only to get the substantive review but to give visibility to the affected parties. In this case that visibility would have enabled us to fix this in day 1, as opposed to taking us 2 days to find the root cause as we were completely unaware of this PR. Agree that having the bot ping MCO would be ideal and that this FCOS branch ownership needs better resolution. But that said, we can and should ensure that when the bot fails to ping appropriately, we resolve that manually. This is about ensuring open communication and visibility for the health of the project. |
@kikisdeliveryservice would you create and start a doc that highlights what you would see here to prevent such scenario? I don't have anything right now but you seem to so I think it would be beneficial to start on that and avoid falling into this again |
Happy to do so @runcom 👍 |
9 participants
Porting #5659 #5681 #5695 to all branches from 4.2 to master
Blocked by: openshift/machine-config-operator#1226 and openshift/machine-config-operator#1249
As a follow up, we could also backport openshift/origin@cbd4377 to 4.2 in the origin repo.