Support for Github ARM Runners

[DarkAtra]

We experienced quite some issues when github updated their runners to ship with docker version 29.1.5 (previously was 27/28), so we decided to ensure we have control over which docker version is installed in our workflows. Thus we found this action and at the start everthing was looking great... for AMD64 runners at least.

Once we tried building multi-arch images for one of our projects, we observed very strange errors:

• like Image with name "..." not found (example) even though the image was just pulled a few seconds earlier

We tried a bunch of workarounds that were discussed here but none seemed to fix our issue - all attempts are also visible here.

Our last idea was to install docker differently... via apt instead of using docker/setup-docker-action. And to our supprise that solved all our issues (this run).

That made us curious: is this action supposed to be working on githubs official arm based runners? (e.g. ubuntu-24.04-arm) and if not, do you plan to add support for arm runners in the near future?

[thaJeztah]

Unfortunately, github uses an older v29 minor release (29.1.5, no longer maintained), and from the workflow where things worked (where you manually updated docker), I see it's running a newer version, so it's possible that bug fixes in the newer version fixed your issue; this was from the successful run;

Client: Docker Engine - Community
 Version:    29.2.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.31.1
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v5.0.2
    Path:     /usr/libexec/docker/cli-plugins/docker-compose
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.1.0
    Path:     /usr/libexec/docker/cli-plugins/docker-model

Server:
 Containers: 0
  Running: 0
  Paused: 0
  Stopped: 0
 Images: 1
 Server Version: 29.2.1
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: false
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: dea7da592f5d1d2b7755e3a161be07f43fad8f75
 runc version: v1.3.4-0-gd6d73eb8
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.14.0-1017-azure
 Operating System: Ubuntu 24.04.3 LTS
 OSType: linux
 Architecture: aarch64
 CPUs: 4
 Total Memory: 15.58GiB
 Name: runnervm95407
 ID: f9cb7d20-711d-4eb2-a4b7-c4900d5010b9
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: githubactions
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

[thaJeztah]

Actually, not sure; I see the failed workflow also had the same version?

Client:
 Version:    29.2.1
 Context:    default

[DarkAtra]

The docker versions for both the failed and successful runs are the exact same from what i can tell. The only difference is the way docker was setup. The failed run uses the setup-docker-action and the successful run installs docker via apt. We also tried some recommendations (metnioned here), for example disabling containerd-snapshotter, but that didn't help either.

Right now it seems to me as if the setup-docker-action does something slightly different for ARM runners which then leads to the issues we observed - i have no clue what exactly though.