/__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version GLIBC_2.28' not found (required by /__e/node20/bin/node)`

[nicowilliams]

Using container: image: debian:bullseye to build the OpenJDK for an older release of a distro (Debian in this case, but this isn't specific to Debian) causes a failure due to node in the actions/checkout@v4 docker image to fail to run due to the container having an older glibc:

/usr/bin/docker exec  ebe297a6b5716c387c7333d466eb082069a2f0b0c97379a95e810de4f4fa67a5 sh -c "cat /etc/*release | grep ^ID"
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node)

(Using build tools that depend on newer glibc versions seems likely to be a common pitfall for GitHub Actions.)

[briandfoy]

I also have this problem on Ubuntu 22.04 (see https://github.com/briandfoy/data-constraint/actions/runs/7645971689/job/20833756885 while it is around).

Run actions/checkout@v4
  with:
    repository: briandfoy/data-constraint
    token: ***
    ssh-strict: true
    persist-credentials: true
    clean: true
    sparse-checkout-cone-mode: true
    fetch-depth: 1
    fetch-tags: false
    show-progress: true
    lfs: false
    submodules: false
    set-safe-directory: true
/usr/bin/docker exec  55707bba4641f79c81786bd2c50d454ad4ce5589862509caadcaf0d83af05524 sh -c "cat /etc/*release | grep ^ID"
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `CXXABI_1.3.9' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /__e/node20/bin/node)

[falkTX]

I have the same issue when trying to use ubuntu:18.04 image
https://github.com/moddevices/mod-desktop-app/actions/runs/7697857575/job/20975801114

[falkTX]

Similarly the actions/cache@v4 also fails
https://github.com/moddevices/mod-desktop-app/actions/runs/7698414056/job/20977633093

[Lastique]

I have the same problem with checkout@v4 with running CI on ubuntu:16.04 and ubuntu:18.04 docker images:

/usr/bin/docker exec  96e66dce4d560bc83ea53e3885a0f7a370efc33ab78c57efc31e036d6ef7b0c3 sh -c "cat /etc/*release | grep ^ID"
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node)

https://github.com/Lastique/scope/actions/runs/7754629439/job/21148329132

/usr/bin/docker exec  25c6cfe8c9e7550b5d65e58ee1567ae81f08d6b5b6b6868be7c4026ac201e195 sh -c "cat /etc/*release | grep ^ID"
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /__e/node20/bin/node)
/__e/node20/bin/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by /__e/node20/bin/node)

https://github.com/Lastique/scope/actions/runs/7754629439/job/21148329685

These older Ubuntu images are needed to be able to test older compiler versions.

Until this issue is resolved, please remove the deprecation notice for checkout@v3, as there simply is no alternative.

[falkTX]

Until this issue is resolved, please remove the deprecation notice for checkout@v3, as there simply is no alternative.

note that it is not just the checkout being broken, anything that uses node is broken which includes cache and artifacts.
even the node-setup action (which could potentially be a workaround) is broken.

basically all the v4 actions from github are broken for older distros due to glibc requirements

[nicowilliams]

basically all the v4 actions from github are broken for older distros due to glibc requirements

Yes. I've noticed. Obviously this was the first one I diagnosed, so it got the issue :)

[Dlazder]

Same problem in ubuntu 18

[evitiello]

Anyone found a workaround for this? Or know why it started happening?

[falkTX]

the workaround is to keep using v3 actions. and it happens because github devs updated the base system where their node stack is built from.

seeing the way github has handled other issues, I expect this one to just be ignored completely.

[alecrajeev]

I ran into this bug for some CI tests and I implemented a workaround.

We basically built (but did not push) a docker image and ran the CI tests inside of the docker build. If the CI tests passed, then the docker build was successful. If the CI tests failed, then the docker build failed.

In this way we got around the node js version limitations for actions/checkout.

[mcarbonneaux]

i use container to test build on old compiler, but when use checkout action i take the error about nodejs.
it's possible to execute checkout outside the container ?

[rduque1]

I used as workaround this step action that allows to run a container in a step: docker-run-action.

You can do the checkout with runs-on: ubuntu-latest and then use the image you want in the steps with the docker-run-action.

[zhouyuan]

We fixed this issue by using the checkout action on Ubuntu 20.04, and modified the tests to use docker run -v /code:/work centos:7 bash -C "xxx".
just for someone also run into this issue.

[barlesh]

We fixed this issue by using the checkout action on Ubuntu 20.04, and modified the tests to use docker run -v /code:/work centos:7 bash -C "xxx". just for someone also run into this issue.

gr8 workaround.
tested it on a sample repo of mine, you can see example
https://github.com/barlesh/workaround-gh-co-and-artifact-on-old-os

[spicy-sauce]

We fixed this issue by using the checkout action on Ubuntu 20.04, and modified the tests to use docker run -v /code:/work centos:7 bash -C "xxx". just for someone also run into this issue.

gr8 workaround. tested it on a sample repo of mine, you can see example https://github.com/barlesh/workaround-gh-co-and-artifact-on-old-os

Thanks, but your example is unavailable, can you check?

[barlesh]

We fixed this issue by using the checkout action on Ubuntu 20.04, and modified the tests to use docker run -v /code:/work centos:7 bash -C "xxx". just for someone also run into this issue.

gr8 workaround. tested it on a sample repo of mine, you can see example https://github.com/barlesh/workaround-gh-co-and-artifact-on-old-os

Thanks, but your example is unavailable, can you check?

sorry, changed visibility to public

[jameslamb]

I got around it by using:

env:
  ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true

in my workflow: https://github.com/mmomtchev/hadron/blob/main/.github/workflows/os_comp.yml#L32-L33

But this too, it will stop working at some point.

It appears to me that we've reached the "some point" where this stops working. In the most recent GitHub Actions runner release, the minimum node version was bumped to Node 20:

• Github Actions Self-Hosted Runner issue with node 20 runner#3373 (comment)
• Remove node16 from the runner. runner#3503

[esabol]

We fixed this issue by using the checkout action on Ubuntu 20.04, and modified the tests to use docker run -v /code:/work centos:7 bash -C "xxx". just for someone also run into this issue.

gr8 workaround. tested it on a sample repo of mine, you can see example https://github.com/barlesh/workaround-gh-co-and-artifact-on-old-os

OK, that works well for a simple script, but what about an actual build with lots of files using gcc/g++? Anyone have a working ci.yml that uses this approach?

[dalboris]

We fixed this issue by using the checkout action on Ubuntu 20.04, and modified the tests to use docker run -v /code:/work centos:7 bash -C "xxx". just for someone also run into this issue.

gr8 workaround. tested it on a sample repo of mine, you can see example https://github.com/barlesh/workaround-gh-co-and-artifact-on-old-os

OK, that works well for a simple script, but what about an actual build with lots of files using gcc/g++? Anyone have a working ci.yml that uses this approach?

Below is the best method that I've found so far, which works reasonably well and does not depend on any third-party action:

name: Ubuntu 18.04 Build
on: [push, pull_request]
env:
  CONTAINER: ubuntu:18.04

jobs:
  build:
    runs-on: ubuntu-latest
    steps:

    - uses: actions/checkout@v4

    # We manually start a container and execute scripts in it instead of using `jobs.build.container`,
    # otherwise we couldn't use GitHub-provided actions (checkout, cache, etc.) as they rely on Node20
    # which would not necessarily be available on some containers (e.g., Ubuntu 18.04).
    #
    # See: https://github.com/actions/checkout/issues/1590
    #
    # If you need to pass environment variables from the GitHub host runner to the Docker container,
    # you can do so by adding `-e MY_VAR` to the docker run command, for example:
    #
    #    docker run --name build-container -d -e GITHUB_REPOSITORY -v ...
    #
    - name: Start Docker Container
      run: |
        docker pull $CONTAINER
        docker run --name build-container -d -v ${{ github.workspace }}:/workspace $CONTAINER tail -f /dev/null

    - name: Install Dependencies
      env:
        SCRIPT: |
          apt-get update
          apt-get install -y cmake build-essential libfreetype6-dev libharfbuzz-dev
      run: docker exec build-container bash -c "$SCRIPT"

    - name: Build
      env:
        SCRIPT: |
          cd /workspace && mkdir build && cd build
          cmake --version
          cmake .. -DCMAKE_BUILD_TYPE=Release
          cmake --build .
      run: docker exec build-container bash -c "$SCRIPT"

Here is a more complex example of how I have successfully ported one of my build to this method:

• Fix Linux build fails due to removal of Node16 in GitHub-hosted runners (#1804) vgc/vgc#1917

I have other examples here:

• https://github.com/dalboris/test-cpp-github-actions/pull/27/files

Good luck everyone!

[esabol]

@dalboris wrote:

Below is the best method that I've found so far, which works reasonably well and does not depend on any third-party action:

Thank you so much! I think I see the path forward now for fixing our CI builds on older systems.