New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cirrus: Simplify only_if/skip + optimize multiarch #14438
Conversation
Examples of tasks created (ignore failed status):
|
2b7a1a7
to
5091eeb
Compare
Re-WIPing this, found a problem that needs fixing. |
26c34e1
to
82da89c
Compare
Force-push: Rebased, added exclusion of all integration-level tasks running on branches where they're less useful. Also added documentation for the various runtime contexts & modes. |
f8cfae9
to
94d78ff
Compare
Force-push: Updated docs. |
3d0d412
to
d82556d
Compare
81cd653
to
9705414
Compare
Using both the 'skip' and 'only_if' features at the same time may be hard for maintainers to decipher. Consolidate them into `only_if` since that bypasses creation of the task all together - meaning there are potentially fewer tasks for a developer to scroll through. Since the `multiarch` Cirrus-Cron build no-longer depends on the direct "build-ability" from the current repo. state, it can be further optimized. When operating in this context, avoid running many/most other tasks, depending instead only on `ext_svc_check`. Finally, add a simple document describing the various runtime contexts along with the list of expected tasks. Reference this prominently right in front of every `only_if` so it's impossible for a maintainer to miss. Signed-off-by: Chris Evich <cevich@redhat.com>
Latest contexts and runtime tests:
|
/hold |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cevich, rhatdan The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Depends on: #14437
Using both the 'skip' and 'only_if' features at the same time may be
hard for maintainers to decipher. Consolidate them into
only_if
sincethat bypasses creation of the task all together - meaning there are
fewer tasks for a developer to scroll through.
Since the
multiarch
Cirrus-Cron build no-longer depends on the direct"build-ability" from the current repo. state, it can be further
optimized. When operating in this context, avoid running many/most
other tasks, depending instead only on
ext_svc_check
.Does this PR introduce a user-facing change?