Create GH Actions workflow to build Docker image

[FintasticMan]

This PR adds a GitHub Actions workflow that builds the Docker image and pushes it to Docker Hub whenever anything in the docker/ directory is changed. I've tested it here, and the images have been pushed here.

Any pull requests should just build the image, but not upload it to Docker Hub. It should also be possible to publish to different tags than just latest by using docker/metadata-action, I just haven't gotten around to that yet.

Before merging, the secret DOCKER_HUB_ACCESS_TOKEN will be needed to be added to this repository.

Issue has been resolved.

[JF002]

@FintasticMan That looks very good 👍 And it even builds for amd64 and arm64 ! 🏅

Regarding the tags : is there anyway to handle them 'automatically'? If you have a look at the docker repo for InfiniTime, I pushed 2 tags when I updated the image : the tag latest and the tag v2. This will allow to pull an older version of the image to build an older version of the project. I'm not sure if this is how we are supposed to handle the versionning of the images, though...

[FintasticMan]

You can definitely push to multiple tags at once, but I'm also not sure of a good versioning system for it. Perhaps it should push to its commit hash and latest.

Another thing I was thinking of doing was pushing the builds to the GitHub Container Repository on pull requests. It would then be put under the username of whoever made the pull request.

[JF002]

@FintasticMan Thanks for your PR #1023! Perfect timing to merge this one so we can test the automatic build :)

You can definitely push to multiple tags at once, but I'm also not sure of a good versioning system for it. Perhaps it should push to its commit hash and latest.

For now, I'm just using an incrementing counter, but I'm doing it manually. Not sure how to automate that using the Action build.

The idea was to keep older versions of the image on the Docker repo along with the new one (latest). Is this something we want/need? Or can I create this "version" tag manually after it has been pushed as "latest"?

[FintasticMan]

I'm not sure if it would be possible to have an incremental counter for the tag. I'm sure that manually adding the image to the "version" tag won't be necessary.

It should be quite doable for the image to be pushed to the tag corresponding to the git commit hash it was built from. This would mean that an image would be pushed to the latest tag and (for example) the 64d329b tag. This would be done using docker/metadata-action.

Is this a good enough solution?

[postlund]

I have done similar things with just a single Dockerfile, where I use the SHA256 checksum of that file as a tag. That makes it easy to detect if anything a has changed. It can quite easily (via a simple python script for instance) be extended to calculate a checksum over multiple files as well.

[FintasticMan]

@JF002 I have now pushed a change that makes it push to latest and the commit shasum. You can see how it looks here. It was pushed by the workflows in this PR: FintasticMan#6.

[JF002]

@FintasticMan that looks good to me! We'll use the commit sha as tags and see if we ever need older tags of the images!

Before merging, the secret DOCKER_HUB_ACCESS_TOKEN will be needed to be added to this repository.

I've never used secrets in Github. Should I create an Environment secret, a Repository secret or an Organization secret?

[FintasticMan]

It needs to be a repository secret.

[JF002]

@FintasticMan What will trigger the build and push of a new image? If I understand correctly, the workflow will be triggered on push and pull-requests on both master and develop? Won't that generate a lot of unnecessary builds

• When you create the pull-request that will be merge on develop
• When the branch is merged in develop
• When develop is merged in master

I think we should try to generate (and publish) the image only when changes are merged in develop. What do you think?

[FintasticMan]

@JF002 At the moment, pushes to develop and master will build the image, and push it to Docker Hub. Pull requests against develop or master will build the image, but not push it anywhere, so that you can easily make sure that it builds properly before merging. Also, it will only run the action if anything in the docker/ directory is changed, so most pushes or pull requests won't do anything anyway.

I think that this is behaviour that makes sense, except for that it should only be for develop, not master. What do you think?

Edit: I've just pushed that change.

[JF002]

@FintasticMan Thanks for those informations about the workflow. It looks good to me!

[JF002]

@FintasticMan So, I've just merged this branch and #1203. I forgot the setup the username in the settings of the project, so it took 1 or 2 trials.
Now, it worked ... except that the image was pushed to the wrong username. Let me explain : the image must be pushed to infinitime/infinitime-build. However, the account infinitime is an organization account, and I cannot create tokens from this account. That's why I created the token from my own user jf002.
Now, I think the workflow must be modified to take that into account : login with jf002 but push to infinitime. Could you have a look at this?

[FintasticMan]

Thanks for the heads up. I'll have a look when I get back to my PC.

[JF002]

@FintasticMan Awesome, thank you very much! I wasn't sure which username needed to be changed! I'll have a look at that PR!