fedora_latest for other arches

[LecrisUT]

I was trying to use fedora_latest with s390x, but it failed due to missing dockerfile. This is unfortunate because that is where the main need for s390x runners is.

[martin-g]

See base_image documentation in the README
With this setting you could use any custom image.

[LecrisUT]

Still having difficulties. I've tried it with:

      - uses: uraimo/run-on-arch-action@v2
        with:
          arch: s390x
          base_image: "s390x/fedora:latest"

(with and without the arch part, but it still fails).

https://github.com/maciejhirsz/logos/actions/runs/11251365677/job/31282242110?pr=428

  #0 building with "default" instance using docker driver
  
  #1 [internal] load build definition from Dockerfile.s390x.ubuntu18.04
  #1 transferring dockerfile: 214B done
  #1 DONE 0.0s
  
  #2 [internal] load metadata for docker.io/s390x/fedora:latest
  #2 ...
  
  #3 [auth] s390x/fedora:pull token for registry-1.docker.io
  #3 DONE 0.0s
  
  #2 [internal] load metadata for docker.io/s390x/fedora:latest
  #2 ERROR: no match for platform in manifest: not found
  ------
   > [internal] load metadata for docker.io/s390x/fedora:latest:
  ------
  Dockerfile.s390x.ubuntu18.04:1
  --------------------
     1 | >>> FROM s390x/fedora:latest
     2 |     COPY ./run-on-arch-install.sh /root/run-on-arch-install.sh
     3 |     RUN chmod +x /root/run-on-arch-install.sh && /root/run-on-arch-install.sh
  --------------------
  ERROR: failed to solve: s390x/fedora:latest: failed to resolve source metadata for docker.io/s390x/fedora:latest: no match for platform in manifest: not found

Locally I am able to coax it though:

$ podman run --arch s390x s390x/fedora:latest uname -a
✔ docker.io/s390x/fedora:latest
Trying to pull docker.io/s390x/fedora:latest...
Getting image source signatures
Copying blob 6f64a863c90f done   | 
Copying config a99ee4777c done   | 
Writing manifest to image destination
Linux a0cbd18cfcc3 6.11.2-300.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Oct  4 16:44:08 UTC 2024 s390x GNU/Linux

Edit: I've realized the documentation was saying to pass none explicitly, but that did not help either.

[martin-g]

but it still fails

Fails how ?
Link to your workflow and logs please !

[LecrisUT]

I've edited the previous message and provided the logs. Basically it says it cannot find docker.io/s390x/fedora:latest, but if I pass --arch s390x to podman it finds it well

[martin-g]

I have the feeling the arch has to be passed to https://github.com/uraimo/run-on-arch-action/blob/master/src/run-on-arch.sh and then used for the docker build calls.
Let's see what @uraimo thinks about it.

The arch should not be none, of course.

[LecrisUT]

Probably, I don't use docker, so I am just guessing on the syntax here. It seems to work, but the uname -a looks like I did something wrong 🤔
https://github.com/maciejhirsz/logos/actions/runs/11251918804/job/31283959843?pr=428

[martin-g]

I've commented on your commit at LecrisUT@7c5be02#commitcomment-147743824

run-on-arch-commands.sh: line 8: tree: command not found means that it works and it failed at
https://github.com/maciejhirsz/logos/pull/428/files#diff-e910a4c610d37e0660f330a13b3636360ba20a12177de703cbf0af5422263a6dR20
You need to install tree because it seems it is not pre-installed on Fedora.

[LecrisUT]

Indeed, the confusing part was the reference of Ubuntu there:

Linux cb4ab9b9cc81 6.8.0-1014-azure #16~22.04.1-Ubuntu SMP Thu Aug 15 21:31:41 UTC 2024 s390x GNU/Linux

[uraimo]

Hi, the more exotic platforms for Fedora have been removed some time ago because they were a constant source of issues.
It should work this way IF the images specifies a platform explicitly:

  - uses: uraimo/run-on-arch-action@v2
        with:
          arch: none
          distro: none
          base_image: "s390x/fedora:latest"

Since you needed to specify manually --platform for this image this is not the case, please also try this workaround with the unmodified action, as someone suggested some time ago:

base_image: '--platform=linux/s390x s390x/fedora:latest'

This is basically how some of the newer images are configured nowadays, it didn't use to be like that, and that's why --platform was never handled explicitly.

I've seen your PR but I'm worried about the implications for other users and "amd64" is currently not a good default since it's unsupported(basically I haven't really checked how the QEMU emulation layer behaves in this case).

So, thanks for taking the time to open it, really, but for now I will not merge it for now. I hope to be able to release a revamped version of this Action with this and other fixes some day but right now, that's not in the cards...

[LecrisUT]

No worries. I've investigated for the original project usecase and I've encountered further issues that I was not able to reproduce when running in podman, so indeed it is much more nuanced than just adding that option.