GitHub action for automatic multiarch Docker build #1613
Conversation
TR-SLimey
changed the title
In case something needs to be tweaked in the future, the link contains some examples and explanations which would be useful
|
We probably only want this to execute for tags if I'm honest. We push to master frequently. My Github Action-fu isn't great, so I'll go over this properly later on. |
|
Yeah, I actually thought about that after opening the PR but didn't have time to change it. I'll look into it though when I have a minute. |
As this workflow takes quite a lot of time, and [pushing to master happens frequently](#1613 (comment)), the container will now only be built when a release is created, and the builds will also be correctly tagged.
|
That should do it :D |
|
Passing this to @anoadragon453 who has more GH Actions knowledge than I. |
There was a problem hiding this comment.
Heads up secrets are added to a repository via https://github.com/matrix-org/dendrite/settings/secrets/actions.
Looks mostly sane. It'd be nice to test this in a separate branch (or pushing to a temporary user?) before pushing to production with it.
I'll need to check internally whether we're happy pushing to docker hub via github actions, but I'm not against it personally.
Just a small q below.
| username: ${{ env.DOCKER_HUB_USER }} | ||
| password: ${{ secrets.DOCKER_TOKEN }} | ||
| - | ||
| name: Build temporary (builder) image |
There was a problem hiding this comment.
Why are we calling this a temporary builder image?
There was a problem hiding this comment.
From what I've gathered, that's the image which contains the go toolchain and which builds Dendrite, and only the binaries get copied to the actual monolith and polylith images (to save space I believe - Neil mentioned this somewhere), while this image is just discarded, hence it is temporary and a builder. That's mostly just from a quick glance at the Dockerfiles though so I may be wrong.
EDIT: Having checked, I also can't find the dendrite image in matrixdotorg's docker repo (only the -monolith and -polylith ones) so it does indeed seem temporary.
EDIT 2: As for testing, I think the easiest way is to just (1) fork Dendrite, (2) paste this into the correct file replacing matrixdotorg with a test user, (3) create a token for the test user, (4) create a dummy release.
There was a problem hiding this comment.
Cool OK, and thanks for the info. Do you want to try that testing strategy? Otherwise I can do so sometime tomorrow possibly.
There was a problem hiding this comment.
I've done those tests already on my fork ( I'm nowhere near confident enough to open a PR without testing :P ), and it seemed to work pretty well, but I think it might be good for you to test also, to avoid "works on my end" kinds of bugs :P
|
Testing against |
Fixing a noisy error message for dendrite /sync routine Co-authored-by: Brian Meek <brian@hntlabs.com>
Not sure if this is something you'd want to do or not, but I figured I'd open a PR as a proof of concept anyway.
I've just created a GitHub action which builds the Dendrite docker image on release using buildx, and then pushes the image to docker hub while tagging it with the release version also ( saves me building unofficial images every release :P ).
By default it produces
linux/amd64,linux/arm/v7andlinux/arm64variants to match Synapse, but obviously that can be tweaked easily.Note: If you do merge this, don't forget to create the
DOCKER_TOKENsecret.Signed-off-by:
tr_slimey@protonmail.com | @tr_slimey:an-atom-in.space