s390x: build native runner binaries in a stage #67
Conversation
|
Unfortunately, this has to be parked for now... I tested the build on a local box, and on a s390x host. I then modified However, the s390x-native build of actions runner binaries via docker-build-push action (which uses qemu emulation) on github-hosted runners fails with a segfault in .NET This may or may not be related to the issue in emulation with .NET 8. So, for now I am going to use the same approach I did for v2.321.0 upgrade: make a "release" tag in my fork and upload s390x binaries that I know are working. Then, updated runner image to use those binaries. On the next actions runner release, I'll test this PR again. cc: @chantra |
|
Oh, btw I briefly tried cross-compiling s390x binaries on x64, but didn't get too far. I looked into that on the off chance it's easy (.NET is supposed to be cross-platform!!!), but it wasn't. No point in spending lots of time on that. |
Remove now unused s390x.Dockerfile, then rename s390x-native.Dockerfile to s390x.Dockerfile Signed-off-by: Ihor Solodrai <[email protected]>
Since v2.321.0 of Github Actions runner we have switched to native s390x binaries, built externally [1]. The external build was executed locally using scripts from the gaplib [2], the binaries then were published [3], so that they could be downloaded during s390x image build. However there is no technical reason to externalize s390x build process. It was done this way mostly due to the fact that officially released pre-built binaries are downloaded, and not built. This change updates s390x Dockerfile adding a stage for building s390x actions runner binaries, which are immediately used in the runner docker image for BPF CI. This will simplify s390x native runner maintenance, and will help to automate uneventful version bumps. The current actions runner version is v2.322.0 [1] kernel-patches#64 [2] https://github.com/anup-kodlekere/gaplib [3] https://github.com/theihor/s390x-actions-runner/releases/tag/v2.321.0 Signed-off-by: Ihor Solodrai <[email protected]>
Rename docker build ARG according to the recent changes, and change wording in PR/commit message. Signed-off-by: Ihor Solodrai <[email protected]>
|
cc: @chantra @anakryiko Here is a TL;DR picture describing the situation: This week I wanted to update s390x runners to the new version (v2.322.0), and while at it I modified our dockerfiles such that simple bumps are mostly automated. This is what this PR is about. But that ended up segfaulting on .NET build, as I described in a previous comment. "Bummer!", I thought. And proceeded to updating runners semi-manually. But I got blocked, because it turned out that our docker build workflows have been failing with obscure errors for a while now. Well, that had to be fixed. It took a while, but in the end I found a fix (#69, nice) thanks to the good people on the internet. The fix came down to forcing upstream actions to use more recent QEMU. And that gave me a pause: maybe the reason for .NET segfault was also QEMU? Of course it was! Which is why the pipeline is green on this PR now. And then I remembered that last week libbpf/libbpf builds on non-x64 archs started segfaulting when compiling with cc. Andrii's take was "let's wait, it might go away", and he's probably right, although the timeline is unclear. But first I wanted to confirm that the run-on-arch action uses similar dependencies as docker build-push. Turned out it's a bit worse. The Anyways, important point here is that if you're using docker to run things on different architectures, you have to remember that it's not magic. It's QEMU. And so what actually happens is that For libbpf I first tried to force run-on-arch to use newer qemu. That didn't work, so I decided to give it a try and run docker in the workflow directly (it is set up on github-hosted runners after all). And that resolved the weird segfault. Phew! |
|
I wonder if this could eventually be stable enough to make it into myoung34/docker-github-actions-runner#248 ? |
I'll look into it. |
See commit messages for details.