Automate publishing multiarch images to GHCR (migrate away from Docker Hub)

[klardotsh]

Supercedes #390 by building multiarch images in GHCR rather than depending on local workstation builds.

Blockers: https://github.com/orgs/zulip/packages/container/package/zulip needs to be made public, and I need to verify that this repo actually has permissions to push to that registry (while I'm an admin of the registry, I'm not an admin of this repo, so can't double-check the secrets plumbing behind the scenes that I vaguely recall being a thing to do here).

Right now it'll push a SHA-tagged image for the tip of any PRs to main, and then push whatever IMAGE_TAG is + :latest for merges to main, which in general should provide both debuggability of images and of GHA workflows, as well as The Expected Behavior for automatic public-facing image publishes. Open to tinkering with these conditions if necessary.

[klardotsh]

Hm, someone with admin rights needs to OK the new (forked) actions I believe, for those to get tested here.

[andersk]

I don’t think it’s worthwhile to maintain an extra changelog when we already have Git.

Can we have things trigger based on the names of Git tags pushed to the repository, rather than maintaining this file?

[klardotsh]

Yep, we can definitely do that easily in GHA. The only tradeoff is "how automatic will this be?" - as authored, as soon as this file changes in main, a new GHCR tag is cut, meaning 0 human interaction required post-merge to get Docker image changes published. The tag method is 1 (small) interaction that - so long as the same naming scheme is followed - comes with no other tradeoffs I can think of.

[andersk]

Editing a file is an interaction too. We want the Git tags to be there anyway; they’re self-documenting, more flexible (e.g. we could push a tag that isn’t on main for an emergency patch release), more standard, and simpler. So I think we should go with that.

[klardotsh]

Mmm yeah the non-main case seems especially useful of an addition here. I'll patch this up.

[andersk]

Hm, someone with admin rights needs to OK the new (forked) actions I believe, for those to get tested here.

There doesn’t seem to be a way to do that.

[klardotsh]

Ah right the workflows still belong to my fork (as seen by the syntax errors in https://github.com/klardotsh/docker-zulip/actions before I fixed and rebased those out) until merged into main, unless we configure to allow forked workflows: https://github.blog/2020-08-03-github-actions-improvements-for-fork-and-pull-request-workflows/

(there's a corner case probably not worth solving here that while we might want this forked run to have access to secrets, we don't want most forked runs to have access to secrets, and I forget if there's one-off toggles to allow one PR to have access to secrets...)

[andersk]

If you were to reopen this PR from a branch in zulip/docker-zulip rather than a branch in klardotsh/docker-zulip, would that suffice?

[klardotsh]

That's an excellent question. Let me try that with a new PR number and find out :)

[klardotsh]

Two step process: #396 helped me isolate where a syntax error was in the original PR (which didn't report on my fork, from what I can tell), but wasn't ultimately necessary (pushing that same commit series here triggered a build).

[klardotsh]

Closing in favor of #397, because this branch indeed needs to be within the org to push to the repo (push permissions aren't granted to forks and the CI runs in the context of the fork in this case).