Update install documentation & add Build pipeline

[hurzelpurzel]

Refer to the Windows build of user "passcod".

[packit-as-a-service]

Ephemeral COPR build failed. @containers/packit-build please check.

[passcod]

I would much rather this project start producing builds, even copying my config to do so if needed (though one should note that the builds produced are limited in the way pointed out in the readme, and thus might not be considered appropriate), than pointing to my repo.

[hurzelpurzel]

Know I added the Pipeline from @passcod and provided the linuxs build as well.

[mtrmac]

Thanks for the PR.

First of all, we can’t even look at a PR where the DCO is missing.

---

It’s also, still, the case, that I don’t think we can provide useful stand-alone Linux binaries. Compare #1545 and earlier discussion. I’m happy if they work for you, and it’s perfectly fine to publish them, but I don’t think we want to knowingly recommend that path in the official repo.

---

WRT macOS / Windows binaries, I have a much less strong opinion. (I am rather worried that the Windows binary is probably not a good Windows ecosystem citizen, but, well, maybe we got to start somewhere.)

The binaries for those operating systems could be useful, but it’s also something where I know very little. It also needs to align with how the github.com/containers organization has build systems and clouds set up, and what we can commit to watching / maintaining. @cevich , WDYT, at least for an initial triage?

[TomSweeneyRedHat]

@hurzelpurzel thanks for the PR, as @mtrmac noted, please sign it.

@cevich, PTAL when you get a chance.

[cevich]

So in general producing test-builds is a perfectly reasonable thing to do, however they must be very clearly labeled as testing-only builds (if they wreck your universe, we don't care). If this PR wants to go in that direction for the initial implementation, great! I think all that's needed is stripping out the release components (and could drop the version query as well).

"Official" builds must come from a trusted build pipeline and include some form of trust-verification. Both parts are critical and non-trivial to pull off. What happens in podman today is maybe less than ideal, but it works and could potentially be duplicated here:

1. Builds (all platforms all arches) are done manually in a clean-room environment and uploaded to a github pre-release.
2. A dry-run is manually initiated for a github-actions workflow which downloads (from pre-release page) and signs the windows and mac installer binaries. Making them available for manual inspection/testing.
3. Assuming everything is "good", the pre-release is published which triggers the same signing workflow to perform the official signing.

The critical "good-citizen" thing here WRT Windows (and maybe Mac) is the signing can only happen once per version/release. This is because a UUID is generated in the installer that the OS tracks for both uninstall and upgrade purposes. Having duplicate UUIDs per version completely screws this up for end-users.

Hence why there is always a human in the release publishing and signing loop.

[github-actions]

A friendly reminder that this PR had no activity for 30 days.

[mtrmac]

Hence why there is always a human in the release publishing and signing loop.

At this point, to me that is pretty much a show-stopper. Combined with the lack of sign-off…