ci-operator/config/openshift/origin/openshift-origin-master: Rollback AWS update jobs #16911
Conversation
… AWS update jobs Like the cluster-version operator has been doing since db0d358 (CVO: add rollback tests for 4.6+, 2020-10-14, openshift#12789), and which we used to do much more broadly until 6663962 (upgrade workflows: remove abort-at from default TEST_OPTIONS, 2020-10-08, openshift#12544). I'm personally in favor of the broad approach, because we want minor rollbacks to work, so if we break master->PR rollback, we're in big trouble. But even with the narrow scoping for rollback jobs, origin's test are implementing and monitoring the rollback functionality, so they deserve to have a local test excercising it. I've added this to the AWS update job, because Clayton wants it to be optional, and the AWS update job has been optional and not always-run since it was born in bd85872 (add optional e2e-aws-upgrade job, 2020-08-10, openshift#10785).
wking
force-pushed
the
rollback-origin-job
branch
from
eedf2b1 to
e8bc08d
Compare
wking
changed the title
|
With eedf2b1 -> e8bc08d, I've pivoted to use AWS update jobs, which have been |
|
The test binary can't break rollback, it can just break our ability to test rollback, which is a less worrisome condition. |
|
True. Still helps with things like "have you tested this?". |
|
Yes I want the optional job, just not convinced it's required by default. |
|
Can you make it optional? |
|
The AWS job I've attached it to now was born |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: smarterclayton, wking 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 |
openshift-ci-robot
added
the
approved
|
@wking: Updated the
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. |
4 participants
Like the cluster-version operator has been doing since db0d358 (#12789), and which we used to do much more broadly until 6663962 (#12544). I'm personally in favor of the broad approach, because we want minor rollbacks to work, so if we break master->PR rollback, we're in big trouble. But even with the narrow scoping for rollback jobs, origin's test are implementing and monitoring the rollback functionality, so they deserve to have a local test excercising it.