Cirrus: Automate releasing of tested binaries

[cevich]

It's desirable to make archives available of builds containing actual
tested content. While not official distro-releases, these will enable
third-party testing, experimentation, and development for both branches
(e.g. "master") and pull requests (e.g. "pr3106").

• Add a Makefile targets for archiving both regular podman binaries
  and the remote-client. Encode release metadata within these
  archives so that their exact source can be identified.

• Fix bug with cross-compiling remote clients for the Windows and Darwin
  platforms.

• Add unit-testing of cross-compiles for Windows and Darwin platforms.

• A few small CI-script typo-fixes

• Add a script which operates in two modes:

  1. Call Makefile targets which produce release archives.
     Upload the archive to Cirrus-CI's built-in caching system
     using reproducible cache keys.

  2. Utilize reproduced cache keys to attempt download of cache
     from each tasks. When successful, parse the file's
     release metadata, using it to name the archive file. Upload
     all recovered archives to a publicly accessible storage bucket
     for future reference.

• Update the main testing task to call the script in mode Initial checkin #1 for
  all primary platforms.

• Add a new $SPECIALMODE task to call the script in mode Initial checkin #1 for
  Windows and Darwin targets.

• Add a new 'release' task to the CI system, dependent upon all other
  tasks. This new tasks executes the script in mode libpod create and run #2.

• Update CI docuemntation

[cevich]

Note: I have no idea if this will actually work, but I need a PR to see if it does. This is that.

[cevich]

design note: I'm generating the canonical name in the Makefile to enable developers to retain local tarball and not have them clash with each-other as content changes. However, that requires renaming of the tarball when running under CI, and this may be an unnecessary complication. Unf. there are some env. vars. only available under CI, and I'm a bit loathe for the Makefile to depend upon them.

[edsantiago]

This can't possibly work; I'll take a fresh look once these issues are taken care of

[rh-atomic-bot]

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

[cevich]

@edsantiago mind taking a peek at this now that it's working? Also @baude or @jwhonce PTAL since y'all are most heavily involved in the remote-client efforts.

[rh-atomic-bot]

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

[edsantiago]

I've tried very hard to understand all this; I can't. I have, as best I can, confirmed that you've addressed my earlier review comments. I've skimmed the rest of the code, mostly feeling lost. My two comments below may therefore be nonsensical. I'll just approve and hope for the best.

[cevich]

mostly feeling lost.

aww, sorry 😢 Probably a sign that better (any) documentation is needed. Hmmm, or maybe a blog post (advertising availability of automatic binary-builds for testing). I've added both to my TODO list. Thanks for reviewing what you were able, it's still helpful 👍

[cevich]

/test images

[edsantiago]

/test images

[cevich]

/test images

[cevich]

@baude this is good-to-go, PTAL (you originally requested it)

[rhatdan]

/approve

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

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

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 [rhatdan]

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

[baude]

/lgtm