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 #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 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?

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

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.

Bumpedybump

Bumpedybump bump

We need alpine for docker in dockerrr

waiting for alpine @github

waiting for alpine https://github.com/github

waiting for alpine https://github.com/github

I just stumbled across the same problem. Now I have to workaround my build with running docker container manually and extract the build-artifacts :-(

Bump! Error: JavaScript Actions in Alpine containers are only supported on x64 Linux runners. Detected Linux Arm64

I'm doing something slightly different than y'all AFAICT. I'm not running the self-hosted runner in Alpine, but I'm running an Alpine container within the runner (self-hosted or otherwise). I hope the solution for my situation helps in yours, too.

Based on the workarounds of @reaperhulk in #801 (comment) and @nekinie in #801 (comment), I did a little more digging and found a way to make NodeJS work with GitHub Actions inside Alpine.

Things like actions/checkout are invoked with a hard-coded path to NodeJS inside the container, something like /__e/node20/bin/node. But we don't need this pre-compiled NodeJS. There's already a perfectly good one available inside the container. The only problem is that /__e is a read-only volume attached to the container. But we have access to the docker socket, so...

Here's the extra step I'm adding to the top of my workflow to resolve this:

     - name: Patch native Alpine NodeJS into Runner environment
        run: |
          apk add docker nodejs
          sed -i "s:ID=alpine:ID=NotpineForGHA:" /etc/os-release
          docker run --rm -v /:/host alpine sh -c 'cd /host/home/runner/runners/*/externals/ && rm -rf node20/* && mkdir node20/bin && ln -s /usr/bin/node node20/bin/node'
        shell: sh  # No bash in Alpine by default

This will:

• Install docker and nodejs in the container
• Modify /etc/os-release to avoid tripping the Runner's lock-out mechanism
• Run a sibling Docker container with access to the host FS, which then clobbers the source of that internally-read-only /__e path (/home/runner/runners/*/externals/)
• Allow the rest of your workflow steps to run as they normally would, but from inside an Alpine container

With this, I get actions/checkout executed with the Alpine-native NodeJS, without need for gcompat or anything else.

I hope this helps!

And here's a simpler version without the need for another container, now that I realize there's volume support directly in the Actions Workflow:

    runs-on: ubuntu-latest
    container:
      image: alpine
      volumes:
        - /:/host  # Jailbreak!

    steps:
      - name: Patch native Alpine NodeJS into Runner environment
        if: runner.os == 'Linux'
        run: |
          apk add nodejs
          sed -i "s:ID=alpine:ID=NotpineForGHA:" /etc/os-release
          cd /host/home/runner/runners/*/externals/
          rm -rf node20/*
          mkdir node20/bin
          ln -s /usr/bin/node node20/bin/node
        shell: sh  # No bash in Alpine by default

Bump

With the introduction of the ARM64 runners to the general public (https://github.com/orgs/community/discussions/148648), I ran into this issue as well: the host is the new ubuntu-24.04-arm runner and a Alpine container is/was used for running tests in a musl environment. Using the hack mentioned in #801 (comment) might work, but is likely to break if e.g. the expected Node path changes.

Having proper support would be greatly appreciated 😃

The hack still works with ubuntu-24.04-arm (for now).

You can just not use container: and you'll never have this issue.

https://github.com/userdocs/test/actions/runs/12828579208/workflow