fedora_latest for other arches
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.
See base_image documentation in the README
With this setting you could use any custom image.
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.
but it still fails
Fails how ? Link to your workflow and logs please !
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
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.
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 :thinking:
https://github.com/maciejhirsz/logos/actions/runs/11251918804/job/31283959843?pr=428
I've commented on your commit at https://github.com/LecrisUT/run-on-arch-action/commit/7c5be02676c92296593f5138777b861fd035413c#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.
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
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...
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.
I'm closing this, the issue of most images now requiring an explicit architecture declaration to be started correctly has been addressed with 96c27aa6978f736220aea94414920135028189be, and when needed the platform can be explicitly specified with base_image as shown here