Install Commands without GitHub Token not Executed

[eXpl0it3r]

Description

If you don't use a GitHub Token to cache the Docker image, the install options aren't actually executed.

Steps to Reproduce

1. Create a GitHub Actions workflow using run-on-arch-action
2. Specify install commands
3. Don't provide a github-token
4. Run the workflow

name: NuGet Release

on: [push, workflow_dispatch]

concurrency:
    group: nuget-${{github.ref}}
    cancel-in-progress: true

jobs:
    linux-arm64:
        name: Linux ARM64
        runs-on: ubuntu-22.04

        steps:
            - name: Checkout CSFML
              uses: actions/checkout@v4
              with:
                  path: CSFML

            - name: Build in ARM64 container
              uses: uraimo/[email protected]
              with:
                arch: aarch64
                distro: ubuntu22.04
                install: |
                  apt-get update
                  apt-get install -y git libfreetype6-dev xorg-dev libxrandr-dev libxcursor-dev libudev-dev libgl1-mesa-dev libflac-dev libogg-dev libvorbis-dev libopenal-dev cmake g++
                run: |
                  cd ./CSFML/tools/nuget
                  chmod +x ./build.linux.sh
                  ./build.linux.sh linux-arm64

            - name: Upload Artifact
              uses: actions/upload-artifact@v4
              with:
                  name: CSFML-linux-arm64
                  path: CSFML/tools/nuget/CSFML

Actual Behavior

It just launches a default Docker image that doesn't run the specified install commands.

Expected Behavior

Even if the Docker image isn't cached, the built Docker image should be used and the install commands should be executed.

Workaround

Just run the apt-get install commands in the run section first.

Additional Information

You never see the install being executed.

Here's the output:

Build container

#0 building with "default" instance using docker driver
  
  #1 [internal] load .dockerignore
  #1 transferring context: 2B done
  #1 DONE 0.0s
  
  #2 [internal] load build definition from Dockerfile.aarch64.ubuntu22.04
  #2 transferring dockerfile: 219B done
  #2 DONE 0.0s
  
  #3 [auth] arm64v8/ubuntu:pull token for registry-1.docker.io
  #3 DONE 0.0s
  
  #4 [internal] load metadata for docker.io/arm64v8/ubuntu:22.04
  #4 DONE 0.2s
  
  #5 [internal] load build context
  #5 transferring context: 109B done
  #5 DONE 0.0s
  
  #6 [1/3] FROM docker.io/arm64v8/ubuntu:22.04@sha256:462e829de9164b6c066246cddc265a93607[17](https://github.com/eXpl0it3r/CSFML/actions/runs/9119474572/job/25074906979#step:3:18)44f689f0ea73daa92b4f9feb47e
  #6 resolve docker.io/arm64v8/ubuntu:22.04@sha256:462e829de9164b6c066246cddc265a936071744f689f0ea73daa92b4f9feb47e done
  #6 sha256:462e829de9164b6c066246cddc265a936071744f689f0ea73daa92b4f9feb47e 424B / 424B done
  #6 sha256:7423357ed609f13ba90313f43454dc3026afb26476e14cb8b1dbb3eadb8a192c 2.31kB / 2.31kB done
  #6 sha256:d5a2ad729c09fbfdb259ae764f92[18](https://github.com/eXpl0it3r/CSFML/actions/runs/9119474572/job/25074906979#step:3:19)8efc67a615ffde9bb34a46298d1edf3cd6 1.05MB / 27.36MB 0.1s
  #6 sha256:d5a2ad729c09fbfdb259ae764f92188efc67a615ffde9bb34a46298d1edf3cd6 13.63MB / 27.36MB 0.3s
  #6 sha256:d5a2ad729c09fbfdb259ae764f92188efc67a615ffde9bb34a46298d1edf3cd6 25.17MB / 27.36MB 0.5s
  #6 sha256:d5a2ad729c09fbfdb259ae764f92188efc67a615ffde9bb34a46298d1edf3cd6 27.36MB / 27.36MB 0.6s
  #6 extracting sha256:d5a2ad729c09fbfdb259ae764f92188efc67a615ffde9bb34a46298d1edf3cd6
  #6 sha256:d5a2ad729c09fbfdb259ae764f92188efc67a615ffde9bb34a46298d1edf3cd6 27.36MB / 27.36MB 0.6s done
  #6 extracting sha256:d5a2ad729c09fbfdb259ae764f92188efc67a615ffde9bb34a46298d1edf3cd6 1.0s done
  #6 DONE 1.7s
  
  #7 [2/3] COPY ./run-on-arch-install.sh /root/run-on-arch-install.sh
  #7 DONE 0.2s
  
  #8 [3/3] RUN chmod +x /root/run-on-arch-install.sh && /root/run-on-arch-install.sh
  #8 DONE 0.3s
  
  #9 exporting to image
  #9 exporting layers
  #9 exporting layers 0.2s done
  #9 writing image sha256:e871c04d432b98b747c68[20](https://github.com/eXpl0it3r/CSFML/actions/runs/9119474572/job/25074906979#step:3:21)aa84e1f3148e5f25ff7c811bbc2d75ad2905aa9e8 done
  #9 naming to docker.io/library/run-on-arch-expl0it3r-csfml-nuget-release-aarch64-ubuntu[22](https://github.com/eXpl0it3r/CSFML/actions/runs/9119474572/job/25074906979#step:3:23)-04:latest done
  #9 DONE 0.2s

Run container

WARNING: The requested image's platform (linux/arm64/v8) does not match the detected host platform (linux/amd64/v3) and no specific platform was requested
  Please note that all SFML dependencies must be installed and available to cmake. SFML does not ship with its linux dependencies.
  Building linux-arm[64](https://github.com/eXpl0it3r/CSFML/actions/runs/9119474572/job/25074906979#step:3:65)
  /home/runner/work/CSFML/CSFML/CSFML/tools/nuget/Build /home/runner/work/CSFML/CSFML/CSFML/tools/nuget
  Cloning SFML
  ./build.linux.sh: line 64: git: command not found

[martin-g]

You are missing dockerRunArgs where you need to mount the host folder to the Docker container.
See an example at https://github.com/lh3/bwa/blob/79b230de48c74156f9d3c26795a360fc5a2d5d3b/.github/workflows/ci.yaml#L39-L40

[eXpl0it3r]

Thank you for the reply! 🙂

I don't quite understand the connection between mounting the host directory and having the install section executed. Why is one needed for the other?

Might be a good hint for the readme then, as there doesn't seem to be an indication that this is necessary.

[martin-g]

I didn't say that the mounting is related to the installation step! They might be related but I didn't check the source code to validate this!

I pointed you at dockerRunArgs because of

run: |
                  cd ./CSFML/tools/nuget

Without the mounting you cannot expect to find CSFML/ inside the Docker container!

Does your CI workflow work now after adding dockerRunArgs ?

[eXpl0it3r]

Yes, after adding it, it does execute correctly.

It's however still unclear to me, why before it didn't even run the installation (no output in the log).
So without a dockerRunArgs, the image isn't even executed?

What's even more peculiar is, that it still ran the run commands without it, but I assume directly on the host, since the volume wasn't actually mapped?