On 8/27/24 20:10, Jeff Trull via Boost wrote:

Hi folks,

While reviewing the Modular Boost changes for Wave I noticed that our CI is now failing - and we're not alone in this. It looks like the version of glibc in some of the old Ubuntu containers, which are required to compile against old versions of gcc, is incompatible with the Node executable that runs actions/checkout@v2 (and 3 and 4). You might see errors like this:

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

The Github blog discusses the change here <https://github.blog/changelog/2024-03-07-github-actions-all-actions-will-run-on-node20-instead-of-node16-by-default/>

At least one brave pioneer, Andrey Semashev, has made updates to make CI green again in a handful of libraries, but I haven't seen it discussed on the list. Is there a fix other than "rewrite using manual checkout"?

I managed to implement the workaround described in the blog post by adding these lines close to the top of ci.yml:

env: ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true

Though it seems unwise to rely on in the long run.

It's been a long standing problem and was reported here: https://github.com/actions/checkout/issues/1590 In that issue, you can see ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION is not working for some people, and it is expected that it will stop working completely at some point. The only solution I know of is to stop using actions/checkout (or anything actions/* really). As a bonus, this will also relieve you from the deprecation warnings that appear in the CI whenever GitHub decides to switch to a newer Node version. Alternatively, you could try installing an older compiler to a newer Ubuntu that is compatible with actions/checkout, and configure an environment where the Boost build is using that older compiler. But that may be more problematic if the older compiler packages are not available for the newer Ubuntu. And you'd still depend on the actions life cycle.

Am 27.08.24 um 19:10 schrieb Jeff Trull via Boost:

It looks like the version of glibc in some of the old Ubuntu containers, which are required to compile against old versions of gcc, is incompatible with the Node executable that runs actions/checkout@v2 (and 3 and 4). You might see errors like this:

Some more details/context: actions/cache@v3 can be used instead of the v2 as it is (likely) a small improvement although I forgot by now what they did. Both have the same restriction in that they don't run in Node 20. actions/cache@v4 should be used where possible, i.e. where Node 20 is available. The GLIBC issue appears when using the `container` feature in the Github Actions yaml with Ubuntu 16.04 & 18.04. Newer Ubuntu versions are available as runner images directly, i.e. `os: ubuntu-20.04`. Those should be preferred if the required compiler packages are available. Going forward I hope we can drop the container jobs someday as the compilers tested (only) there become ancient. (GCC 7 is in Ubuntu 20, GCC 14 is the latest release, for Clang it is Clang 8 with Clang 18 being the latest release) I'd also like to suggest to take inspiration of the templates in Boost.CI: https://github.com/boostorg/boost-ci/blob/master/.github/workflows/ci.yml The relevant workaround for the glibc issue is here: https://github.com/boostorg/boost-ci/blob/0e4bc4d58c45a3bad2eba054eafdaaef7b... There I even went a step further and conditionally use actions/checkout@v3 or actions/checkout@v4 to avoid deprecation warnings and IIRC the newer versions have some reliability improvements.

...

Is there a fix other than "rewrite using manual checkout"? [...] env: ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION: true

Though it seems unwise to rely on in the long run. The only solution I know of is to stop using actions/checkout (or anything actions/* really). I do prefer the declarative approach of using the actions instead of manual commands. Especially not having to specify some parameters like the repository or fetch-depth is convenient. So `- uses: actions/checkout@v4` was a nice and clean way to do the cloning without any "noise". Of course this has changed due to this breakage and a manual clone step might be easier, especially if they completely drop the support for the workaround before we drop support of the old compilers. However the `actions/cache` action for use with ccache to speed up CI runs is highly useful to me and could not be easily replaced. I also found other actions, such as `codecov/codecov-action@v4` to be more reliable than the manual approach as they seemingly include logic to gracefully handle temporary issues such as network timeouts. IIRC the checkout action has something like that too.

In the end it's a trade-off like everything else and needs a decision by the respective maintainers. Happy CI testing!