add explanation of blocking jobs in master before service streams#43418
add explanation of blocking jobs in master before service streams#43418openshift-merge-robot merged 1 commit intoopenshift:masterfrom
Conversation
openshift-ci
Bot
added
the
approved
openshift-ci-robot
added
the
rehearsals-ack
There was a problem hiding this comment.
| This means that a new job must first become blocking on master before becoming blocking on service | |
| streams in order to be confident that our backports will pass our service stream testing. | |
| If an exception is required due to instability of a job on master, that exception must be accepted | |
| by the party responsible for service stream quality, currently the rotation of patch managers. | |
| This means that a new job must first become blocking on master before becoming blocking on release | |
| branches in order to be confident that our backports will pass our release branch testing. | |
| If an exception is required due to instability of a job on master, that exception must be accepted | |
| by the party responsible for release branch quality, currently the rotation of patch managers. |
I feel like this is a more commonly understood term but maybe I'm wrong. Fine either way.
|
/lgtm |
openshift-ci
Bot
added
the
do-not-merge/hold
deads2k
force-pushed
the
add-explanation
branch
from
10848cd to
7874967
Compare
|
updated word choice. |
|
[REHEARSALNOTIFIER] Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
/hold cancel |
openshift-ci
Bot
removed
the
do-not-merge/hold
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: deads2k, sdodson 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 |
|
@deads2k: all tests passed! Full PR test history. Your PR dashboard. 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. |
4.14, becasue we want to freeze these through the life of 4.14, following the existing pattern, most recently d666767 (ci-operator/config/openshift/release/openshift-release-master__nightly-4.13: Add oldest-* jobs, 2023-04-26, openshift#38728). I'm not pulling in the rollback job this time, because that's moving under QE and is in flight separately in [1]. I'm also adding a 4.15 cred-freeze job this time, to catch up with dbcbb85 (add explanation of blocking jobs in master before service streams, 2023-09-18, openshift#43418). As I pointed out in d666767, I'm still concerned about the amount of churn that I expect will land during the engineering candidate, but I'm not on the release-oversight team, and if they perfer having a blocker job in the development branch with occasional pin bumps, that's fine with me. The bulk of the ci-operator/jobs content is from: $ make jobs But then I manually edited to inject reporter_config, as described in 08db24d (ci-operator/jobs/openshift/release: Ping @Patch-Manager for cred-freeze failures, 2021-12-08, openshift#24177). [1]: openshift#43401
4 participants
This isn't generally obvious, so it's worth explaining in the doc. A linter would be even better, but I'm unsure of where such a linter would be.