GitHub Actions workflow to build multi-arch images

[heussd]

This is a GitHub-Actions-only-solution to build and push alpine/git Docker images automatically in multiple architectures (linux/amd64,linux/ppc64le,linux/s390x,linux/arm64,linux/arm/v7,linux/arm/v6).

Steps to activate:

1. Change back the image name from heussd/git -> alpine/git
2. Create a Dockerhub Access Token
3. Configure DOCKER_USERNAME and DOCKER_PASSWORD as GitHub CI/CD secrets

With using this, all other build-scripts in this repository (multi-arch-image.sh, build.sh, Makefile) are not necessary anymore.

[barthy1]

Hi @heussd ! Great that you provided some sample how to use Github actions. I really like this approach and how easily it can be used to get multi-arch image. However, I find the current code not fully covered existing functionality. 1) As far as I can see docker push will be done every time for code in PR, that is not how it should be done. As new image build should be done only when PR is merged 2) build.sh is used to build several images depending on conditions and to produce different tags

Do you feel you can update your PR to resolve problems mentioned above?

[heussd]

Hi @barthy1, you are right, the PR does not cover every existing functionality yet.

Sure, I will have a look into build.shand see how I can replicate it with GitHub Actions. I will also have a look on how to adjust the pushes 😄

[heussd]

Hi @barthy1 , so I did some updates and I hope I got everything covered:

• Produce many different tags for different platforms. This is done via docker buildx bake - which automatically builds images in parallel for multiple architectures and tags them as configured (see docker-bake.hcl).
• TAG_VERSION and NEXT_TAG are essentially the same like before but are now calculated within the workflow
• GIT_VERSIONis retrieved from the alpine package manager installation messages while building a throw-away image.
• The last step automatically tags the build with NEXT_TAG
• The whole pipeline is only triggered after merges into master.

See this Dockerhub page to see what is build and pushed after just one single execution.

I think it's a nice combination of what was there before and GitHub actions.

However, there's one possible drawback: the whole pipeline determines GIT_VERSION once for amd64 and assumes it's the same for all other architectures. I'm no alpine expert, but by looking at some versions in the package manager, this assumption seems to be valid.

Happy to hear what you think about this.

[barthy1]

hey @heussd thank you for this hard work! I still have some input. 1) Github actions stopped running .hcl workflows - https://github.blog/changelog/2019-10-01-github-actions-hcl-workflows-are-no-longer-being-run Does it make sense to use it here even as input? 2) The workflow still runs for each PR 3) What you try to do with "Create Release" step? There are no releases in this project 4) crazy-max/ghaction-docker-buildx@v1 action is archived and not recommended to use

In general I have a feeling that code became not clear (to me at least) and questionable, so I have doubts about it

[barthy1]

@ozbillwang sorry for bothering you. However I need you opinion about usage of Github actions in the project before too much time is spent on it :)
Do you feel that changing the way to build Docker image from Travis to Github actions is acceptable for you?

[ozbillwang]

@barthy1

Over engineering, from my view, especailly the HCL file. HCL developed by Hashicorp, but mostly used for terraform deployment.

This PR looks a total new way do the job, we both are not familar with, would be hard to support it in the future.

Maybe the owner can keep it in his own.

Secondly, my other docker build repositories use the Travis CI as well, it can keep the consistent to others.

[heussd]

@barthy1 no hard work from my side, rather fun work 😄

1. The hcl file is build-in in Docker and has, to my understanding, nothing to do with GitHub HCL Workflows.
2. You are right, fixed that.
3. The "Create Release" step pushes a new git tag. It's how I understand build.sh#L44-L50.
4. Good catch! Thanks a million, I upgraded to the official image 😄

@ozbillwang I don't see why you think this is over-engineering:

• It is using build-in Docker features instead of doing it manually.
• With less lines of code, you get support for more platforms
• It has a clear control flow in one single file instead of splitting it between .travis.yml, build.sh and multi-arch-image.sh

I however see that you do not want integrate something you are not used to. I'm completely fine with you not accepting this MR. My motivation was to a have a ARM version of alpine/git - I'll use my own now.

Cheers! 🍻

[ozbillwang]

@heussd

I understood what you do. But I never and have no any interesting to run applications in multi-arch linux, I am out of these things.

Anything updated in, we need support it future, but that's not what i want to do currently.

If you can make it work in Travis CI with your way, I am happy to accept it. Since I need manage other similar docker build projects as well.

We can put the idea aside, you can keep working with your way.

[ozbillwang]

closed by #32