Add docker image publishing workflows

[Starttoaster]

Sorry for the radio silence on this, I wanted to get to this sooner but I've been extremely busy as of late unfortunately. Eventually carved out time to work on this 😄 Regards #691 FYI @jnichols-git

These workflows should handle building and pushing images to docker hub and github's container registry, using qemu and docker buildx to build for the arm64 and amd64 platforms.

We have two files here:

publish-docker.yaml:

• This will run when a release is created (which excludes prereleases, like release candidates)
• On a release workflow, it creates some semver docker tags (like :x.x.x, :x.x, and :x), it also updates the :latest tag from the latest release code, and creates a :sha-<commit sha long> tag
• This will run on merges/pushes to main
• On a main workflow, it refreshes a :main tag, and creates a :sha-<commit sha long> tag
• It also runs the main workflow on a schedule

publish-docker-prerelease.yaml:

• This will run when a prerelease is created (which is a checkbox in the github UI when creating a release, and is typically used for betas or release candidates)
• On a prerelease workflow, it creates a semver docker tags (like :x.x.x-rc1 for a tagged prerelease like :x.x.x-rc1), and creates a :sha-<commit sha long> tag

A slight change here that I wanted to specifically call out was that this adds a new kind of tag that I don't think you currently do. And this is the tag that will get rebuilt over time from a fresh alpine base. Which is the :main tag. I can also just switch this to be the :latest tag, depending on what you want. But :main gets refreshed every week. :latest will just track the latest released version and will be refreshed every time a release happens. And the semver tags will just be tagged once when a release is cut.

Some important general notes here:

• This begins uploading trickster images to github's container registry, which isn't currently done here. I can strip that out here if you want. I just figure it's valuable to have a second registry and basically free since the workflow should manage tagging/uploading there.
• This relies on a Docker Hub username and access token with read+write privileges in github secrets, which a maintainer here will need to provide.

[Starttoaster]

Ah, my commits are signed but not signed off on. So I'm failing that DCO check. Will fix that but will have to force push it up.

edit: Fixed signoffs.

[Starttoaster]

FYI, I set up mostly the same workflows in a repo of my own just to try them out, and you can see what they did. The only thing I think I stripped out was the docker hub login, for testing purposes I'm just using github's container registry. But here: https://github.com/Starttoaster/ci-playground
I created a release tag, a pre-release tag, and just ran CI against a push to main. Those created the following tagged version https://github.com/Starttoaster/ci-playground/pkgs/container/ci-playground

[Starttoaster]

I notice in Docker Hub, there's a trickstercache user, a tricksterproxy user, and a tricksterio user, that all claim to own the trickster image. Are these all you? Did I even choose the right one in my pull request? 😄

[Starttoaster]

I just switched this to trickstercache because I saw that's the user called out in the readme here.

[Starttoaster]

But is it actually all 3 of them? And if so, is there a reason besides something like a typo-squatting defense?

[Starttoaster]

Closing. I think there's a lack of interest here. I'm just going to own my fork of this repo with security patches :)