Release redo

[cevich]

The initial implementation was far more complicated than necessary.
Strip out the complexities in favor of a simpler and more direct
approach.

Note: The new cross-compile tasks will likely fail when this
merges, due to the container image not being built yet
(they're defined in this PR). Re-running them after 30m or so
should allow them to pass.

[cevich]

@jwhonce @baude @mheon the 'release' task is badly broken and far too complex. This is the beginnings (somewhat incomplete / untested) re-implementation. Key elements are:

• No more 'release' task
• Fixed & re-purposed (broken) 'brew-pkg' Makefile target for windows and darwin
• Produce the release archives directly in the testing tasks (cross-compile-test for windows|darwin)
• Use the just built & tested podman, with a purpose-built container, to upload the archives.
• For podman on linux, make a tarball
• For podman-remote on windows/darwin, use a zip file

PTAL at the Makefile - it seems to work for me. Better this way?

Should I put back the old 'brew-pkg' target, and if so, does the archive-subdirectory have to be 'brew'?

[jwhonce]

@baude , If @cevich is going through all this work should a linux podman-remote tarball also be created for completeness?

[cevich]

going through all this work

Arguably it's necessary work, the current implementation is too complicated and broken. Simplification was demanded, but you're correct to ask "while I'm at it"...

should a linux podman-remote tarball also be created for completeness?

At this stage, this would be a nearly trivial addition.

[rh-atomic-bot]

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

[ashley-cui]

@cevich I would prefer if the subdir would not be named podman-remote, since from a user on the Mac's point of view, podman is just podman, and not very remote. Shouldn't be a big deal though, the version'd folder could work fine.
I'm not really familiar with webhooks, but it would sound ideal if podman in homebrew could be updated every time a version is released. The webhook would need to edit a ruby file and open a PR for homebrew. If this is possible, let me know and I can take a look at it or something. (probably would need help though)

[cevich]

I would prefer if the subdir would not be named podman-remote, since from a user on the Mac's point of view, podman is just podman, and not very remote. Shouldn't be a big deal though, the version'd folder could work fine.

oh okay, no problem, I put it back to 'podman-$VERSION'. I'd like to include the version number in the sub-dir name, since for humans that prevents clashes when unzipping. However, it can be a pain for automation to deal with, since the number will inevitably change.

If you have a mac, take a peek and make sure this works: https://storage.cloud.google.com/libpod-pr-releases/libpod-remote-pr3710-darwin---amd64.zip

I'm not really familiar with webhooks, but it would sound ideal if podman in homebrew could be

They're simple in concept: It's just a URL that automation would send some custom JSON to. In other words, it's just a REST API endpoint. I'm not familiar with homebrew to know if this is supported or not. It's fairly common for SaaS tools to have them, so worth checking their docs.

updated every time a version is released. The webhook would need to edit a ruby file and open a PR for homebrew. If this is possible, let me know and I can take a look at it or something. (probably would need help though)

A webhook is a one-shot deal, though the JSON can be whatever is required. If homebrew does not support webhooks, it is possible ti bolt-on automation to do what you describe. The down-sides are:

• It doesn't care if there's a human on the other end or not. It will gladly open up 10,000 PRs. This could be limited to only running for tagged-releases (every few weeks), but it still will not care if it's 1 or 100 (if something goes wrong).

• it's somewhat involved (from a security standpoint) to (safely) automate opening of PRs. I know how to do it, but it's likely a week or two worth of work (including testing), so we should try to avoid this if possible.

[rh-atomic-bot]

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

[ashley-cui]

oh okay, no problem, I put it back to 'podman-$VERSION'. I'd like to include the version number in the sub-dir name, since for humans that prevents clashes when unzipping. However, it can be a pain for automation to deal with, since the number will inevitably change.

If you have a mac, take a peek and make sure this works: https://storage.cloud.google.com/libpod-pr-releases/libpod-remote-pr3710-darwin---amd64.zip

It looks like the docs are missing in the zip file, other than podman.1. It should have all the relevant docs generated by the remote-docs script.

A webhook is a one-shot deal, though the JSON can be whatever is required. If homebrew does not support webhooks, it is possible ti bolt-on automation to do what you describe.

Okay, I think it's just for the best to open the PR's manually once a new version is released, but we can definitely configure a webhook to upload the zip file asset triggered by a new release

[cevich]

It looks like the docs are missing in the zip file, other than podman.1.

Oh, thought it was expected to be that way 😄 I'm a bit worried about the size of this PR, want me to fix that here or can do it in a separate one?

Okay, I think it's just for the best to open the PR's manually once a new version is released

At first, for sure yes. Bother me after a while, if you find that too tedious, and I'll help try and figure something out or dig into docs more. It's definitely possible to trigger "stuff" from libpod CI running on master only when a new release tag is added. So we just need to figure out what "stuff" isn't an overwhelming amount of work 😄

[rhatdan]

/approve

[openshift-ci-robot]

[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:

• OWNERS [rhatdan]

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

[ashley-cui]

Oh, thought it was expected to be that way I'm a bit worried about the size of this PR, want me to fix that here or can do it in a separate one?

Either works for me 😄

At first, for sure yes. Bother me after a while, if you find that too tedious, and I'll help try and figure something out or dig into docs more. It's definitely possible to trigger "stuff" from libpod CI running on master only when a new release tag is added. So we just need to figure out what "stuff" isn't an overwhelming amount of work

I believe the workflow should be this: libpod CI is triggered when a new release tag is added, and uploads zip file as a release asset via github api 1 2. Then, to get this zip file into homebrew, we need to fork the brew repo, update it, and open a pr against their master. The brew part is what would happen by hand for now. If you have any ideas on how to automate the last part, let me know and maybe we can figure this out together? 😊

[rhatdan]

LGTM
@cevich @ashley-cui Is this ready to go in?

[cevich]

let me know and maybe we can figure this out together

@ashley-cui Yes, that's the workflow I have in mind, and yes, I'm happy to help. This PR ready to go in then, so we can get started on the followup items?

[rh-atomic-bot]

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

[cevich]

Opened #3899 as followup for docs

[baude]

/lgtm