iamthefij/multiarch-pipeline-test
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge branch 'test-branch'
All checks were successful
continuous-integration/drone/push Build is passing
Details

Browse Source
This commit is contained in:
IamTheFij 2019-06-04 22:34:21 -07:00
commit 978fb1991f
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Readme.md
View File

@ -18,7 +18,7 @@ This is the root of the "magic". This file includes inline documentation as well
Many library images now [support multiple architechtures](https://github.com/docker-library/official-images#architectures-other-than-amd64) and do so by providing them under a different prefix repo. Many library images now [support multiple architechtures](https://github.com/docker-library/official-images#architectures-other-than-amd64) and do so by providing them under a different prefix repo.
However, some images use a tag suffix format. In fact, that will be the output of this pipeline. Something like `user/image:linux-amd64` and `user/image:linux-arm`, etc. It's still possible to build based on those images. To do so, instead of a `REPO` arg, you can rename it to `TAG_SUFFIX` and update the `FROM` statement in the `Dockerfile` to something like `FROM user/image:v1.0.0${TAG_SUFFIX}`. However, some images use a tag suffix format. In fact, that will be the output of this pipeline. Something like `user/image:linux-amd64` and `user/image:linux-arm`, etc. It's still possible to build based on those images. To do so, instead of a `REPO` arg, you can rename it to `TAG_SUFFIX` and update the `FROM` statement in the `Dockerfile` to something like `FROM user/image:1.0.0-${TAG_SUFFIX}`.
If you do rename the build arg, you must also rename the arg in the `Makefile` and `.drone.yml`. If you do rename the build arg, you must also rename the arg in the `Makefile` and `.drone.yml`.
@ -30,4 +30,4 @@ This is done by using distinct pipelines for each of these processes. First is t
After that, there are three distinct pipelines that can be run in parallel. One for each arch we would like to support. They are `linux-amd64`, `linux-arm`, and `linux-arm64`. These have two build steps. First to download the proper `qemu` binary, and second to build and push the image to Docker Hub. We take advantage of the autotagging feature of the Drone plugin to get convenient Docker image tags to match our git tags. After that, there are three distinct pipelines that can be run in parallel. One for each arch we would like to support. They are `linux-amd64`, `linux-arm`, and `linux-arm64`. These have two build steps. First to download the proper `qemu` binary, and second to build and push the image to Docker Hub. We take advantage of the autotagging feature of the Drone plugin to get convenient Docker image tags to match our git tags.
Once all three complete successfully, a final pipeline generates a Docker manifest and pushes it to Docker Hub. This allows Docker will map a client architechture to a particular Docker image. After this is pushed you should be able to `docker run user/image` on any of our supported architechtures and Docker will pull the correct image. Once all three complete successfully, a final pipeline generates a Docker manifest and pushes it to Docker Hub. This allows Docker will map a client architechture to a particular Docker image. After this is pushed you should be able to `docker run user/image` on any of our supported architechtures and Docker will pull the correct image.