Migrate from DockerHub automation to GitHub Actions

[tuxpeople]

This may close #11 or is at least a first step towards closing it.

It's dockerhub only right now. Let me know if you'd like to have it expanded to use ghcr as well.

What you need to do:

1. Go to your repository settings and add a new secret called DOCKERPASSWORD containing your dockerhub password. (It's here: https://github.com/ansemjo/speedtest-plotter/settings/secrets/actions/new)
2. Open the file .github/workflow/release.yml and check the conten of the vars on lines 15-18 (see description below)

The vars:*

• PLATFORMS (Line 15): Specifies the platforms for which the images are beeing built. You can decide which ones to use, those are the currently available from the build environment: linux/amd64, linux/arm64, linux/riscv64, linux/ppc64le, linux/s390x, linux/386, linux/arm/v7 and linux/arm/v6. Which one to use depends on your own wishes and the availability of the tools/packages used.
• IMAGENAME (Line 16): The name of the image on dockerhub
• DEFAULT_TAG (Line 17): See below
• DOCKER_USER (Line 18): Your dockerhub username.

What the workflows are doing:

• .github/dependabot.yml: This is a dependabot configuration which should check the dependencies and should open pull-requests if
  • a new baseimage is available for your Dockerfile
  • if there's a new version of a dependency of the workflow (eg. Hadolint)
• .github/workflow/pullrequests.yml: This is a workflow which runs for every pull-request. It's a simple one which just do linting and check if the image can be successfully built for x86_64 (aka amd64).
• github/workflow/release.yml: This is the workflow which runs on every push to the branch in line 9 and if you tag a version/release using v*.*.* as pattern. It also has a cron on lines 11/12 to make weekly updates.

More about the Release-Workflow:
Step Generate Build-Args: Not used here. Could be used to do some shell script vodoo to end up with yome buildargs for docker. There is a commented out example lines 28/29 showing the results have to be echoed. They are used on line 86/87 if existing.

Step Checkout: Well,this checks out the repo.

Step Prepare: This step is mainly responsible to define how the image is tagged later on. The first if (Lines 37-50 checks if it runs because you tagged a new release/version. It then breaks apart the tag into its pieces. Example: If you release Version v1.2.3 this if will end with the tags speedtest-plotter:1, speedtest-plotter:1.2, speedtest-plotter:1.2.3 and speedtest-plotter:latest for this image. If you later publish v1.2.4, the tag speedtest-plotter:1.2 on dockerhub will be this .new 1.2.4, while speedtest-plotter:1.2.3 is still there referencing to the former release. Ask me if this in unclear, not sur If I can explain it very well :-) Lines 51/52 is for when it's "just" a push to master, then the image will get the tag specified as DEFAULT_TAG at line 17. I usually use that as follows: For stuff where I do versioning, I use edge or devel for this and leave latest to be only used for the versioned, released versions. But this is up to you. Lines 53/54 may be obsolet since I moved the pull request workflow into a different file.

Step Hadolint: This runs hadolint over the Dockerfile. This helps writing "good" Dockerfiles. See https://github.com/hadolint/hadolint/blob/master/README.md for details. This is the reason I put ignores into the Dockerfile and specified a version for the base image. If you don't like this, just delete the whole step (and also in the pullrequests.yml).

Steps Set up QEMU / Set up Docker Buildx: They prepare the environment

Step Login to Docker Hub: Well.... :-D

Step Build and push: This is the main action. It builds the images, all platforms in parallel. Also tags and labels the images. See 89-95 for the labels beeing added. Review them and decide whether you like that or not. And finally pushes them to dockerhub.

Step Docker Hub Description: Updates the Description on Dockerhub with your current readme.

[ansemjo]

Again, thanks a lot! :)
I've looked through the files and added a few questions / comments (see below). Summarized:

• This may be nitpicky, but I would prefer to name the secret *_TOKEN. At least I won't be using my actual password for this workflow.
• Parametrize the DockerHub username into a secret as well?
• A little clarification about the push to branches. The if clause seems to match all of them? I understand the tag splitting though, that's cool.

I somehow was not aware that you could just use QEMU and build for multiple architectures in GitHub Actions. That's amazing.

[tuxpeople]

Hope it works for you that way :-)

[ansemjo]

Yes, it does! I just needed to add the secrets and disable DockerHub builds before the merge. :)

edit: ha! Dependabot is already off to the races in #14 and #15 :D

[tuxpeople]

Upsi. Sorry for not updating the versions. However, you just got proof it works :D

As you can see in those PR, they run trough the pullrequest workflow as well.

Further reading if you are interested in building multiarch images locally:

https://www.docker.com/blog/multi-arch-build-and-images-the-simple-way/
https://docs.docker.com/buildx/working-with-buildx/

[tuxpeople]

One more thing:

If the workflow is running (eg. because you pushed a change) and you push something else whilst it's running, the first run will get canceled and the next one gets started. It will cause a "false positive" because it's not failing, it just got canceled.

[ansemjo]

However, you just got proof it works :D

Yep. :D I'll merge those as soon as the one currently running for this merge finishes. I see no reason why it should fail, but the compilation of taganaka/SpeedTest logged quite a few warnings on the ARM architectures.
(For my own reference, I mean: https://github.com/ansemjo/speedtest-plotter/runs/2369730337?check_suite_focus=true#step:10:1665)

If the workflow is running (eg. because you pushed a change) and you push something else whilst it's running, the first run will get canceled and the next one gets started. It will cause a "false positive" because it's not failing, it just got canceled.

Aye, I'll keep that in mind.

[ansemjo]

Huh, updating the DockerHub description failed ..

[tuxpeople]

Huh, updating the DockerHub description failed ..

You've used a token, right? I used my password, so I didn't noticed it, but:

Docker Hub Personal Access Tokens cannot be used as they are not supported by the API. See here and here for further details. Unfortunately, this means that enabling 2FA on Docker Hub will prevent the action from working.
https://github.com/peter-evans/dockerhub-description

[ansemjo]

Yeah I did. I've just found docker/hub-feedback#1927.

Unfortunate, but I would rather disable this step for now then.

[tuxpeople]

Comment it out and follow docker/roadmap#115 to get notified once that's changed.