exec /__e/node20/bin/node: no such file or directory
twmht opened this issue · comments
on:
pull_request:
types: [opened, synchronize]
name: Tag Created
jobs:
tag-created:
runs-on: rtx4090-1
container:
image: nvcr.io/nvidia/l4t-tensorrt:r8.0.1-runtime
steps:
- name: Checkout code
uses: actions/checkout@v4
with:
ref: v0.2.0
...I am trying to do cross-compilation. The self-hosted runner is x86-64, but the Docker image is arm64. However, I am encountering the following error.
Run actions/checkout@v4
with:
ref: v0.[2](https://github.com/TechWhiskers/fastflow_core/actions/runs/8644594833/job/23700048482#step:3:2).0
repository: TechWhiskers/fastflow_core
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 0[3](https://github.com/TechWhiskers/fastflow_core/actions/runs/8644594833/job/23700048482#step:3:3)0cae08918d43e6cbb15a[4](https://github.com/TechWhiskers/fastflow_core/actions/runs/8644594833/job/23700048482#step:3:4)a5b7b1b192276fc6a65970291c246d34a8349c3a0 sh -c "cat /etc/*release | grep ^ID"
exec /__e/node20/bin/node: no such file or directory
Does the GitHub runner support this method?
What version is the Actions Runner software in that image? Can you confirm it supports Node 20 (version must be >= https://github.com/actions/runner/releases/tag/v2.308.0)
I know that this is old, but we're running GHES 3.12.5 and our self-hosted runners are using the v2.316.1 release. This only seems to occur when a job is running inside a custom Docker container. While the workflow log says that /__e/ is mounted as expected, the error message is still common in these scenarios.
exec /__e/node20/bin/node: no such file or directory
This happens with GitHub-hosted runners, too.
jobs:
build_other:
name: build on ${{ matrix.arch }}/debian:12
runs-on: ubuntu-22.04
container: ${{ matrix.arch }}/debian:12
strategy:
matrix:
arch: [i386, amd64]
steps:
- uses: actions/checkout@v4The first job (on i386/debian:12) fails with the error in the title; the second (on amd64/debian:12) checks out the code successfully.