ci-operator/jobs/openshift/release: Add 4.y-nightly -> 4.(y+1)-nightly #6542
Conversation
For 4.2->4.3 and 4.3->4.4. I've left off 4.1->4.2, since 4.1 is pretty old and stable. I've left off 4.4->4.5, because we haven't built a 4.5 nightly yet [1]. This should help catch breakage like the ephemeral-storage request that broke 4.2 -> * updates [2], but didn't turn up in CI because we don't have any jobs testing nightly -> updates. After this commit we'll have: * endurance-upgrade-aws-4.3 I'm not really clear on what this does. Seems to use the template from 39e69e2 (add long lived cluster management job and e2e test, 2019-06-12, openshift#3887). Seems to use 4.3-ci -> self updates? I dunno. * release-openshift-origin-installer-e2e-aws-upgrade-4.3 Lets the release controller or ci-operator or some such choose the source and target version. * release-openshift-origin-installer-e2e-aws-upgrade-fips-4.3 4.3-ci penultimate -> 4.3-ci latest on AWS with FIPS enabled. * release-openshift-origin-installer-e2e-azure-upgrade-4.3 4.3-ci penultimate -> 4.3-ci latest on Azure * release-openshift-origin-installer-e2e-gcp-upgrade-4.3 4.3-ci penultimate -> 4.3-ci latest on GCP * release-openshift-origin-installer-e2e-aws-upgrade-4.2-to-4.3 4.2-stable -> 4.3-ci on AWS. * release-openshift-origin-installer-e2e-aws-upgrade-4.2-nightly-to-4.3 4.2-nightly -> 4.3-nightly on AWS. New in this commit. * release-openshift-origin-installer-e2e-aws-upgrade-rollback-4.2-to-4.3 4.2-stable -> 4.3-ci on AWS with TEST_OPTIONS=abort-at=99. For more on abort-at, see openshift/origin@a53efd5e27 (Support --options on upgrade tests to abort in progress, 2019-04-29, openshift/origin#22726). * release-openshift-origin-installer-e2e-aws-upgrade-rollback-4.3 4.3-ci penultimate -> 4.3-ci latest on AWS with TEST_OPTIONS=abort-at=random. and similarly for 4.4. I'm not entirely clear on how the release informer jobs ingest the version being considered for promotion, maybe these new jobs will end up just being vanilla periodics. But that's probably fine, because all we need is some sort of signal in CI to show that 4.2-nightly -> 4.3 (or whatever) is broken before we give that 4.2 nightly a stable name like 4.2.13 (or whatever). Even if these do run as 4.3 promotion informers, breakage like [2] happened in the 4.2 nightly. So you could still have: 1. 4.2 PR lands and breaks 4.2 -> 4.3. 2. Associated 4.2 nightly promotion goes through all green. 3. Some subsequent 4.3 change lands, and the informing job fails because of the 4.2 change from step 1. But again, as long as we have some kind of signal (like the one added by this commit), the release admins should hear about it and know that they need the breakage triaged before they give a nightly a stable name and sign the release. [1]: https://openshift-release.svc.ci.openshift.org/#4.5.0-0.nightly [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1786315#c2
openshift-ci-robot
added
the
size/L
|
Lgtm after the rehearse jobs finish (and appear to do right thing) |
|
/lgtm |
|
@wking: 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: 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 following 2 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. |
4 participants
For 4.2->4.3 and 4.3->4.4. I've left off 4.1->4.2, since 4.1 is pretty old and stable. I've left off 4.4->4.5, because we haven't built a 4.5 nightly yet. This should help catch breakage like the ephemeral-storage request that broke 4.2 -> * updates, but didn't turn up in CI because we don't have any jobs testing nightly -> updates. After this commit we'll have:
TEST_OPTIONS=abort-at=99. For more onabort-at, see openshift/origin@a53efd5e27 (Support --option on upgrade tests to abort in progress origin#22726).TEST_OPTIONS=abort-at=random.and similarly for 4.4.
I'm not entirely clear on how the release informer jobs ingest the version being considered for promotion, maybe these new jobs will end up just being vanilla periodics. But that's probably fine, because all we need is some sort of signal in CI to show that 4.2-nightly -> 4.3 (or whatever) is broken before we give that 4.2 nightly a stable name like 4.2.13 (or whatever). Even if these do run as 4.3 promotion informers, breakage like rhbz#1786315 happened in the 4.2 nightly. So you could still have:
But again, as long as we have some kind of signal (like the one added by this commit), the release admins should hear about it and know that they need the breakage triaged before they give a nightly a stable name and sign the release.