cirrus: minor cleanup and refactoring

[edsantiago]

...with the goal of (very soon) reusing this code, in #2947,
to run system tests in CI. This is the cleanest way I can
think of to do so without duplication or a large maintenance
burden.

Changes are:

• replace references to 'ginkgo' with 'integration'. That
  target is already in Makefile, and is not only more
  readable, it's also more abstract. There is no reason
  for this level of code to know about ginkgo.
• replace a 'noxxx' option with the more usable 'xxx'
  • and fix a logic bug: the '-n' (no-remote) option
    should not be treated as an actual test-defining
    argument option.
• allow rootless_test.sh to accept an argument,
  that being the name of the test suite to run
  (default: integration). run BATS tests in Cirrus #2947 will enable 'system'.
• allow integration_test.sh to serve multiple purposes,
  by checking its filename. run BATS tests in Cirrus #2947 will add a symlink,
  system_test.sh, which will then cascade down to
  invoke system tests.

Signed-off-by: Ed Santiago santiago@redhat.com

[edsantiago]

@cevich PTAL; this is intended as a prerequisite for the review feedback you gave on #2947.

[cevich]

LGTM with one big-picture concern, if not fixed here, something that should be done in another PR. I do not see any end to growth in the number of testing-permutations - A likely next one will be STORAGE_DRIVER related. Something to consider, and I'm interested in your thoughts on fixing it.

[cevich]

LGTM

@baude @mheon wanna peek?

[edsantiago]

This unfortunately hard-conflicts with @baude's #3236

[cevich]

This unfortunately hard-conflicts

Yeah, we've been needing some change in this area for a while. It's okay, code-conflicts just mean we should clunk our heads together until a more holistic solution presents.

The current design has most flows running through intergration_test.sh, all with slight permutations on the meaning of "Integration test" (and how it's run). There's a lot of duplication in Brent's old container_test.sh too (which was originally used to handle multiple different testing styles and setups).

As you noticed before from my comments, I'm a bit torn between the different approaches, I like both separate/simple scripts and grand-poo-bah --with --options.

Perhaps if we all "tat and sinkt bout it" together, with a drawring of our matrix, that would help?

[rh-atomic-bot]

☔ The latest upstream changes (presumably #3236) made this pull request unmergeable. Please resolve the merge conflicts.

[edsantiago]

Rebased

[cevich]

/lgtm

[baude]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [baude]

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

[cevich]

/retest