[bug] v2, v3 and v4 fail in 32-bit containers

dscho commented 2 weeks ago

What happened?

Thanks to the helpful brown-out to notify everybody about the deprecated v1, I once again tried to run actions/upload-artifact@v4 in an i686 Docker container, and it fails miserably:

exec /__e/node20/bin/node: no such file or directory

What did you expect to happen?

I expected to either be allowed to use the deprecated v1 (which works!), or for v4 to work (which does not).

How can we reproduce it?

name: CI

on: [push, pull_request]

jobs:
  demo:
    name: demonstrate need for "deprecated" actions/upload-artifact in i386 containers
    runs-on: ubuntu-latest
    container: i386/ubuntu:focal
    steps:
    - name: Upload fails
      # shows 'exec /__e/node20/bin/node: no such file or directory'
      uses: actions/upload-artifact@v4
      with:
        name: some-artifact
        path: .

Anything else we need to know?

This has been noted in git/git, which is a quite high-profile project.

What version of the action are you using?

v4

What are your runner environments?

linux

Are you on GitHub Enterprise Server? If so, what version?

no

dscho commented 2 weeks ago

For the record: The Git project currently uses git/git@90f2c7240ccc7fb349199b4ded6b47702b40331f, which removes the upload altogether. This is not ideal, of course, as investigating test failures is made much harder by that, requiring any person investigating the test failures to recreate the same environment as in the workflow job, locally, and then hoping that the problem reproduces there.

dscho commented 2 weeks ago

I've got more information now:

I found out that there is no official linux-x86 build of node20
There are unofficial linux-x86 builds of node20 at https://unofficial-builds.nodejs.org/download/release/. This is a subdomain of the official nodejs.org domain, therefore they are maybe officially unofficial? Or maybe officially unofficial but almost official, unofficially?

It is quite tricky, but it is possible to convince a container on a hosted runner to use that unofficial build. See here for an example. The trick is to map /__e/node20 via the jobs.<job_id>.container.volumes directive, and to use curl and tar to fetch and extract the linux-x86 node. Here is the full workflow definition that worked:

name: CI

on: [push, pull_request]

jobs:
demo:
  name: demonstrate need for "deprecated" actions/upload-artifact in i386 containers
  runs-on: ubuntu-latest
  container:
    image: i386/ubuntu:focal
    volumes:
    - ${{ github.workspace }}:/__e/node20
  steps:
  - name: Try to replace `node` with an i386 version
    shell: bash
    run: |
      ls -lar /__e/node20 &&
      apt-get update &&
      apt-get install -y curl &&
      curl -Lo /tmp/node.tar.gz https://unofficial-builds.nodejs.org/download/release/v20.17.0/node-v20.17.0-linux-x86.tar.gz &&
      cd /__e/node20 &&
      tar -x --strip-components=1 -f /tmp/node.tar.gz
  - name: Upload fails
    # shows 'exec /__e/node20/bin/node: no such file or directory'
    uses: actions/upload-artifact@v4
    with:
      name: some-artifact
      path: .

It would probably have been a better idea to map runner.temp to /__e/node20 than github.workspace, but hey, this was just a demonstration that I hope leads to a path forward.

It should be possible (although I could not wrap my head around the actions/runner code enough during the past few hours) to detect the CPU architecture during the "Initialize containers" phase, probably just after the image was pulled e.g. via docker image inspect (which, according to this tutorial reports that information in the "Architecture" attribute, i.e. docker image inspect --format '{{.Architecture}}' or a variation thereof should do the trick).
When x86 is detected, the node20 folder in WellknownDirectoryExternals should be replaced by a x86 variant of node 20.
While it is somewhat concerning that the node.js project themselves do not build Linux x86 versions, I gather that a one-off build could be made by the Actions team, or one of the "unofficial-builds" could get blessed, and then used in this scenario.

actions / upload-artifact