[Docker] Add support for arm32/64

[Bockiii]

This adds arm32v7 and arm64v8 containers to the dockerhub "latest" tag.

To see how this looks like on dockerhub, check my test image:

Latest tag containing all three architectures: click

Build Rules:

You would need to change the branch name to "master" but keep everything else exactly how it is (docker tag and dockerfile location with the names).

The way the post script works is that you will have to run all image generations at least once (it will fail once for every image). Starting from the second run, all images will be flagged as "successful". That is because the post script wants to link all 3 images under one tag. If you are building them one by one, this step will fail every time because at least one of the images is not available at that point. This will solve itself on the second run though.

[Bockiii]

Also touches #2099

[em92]

Looks fine for me.
@captn3m0, asking for your review as you introduced Docker.

[captn3m0]

This is magic 💯.

This is how the build rules currently look:

There's 3 tags pushed: latest (for what's on master), stable (for the last tag that was pushed), and $tag (for the actual tags themselves).

This PR would only work for the first, and not the remaining 2 builds. The setup instructions (in Wiki and elsewhere) always recommend installing the latest stable release - hence I'd prefer if this could be made to work with all 3 of the builds (since latest might not always be the best version to run).

If it's too much work, we can merge this for just latest support for ARM builds (I'll setup the rules on Docker Cloud), and add the others in a separate PR.

[Bockiii]

I'll check out if I can combine all 3 builds into my script.

As a general thing though: 90% of people use the :latest tag.. usually. No one is going to use a version tag from 2019 (so they are basically garbage laying around), no one should actually use a container from 2019 (os version updates, security etc), so it's almost dangerous to still have them up.

Also, as a user, if I see that "latest" is 10 days old and "stable" is 10 months old, i'm going with latest.

So in my opinion: Get rid of the individual tag builds (the third row) and maybe keep the "stable" that updates on tag pushes.

@captn3m0 opinions?

[Bockiii]

Ask and ye shall receive. I added a second manifest file for the stable tag.

This is what it will look like on dockerhub:

You need to set up the auto builds like this:

Use "master" for the latest builds of course. Keep the rest as is.

Again: The builds will fail on the first run because the post action will fail. You will have to re-run the builds once all images have been built once. Then they will all succeed (as you can see on the screenshot).

[Bockiii]

Also, I wouldn't build a release specific tag anymore. With latest and stable, all use cases should be satisfied without creating a giant backlog of versions and also keep everyone on a somewhat recent version.

Maybe even delete the old tags after the move so people will have to switch to either latest or stable.

[captn3m0]

I agree nobody should be running old versions, but it's nice to have a tag for each version. We provide the older releases on GitHub as well, doesn't mean we endorse running them. Having an older docker image might be helpful in some cases: makes debugging easier for one, lets you downgrade temporarily in case the new release has a breaking change you can't adapt to yet etc.

Using latest tags also causes concerns with some deployment patterns (k8s considers using latest an antipattern for eg).

Setting up the docker cloud rules 👍🏽

[captn3m0]

Updated the rules on DockerHub. This can be merged and tested 💯.

[Bockiii]

I'm reworking the approach, dont merge yet

[Bockiii]

Alright, I did a full rework of the process, 'inspired' (read "almost copied it all") by https://github.com/ckulka/baikal-docker .

You need to configure the dockerhub builds like this:

This is easier to maintain, easier to read and does all three things wanted:

• "latest" tag with all three architectures, updated on each new commit
• "stable" tag with all three architectures, updated on release
• version based tag (e.g "2021-05-06") for longer availablity for a specific version, also with all three architectures.

Please review this new setup and test it.

I will create a new PR at the end for merging since this one became pretty chaotic.

[Bockiii]

This also won't fail on the first run @captn3m0 since this splits the build and the push. So one run and you're good to go.

And also: Change the branch name to "master" of course

[Bockiii]

So @captn3m0 I assume thats a positive review? @em92 do you want another docker person to look at it? If not, I would generate the clean PR and link this one.

[captn3m0]

I'll test it by tomorrow and confirm.

[Bockiii]

Also, today I learned something new :D How to squash and fixup commits. So I won't be creating a new PR, I'm just going to fixup all the commits in this one into one.

Yay git :)

[captn3m0]

Builds look good. This can be configured for all 3 builds right?

[Bockiii]

Correct @captn3m0 . I squashed the commits so now it's only one. Setup the builds like in my last screenshot and it should be good to go.

[Bockiii]

@em92 when you merge the commit, you will have to do a release to trigger the stable and version builds . after that, you should probably go into dockerhub and delete all versions prior to the latest and maybe the last 2 named versions. All other tags can go.

[captn3m0]

Just to note: Build rules are configured correctly. So this can be merged 👍🏽.

[em92]

when you merge the commit, you will have to do a release to trigger the stable and version builds . after that, you should probably go into dockerhub and delete all versions prior to the latest and maybe the last 2 named versions. All other tags can go.

TBH, I am not owner of that docker hub account. @captn3m0 is. So probably that message is for him.

[em92]

Looks like everything is working.
gj @Bockiii and @captn3m0 !