self-hosted: support Alpine

[jcayzac]

Alpine Linux isn't mentioned in the list of supported distributions. Is there any plan to add support soon?

[Korpics]

Bump! :D

[baer95]

Bumpedybump - Would PR for alpine support be welcomed? :D

[villesau]

This would be almost essential for getting proper docker-in-docker support (via this image: https://hub.docker.com/_/docker/ )

[bryanmacfarlane]

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

[bihiguti]

Bump

[mathew-fleisch]

+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.

[unrooty-infinum]

Bump

[rvollmarsb]

+1. A quick test worked. Is there a specific barrier to official support? Is it just a matter of testing?

[bryanmacfarlane]

@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 :)

[alex-schwartzman-at-stratify]

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?

[axe312ger]

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.

[debragail]

any luck?

[kabal2010]

Has anyone been able to get this working on alpine and can please share the steps on how they achieved it?

[StevenACoffman]

@maciejgwizdala Did you get this working here https://github.com/maciejgwizdala/alpine-runner ? Was there anything else necessary?

[chunlea]

Also got this error JavaScript Actions in Alpine containers are only supported on x64 Linux runners. Detected Linux Arm64 when using container: in workflow.

[reaperhulk]

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.

[randysecrist]

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.

[mattmutual]

Bumpedybump

[ml4]

Bump

[cheempz]

Bump

[nekinie]

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

[alex]

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.

[maartenarnst]

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.

[pat-s]

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)

[toots]

Bumpedybump

Bumpedybump bump

[atakanhr]

We need alpine for docker in dockerrr

[azataiot]

waiting for alpine @Github

[snowdream]

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

[iotanum]

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

[project0]

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

[karinswanson-sh]

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

[joeyparrish]

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 https://github.com/actions/runner/issues/801#issuecomment-1374967227 and @nekinie in https://github.com/actions/runner/issues/801#issuecomment-1662148601, 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!

[joeyparrish]

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

[StamenchoBog]

Bump

[Sir-NoChill]

Bump