[CI:DOCS] Cirrus: Ability to skip most tests for docs updates

[cevich]

Warning: skip has non-obvious side-effects vs only_if:
https://cirrus-ci.org/guide/writing-tasks/#conditional-task-execution

The skip instruction can give a false sense of security by always
marking tasks as passed in the UI, even if they didn't run. In
contrast, the only_if condition will avoid creating the task
all -together; therefore, a problematic task's absense is more likely to
be noticed if it introduced a problem.

Note: I left the OSX build in because it actually does some platform-specific docs-manipulation we want exercised.

[mheon]

LGTM

[TomSweeneyRedHat]

Is this taking over for #7797? Looks like it's working better.

[edsantiago]

Looks like we collided. I went with skip because it was easy for my map maker to parse and because positive logic (skip if PR =~ CI:DOCS) is more readable and maintainable than negative (only if PR !~ CI:DOCS).

[edsantiago]

LGTM, modulo one request for DRY. I like how this approach doesn't have all the nasty gray bullet clutter that skip does. Map attached for those who find it useful for review.

[cevich]

I went with skip because it was easy for my map maker to parse and because positive logic

@edsantiago warning...danger..danger: skip has non-obvious side-effects vs only_if:
https://cirrus-ci.org/guide/writing-tasks/#conditional-task-execution

The skip instruction can give a false sense of security by always marking tasks as passed in the UI, even if they didn't run. Therefore, this includes if the PR actually breaks something in one of those green-but-skipped tasks.

Consider the position of some future CI-failure analyst: They must go trolling back through multiple CI builds, trying to find the one that broke something. If the culprit was a [CI:DOCS] task, they are much more likely to notice if it did not run the broken task, as opposed to seeing all tasks are all green. That's why I deliberately chose to use only_if over skip, the former doesn't create the task at all, the later does and then lies about it's status.

[cevich]

Rebased and updated w/ Ed's anchor/alias suggestion. I also updated the commit and PR message to make clear the reasoning behind only_if vs skip usage.

[cevich]

Clarification: What I mean by false-success status can be seen in this PRs twin, in the WebUI: https://cirrus-ci.com/build/6731773184835584

[edsantiago]

/lgtm
/hold

[cevich]

@edsantiago is there some reason why we're holding on this? Did I forget something important again?

[edsantiago]

No reason to hold, I just use that convention to allow you to hold-cancel or to solicit further review; i.e. to leave that decision up to you.

[cevich]

Oh whew! okay, thanks.

[cevich]

/hold cancel

[edsantiago]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cevich, edsantiago

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:

• OWNERS [edsantiago]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment