Enable multi-arch builds in GHA for the main branch #161
Conversation
|
@rooftopcellist, great minds think alike (#162) and if it wasn't for @kurokobo, I would not have noticed your work. I'll post what I've done so far as it might give some ideas. |
by using docker buildx build, multi arch builds can be achieved. see makefile `PLATFORMS` var for default architectures that are build. PR ansible#161
rooftopcellist
force-pushed
the
enable-cross-platform-build
branch
from
ca9543b
to
78a9040
Compare
- These images can later be re-tagged and used by the Release GHA Author: jon-nfc Signed-off-by: Christian M. Adams <chadams@redhat.com>
|
This worked as expected when I tested it on my fork: |
| run: | | ||
| IMG=eda-server-operator:main make docker-build | ||
| - name: Log into registry ghcr.io | ||
| uses: docker/login-action@343f7c4344506bcbf9b4de18042ae17996df046d # v3.0.0 |
There was a problem hiding this comment.
Just out of curiosity, why use the commit with a comment with the tag instead of just the tag?
There was a problem hiding this comment.
@Alex-Izquierdo that change was made by @jon-nfc , but my guess is that it was to pin to a particular known working version of the docker login action in case a new release breaks it. However, I do not know of a specific issue why this might have been done.
The commit is correct for v3.0.0:
There was a problem hiding this comment.
@rooftopcellist is correct it originated from myself. Code was copied directly from github action template. However the reason for keeping it this way is very simple, Security.
A word none of us like, but must deal with. Security in this case is the prevention (reduction in probability) of supply chain attack or more correctly put limiting attack surface.
A git hash in the context of a repository will always remain the same and always be in the same location in the git history. You can not change a git hash. Even if you submit the same code in the same location in the git history, the git hash will always be different.
A Git tag is tied to a git hash. The problem with a git tag for chain of custody is that the git tag can move hashes. You can delete an existing tag and attach it to another commit hash. This is problem when using it to reference a dependency.
A hash to reference the same work as a git tag is preferable. one would hope that the developer whom used the code had reviewed the dependent repo. This I suppose you could call now a dependency in a known and "approved" state. If the hash changes, which would make it not exist, then an error will occur.
Whilst it's not impossible for a hash collision to occur, the probability of it occurring is in the order of 2^40 which is significantly larger than the tag change which anyone with access to commit can do.
There was a problem hiding this comment.
addendum.
the commented tag version exists next to the hash as we are humans, and readability is important.
|
@Alex-Izquierdo I'm not sure I understood this bit.
Currently, it will create an image with the git commit sha as the tag and push it to ghcr.io to be re-tagged for release, or for debugging purposes. It will also push to quay.io with the |
We should build multi-arch images for the eda-server-operator, starting with the the images built for the
mainbranch.Example of a successful run on my fork: