Build docker images through CI

[antondlr]

Issue Addressed

https://github.com/sigp/devops-pm/issues/63

Additional Info

• The anchor binary is now defined in the ENTRYPOINT, meaning we don't need to specify it anymore when running the container: docker run sigp/anchor --help vs. docker run sigp/anchor anchor --help.

• ARM builds are disabled for now as they take [over three hours to complete]. (https://github.com/antondlr/anchor/actions/runs/14017403755/job/39244825764) .
  We can revisit this once we have our first ARM user :-)

• Assumes the secrets DOCKER_USERNAME and DOCKER_PASSWORD are defined. Pulling this from vault is commented out (and untested).

[realbigsean]

One more ask!

there is an interop1 branch that is going to be used for interop, can we also chuck in an auto build for sigp/anchor:interop1

[magick93]

I'm pretty sure cross does this already - cross uses buildx internally.
You can try pulling the manifest from any of the images from https://hub.docker.com/repository/docker/magick93/anchor.

So I'm not sure if docker-multiarch-manifest is needed.

[antondlr]

yeah it is, cross does indeed publish with a manifest but we want the regular (no arch defined) image tag to contain both architectures eventually.
in this stripped down, x86_only version we can skip it indeed and just add the tag. but this works for multiarch, just needs some commenting out.

[antondlr]

ah or do you mean you can push to the same tag and it will append instead of replace, if it's a different arch?
I'll play with it a bit, would be good to get rid of it.

[antondlr]

tested it out; it overwrites the tag altogether.
so for multiarch there are two valid approaches:

• build multiarch manifest manually (what we do here)
• build all architectures in one task and push (with: platforms: linux/arm64,linux/amd64). this slows everything down even more though as both will be built on the same runner instance.

So yeah we can get rid of it, at a cost for actual multiarch builds.
I'm fine with both, do we aim for simplicity or speed?

[dknopik]

If "simplicity" means 3hr builds, i'd vote for speed, at least for now :)

[magick93]

@dknopik

If we consider purely from speed, for now, would the following be an improvement?

• only build docker images on a tag
• only run tests by default

[magick93]

@antondlr - It looks like I'm mistaken. The manifest is not implicitly appended. I've been experimenting on eleel using bake which is basically a wrapper around buildx and depending on which iteration on the matrix finishes last is what is written (overwritten) in the manifest. So I think explicitly updating or appending the manifest would be the reliable way to go.

[antondlr]

yeah this is exactly what I found in testing, too.
also no appropriate config in docker/build-push-action to amend instead of replace :/
luckily it's a pretty fast task to execute!

[jking-aus]

thanks for sorting this out so quick guys -- really appreciate it