self-hosted: support Alpine
Alpine Linux isn't mentioned in the list of supported distributions. Is there any plan to add support soon?
Bump! :D
Bumpedybump - Would PR for alpine support be welcomed? :D
This would be almost essential for getting proper docker-in-docker support (via this image: https://hub.docker.com/_/docker/ )
there's an old POC PR which has rotted on the vine a bit which has the start of what alpine would look like https://github.com/actions/runner/pull/495
Bump
+1 I'd love to see alpine support as well. Went down a rabbit hole trying to make it work myself and couldn't get it working.
Bump
+1. A quick test worked. Is there a specific barrier to official support? Is it just a matter of testing?
@hross since he's driving this area now. I imagine it's not hard technically but more of a matter of official support, building / dist, docs etc. etc. but I'm guessing here :)
so far after installing .NET Core 6.0.100 using https://dot.net/v1/dotnet-install.sh and directly executing the Runner from the archive https://github.com/actions/runner/releases/download/v2.284.0/actions-runner-linux-x64-2.284.0.tar.gz
./bin/Runner.Listener configure
I end up with
bash-5.1$ ldd bin/Runner.Listener
/lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000)
libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000)
libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f7dfa728000)
libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f7dfa70e000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by bin/Runner.Listener)
bash-5.1$ ls -l /lib64/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root 26 Nov 12 22:00 /lib64/ld-linux-x86-64.so.2 -> /lib/libc.musl-x86_64.so.1
Seems like musl-friendly build of .NET Core should be sufficient for executing Runner.Listener, but it's not.
Did I miss anything?
so far after installing .NET Core 6.0.100 using https://dot.net/v1/dotnet-install.sh and directly executing the Runner from the archive https://github.com/actions/runner/releases/download/v2.284.0/actions-runner-linux-x64-2.284.0.tar.gz
./bin/Runner.Listener configureI end up with
bash-5.1$ ldd bin/Runner.Listener /lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000) libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000) libdl.so.2 => /lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x7f7dfa728000) libm.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x7f7dfa70e000) libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f7dfa8c9000) Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by bin/Runner.Listener) bash-5.1$ ls -l /lib64/ld-linux-x86-64.so.2 lrwxrwxrwx 1 root root 26 Nov 12 22:00 /lib64/ld-linux-x86-64.so.2 -> /lib/libc.musl-x86_64.so.1Seems like musl-friendly build of .NET Core should be sufficient for executing Runner.Listener, but it's not.
Did I miss anything?
You might want to open a new issue for your problem. I don't think thats related to a alpine version of the runner image.
any luck?
Has anyone been able to get this working on alpine and can please share the steps on how they achieved it?
@maciejgwizdala Did you get this working here https://github.com/maciejgwizdala/alpine-runner ? Was there anything else necessary?
Also got this error JavaScript Actions in Alpine containers are only supported on x64 Linux runners. Detected Linux Arm64 when using container: in workflow.
The runner team should consider changing how it does Alpine detection because the glibc node runtime they use works fine if gcompat is installed in the container. So, for those who run into this issue you need to run the following as the first step before any JS actions and then everything will work fine:
- run: |
apk add gcompat
sed -i "s:ID=alpine:ID=NotpineForGHA:" /etc/os-release
If you're only using the container for GHA then you could simply build it into your Dockerfile as well, but be wary of other software that may depend on alpine fingerprinting via /etc/os-release rather than musl libc detection.
Also looking for better alpine support.
As a potential user of GHA; (coming from gitlab) -> I would prefer to specify a base image (alpine or whatever I need) as part of the job and let the runner use that via docker. (also using arm64 builds)
It seems like a work around might exist in GHA; but looking at LoE right now vs staying where I am.
Bumpedybump
Bump
Bump
Working from the information posted by alex and reaper:
apk add gcompat aspnetcore6-runtime
./bin/Runner.Listener configure
./run.sh
I also required the following for my pipelines to do any valuable work:
apk add iptables ip6tables docker docker-compose go g++
usermod -aG docker yourusername
rc-update add docker boot
reboot
FWIW, with actions/checkout@v4 the workaround @reaperhulk discovered no longer works. This is because 4.0.0 uses node20, which fails to run with:
Error relocating /__e/node20/bin/node: fcntl64: symbol not found
Presumably as time marches forward and node20 becomes more common, this error will become more omnipresent.
We also get the error "JavaScript Actions in Alpine containers are only supported on x64 Linux runners. ..." running actions/checkout versions @v2, @v3 and @v4 on arm64. So this message is to support the feature request to support such uses.
Combining all the knowledge of this issue and adding some more hacky workarounds, I was able to build some alpine runner images which "work" as of now. You can find the source at https://github.com/cynkra/runner/tree/main/images and the images at https://hub.docker.com/repository/docker/cynkra/actions-runner.
No warranty for updates and no idea how "stable" they are. We've used them in one private workflow so far and everything worked but there might surely be edge cases.
NOTE: Many Actions from the Marketplace don't support Alpine as the underlying OS so you're pretty much on your own with installing dependencies etc.
(we might also add ubuntu-based variants into the same repo which is why we went for a tagging scheme which includes the OS name)
Bumpedybump
Bumpedybump bump
We need alpine for docker in dockerrr
waiting for alpine @Github
waiting for alpine https://github.com/github