Hi, can you post your workflow file?

hey, sure , here: https://github.com/SixSq/img-authz-plugin/blob/master/.github/workflows/main.yml

The problem seems to be around here, inside that Makefile you build with "make all". It's creating another x86_64 alpine container inside the emulated armv7 one.

Step 6/12 : RUN git clone https://github.com/theupdateframework/notary.git &&     cd notary &&     go get github.com/theupdateframework/notary &&     go install -tags pkcs11 github.com/theupdateframework/notary/cmd/notary
 ---> Running in 2fbe61e877ca
Cloning into 'notary'...
go: downloading github.com/docker/distribution v2.7.1+incompatible
go: downloading github.com/spf13/viper v0.0.0-20150530192845-be5ff3e4840c
go: downloading golang.org/x/crypto v0.0.0-20200302210943-78000ba7a073
...
Removing intermediate container 2fbe61e877ca
 ---> a0978c5712f5
Step 7/12 : FROM alpine
latest: Pulling from library/alpine
df20fa9351a1: Pulling fs layer 
....
df20fa9351a1: Pull complete 
Digest: sha256:185518070891758909c9f839cf4ca393ee977ac378609f700f60a771a2dfe321
Status: Downloaded newer image for alpine:latest
 ---> a24bb4013296
Step 8/12 : RUN apk update && apk add --no-cache libc6-compat
 ---> Running in 842e0f94d8b4
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
v3.12.0-320-g7ac7f0b0a6 [http://dl-cdn.alpinelinux.org/alpine/v3.12/main]
v3.12.0-324-g4b4c2fd71c [http://dl-cdn.alpinelinux.org/alpine/v3.12/community]
OK: 12748 distinct packages available
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/community/x86_64/APKINDEX.tar.gz
(1/2) Upgrading musl (1.1.24-r8 -> 1.1.24-r9)
(2/2) Installing libc6-compat (1.1.24-r9)
OK: 6 MiB in 15 packages
Removing intermediate container 842e0f94d8b4
 ---> 8fac80a839e0
Step 9/12 : COPY --from=plugin-builder /usr/libexec/img-authz-plugin /usr/libexec/img-authz-plugin

I'd recommend to add a new target in the makefile that just builds without imposing the creation of an x86 container on the caller, that way you'll be able to build it anywhere you want. As it is, it's impossible to build it anywhere else.

yep that's true. But that shouldn't be a problem cause since I'm using Docker in Docker, your CI container becomes the host for this build, and its architecture is in fact armv7l.

The problem here (I believe) is that containerd doesn't seem to play well with qemu and gets lost when inferring the underlying architecture, thus defaulting to x86 (at least that's my theory) -> containerd/containerd#4109

I'd recommend to add a new target in the makefile that just builds without imposing the creation of an x86 container on the caller, that way you'll be able to build it anywhere you want. As it is, it's impossible to build it anywhere else.

hum not really no. The current Makefile uses Docker for most stages, and Docker infers the underlying arch by itself, thus this Makefile is in fact working for both amd64 and aarch64 on travis -> https://github.com/SixSq/img-authz-plugin/blob/master/.travis.yml#L19

Might depend on how the host CPU is determined within the Makefile. Within docker containers the uname -a command's output is "incorrect", and perhaps some other system calls would also report the kernel/architecture incorrectly. This is not something specific to this GitHub Action, but is a quirk of docker in general. For instance my laptop is an arm64 device running Manjaro, and I have an arm64 docker container running Debian. The output of uname -a within that docker shows the Manjaro kernel.

See https://stackoverflow.com/questions/31012297/uname-a-returning-the-same-in-docker-host-or-any-docker-container for info about this.

I don't have a solution handy, but I'm sure there's a way to determine the emulated CPU from within the container. Might require some adjustments to the Makefile.

The reason it probably works on Travis, is I believe that Travis runs aarch64 natively.