Encountering "/steps/entrypoint.sh: No such file or directory" when running the action

[Minimata]

Hello,

I'm trying to use Game CI's Github Actions on my Gitea server.
The server is hosted using Docker and uses Gitea's act runner as a worker for Actions.
The docker host is a CentOS on the cloud.

In that context, when using the unity-test-runner@v4 action, I quickly encounter an error following the docker command ran by the action: /bin/bash: line 1: /steps/entrypoint.sh: No such file or directory

Here is the full command that generates this error:

[command]/usr/bin/docker run 
--workdir /github/workspace 
--cidfile /tmp/container_4 
--rm 
--env UNITY_EMAIL=*** 
--env UNITY_PASSWORD=*** 
--env UNITY_SERIAL=*** 
--env UNITY_VERSION=2022.3.43f1 
--env PROJECT_PATH=. 
--env COVERAGE_OPTIONS=generateAdditionalMetrics;generateHtmlReport;generateBadgeReport;dontClear 
--env COVERAGE_RESULTS_PATH=CodeCoverage 
--env ARTIFACTS_PATH=artifacts 
--env PACKAGE_MODE=false 
--env REGISTRY_SCOPES= 
--env RUN_AS_HOST_USER=true 
--env GITHUB_REF=refs/heads/main 
--env GITHUB_SHA=1ee52795300db287f4512e19dd1b22af592c7a75 
--env GITHUB_REPOSITORY=minimata/Unity-CICDTests 
--env GITHUB_ACTOR=minimata 
--env GITHUB_WORKFLOW=Run tests on the project 
--env GITHUB_EVENT_NAME=push 
--env GITHUB_ACTION=4 
--env GITHUB_EVENT_PATH=/var/run/act/workflow/event.json 
--env RUNNER_OS=Linux 
--env RUNNER_TOOL_CACHE=/opt/hostedtoolcache 
--env RUNNER_TEMP=/tmp 
--env GIT_CONFIG_EXTENSIONS 
--env TEST_PLATFORMS=playmode;editmode;COMBINE_RESULTS 
--env GITHUB_WORKSPACE=/github/workspace 
--volume /tmp/_github_home:/root:z 
--volume /tmp/_github_workflow:/github/workflow:z 
--volume /workspace/minimata/Unity-CICDTests:/github/workspace:z 
--volume /run/act/actions/game-ci-unity-test-runner@v4/dist/test-standalone-scripts:/UnityStandaloneScripts:z 
--volume /run/act/actions/game-ci-unity-test-runner@v4/dist/platforms/ubuntu:/steps:z 
--volume /run/act/actions/game-ci-unity-test-runner@v4/dist/unity-config:/usr/share/unity3d/config/:z 
--volume /run/act/actions/game-ci-unity-test-runner@v4/dist/BlankProject:/BlankProject:z 
--cpus=2 
--memory=2g 
--env USE_EXIT_CODE=false 
unityci/editor:2022.3.42f1-linux-il2cpp-3 /bin/bash -c /steps/entrypoint.sh

I think it's a permission error because the files do exist on the host and the volume is correctly bound at this point in the command --volume /run/act/actions/game-ci-unity-test-runner@v4/dist/platforms/ubuntu:/steps:z. Therefore, the entrypoint.sh should be in the launched container but the No such file or directory error can be raised even though the file exists but the process doesn't have the right to execute it, which is why I think this is the issue there.

However, I couldn't find a way to give this permission to the created container. Here a few things I tried:

• running docker:dind as a service for my job to have my worklow run docker commands with the privileged option. It's the first time I'm using any kind of dind setup or external service in a workflow so I might have made a mistake there because it changed nothing.
• use the runAsHostUser input which unfortunately does nothing either.

I have read through the documentation and searched the indexed internet for an answer but couldn't really find anything useful. Maybe someone here will have an idea of what's the issue or a workaround?

Thanks!

How to reproduce

Gitea instance docker setup a bit simplified to stay as concise as possible

  gitea:
    image: gitea/gitea:1.21
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - GITEA__database__DB_TYPE=postgres
      - GITEA__database__HOST=gitea_db:5432
      - GITEA__database__NAME=${GITEA_DB_NAME}
      - GITEA__database__USER=${GITEA_DB_USER}
      - GITEA__database__PASSWD=${GITEA_DB_PASSWORD}
    volumes:
      - ./gitea:/data
      - /home/git/.ssh:/data/git/.ssh
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - 127.0.0.1:2222:22

  gitea_db:
    image: postgres:16
    environment:
      - POSTGRES_USER=${GITEA_DB_USER}
      - POSTGRES_PASSWORD=${GITEA_DB_PASSWORD}
      - POSTGRES_DB=${GITEA_DB_NAME}
    volumes:
      - ./gitea-postgres:/var/lib/postgresql/data

  gitea_runner:
    image: gitea/act_runner:nightly
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./gitea-runner:/config
    environment:
      - GITEA_INSTANCE_URL=${HTTP_SCHEME}://${GITEA_SUBDOMAIN}.${DOMAIN_NAME}
      - GITEA_RUNNER_REGISTRATION_TOKEN=${GITEA_RUNNER_REGISTRATION_TOKEN}
      - CONFIG_FILE=/config/config.yaml

Workflow file a bit simplified to stay as concise as possible

name: Run tests on the project
on:
  push:

jobs:
  build:
    runs-on: ubuntu-latest
    
    services:
      docker:
        image: docker:dind
        options: --privileged
        volumes:
          - /var/run/docker.sock:/var/run/docker.sock
      
    steps:
      - name: Install necessities
        run: |
          apt update
          apt install -y docker.io   

      - name: Checkout
        uses: actions/checkout@v4
        with:
          lfs: true
    
      # Cache
      - uses: actions/cache@v3
        with:
          path: Library
          key: Library-${{ hashFiles('Assets/**', 'Packages/**', 'ProjectSettings/**') }}
          restore-keys: |
            Library-

      # Test
      - name: Run tests
        uses: game-ci/unity-test-runner@v4
        env:
          UNITY_LICENSE: ${{ secrets.UNITY_LICENSE }}
          UNITY_EMAIL: ${{ secrets.UNITY_EMAIL }}
          UNITY_PASSWORD: ${{ secrets.UNITY_PASSWORD }}
        with:
          githubToken: ${{ secrets.TOKEN }}
          customImage: 'unityci/editor:2022.3.42f1-linux-il2cpp-3'
          runAsHostUser: true
          dockerCpuLimit: 2
          dockerMemoryLimit: 2g

• Expected behavior

The command forged by the unity-test-runner action should find the /steps/entrypoint.sh file and be able to launch it.

[Minimata]

Alright so the issue was because of Docker-in-docker (dind).

To run my workflows I was using Gitea's container Action runner, so a docker container that spawns other containers to run jobs. Since GameCI's action runs it's own containers for Unity, it meant that these containers would spawn while already inside another container, so a Docker-in-docker situation. As it turns out, volume mounts don't work the same when using a dind setup and therefore, the mounts for steps/entrypoints.sh didn't work properly.

I didn't find a solution to this, only a workaround. Instead of using a Gitea Act runner container for anything tagged ubuntu-latest, I spawned another linux machine and registered the non-container version of Gitea's runner in there with a label unity.

This means that any random job I launch on ubuntu-latest will still run in the container but any workflow labeled unity will run on the bare metal version of the runner and that's what I use for Game CI's actions. This "fixes" the dind issues since we're not in a dind situation anymore.

EDIT: formatting and typo.

[Lexian-droid]

Hello, I wanted to ask you a question, I am using a slough of VPSes and I am encountering this issue too, but I don't quite know what to do. Are you saying you got another linux VM or are you saying you ran a second docker container for unity?

[Minimata]

• I spined up another VPS running on Ubuntu 22.
• I installed git-lfs, Node, Docker and XVFB on it because the actions I'm using are going to need these services to be able to run.
• I downloaded Gitea's act_runner directly on the machine, running the shell script barebones instead of through the docker container. In other words this means that the Ubuntu machine is going to run the actions instead of the docker container of the runner.
• Start with ./act_runner-0.2.11-linux-amd64 register and following the instructions then ./act_runner-0.2.11-linux-amd64 daemon & to actually launch the runner and making it available for jobs.
• Now whenever GameCI's actions launch docker containers, they are handled by the Ubuntu machine directly: it's not docker-in-docker anymore, it's simply docker. Therefore, there is no issues with volumes and the action is working fine.

Hope this helps.

[Lexian-droid]

• I spined up another VPS running on Ubuntu 22.

  • I installed git-lfs, Node, Docker and XVFB on it because the actions I'm using are going to need these services to be able to run.

  • I downloaded Gitea's act_runner directly on the machine, running the shell script barebones instead of through the docker container. In other words this means that the Ubuntu machine is going to run the actions instead of the docker container of the runner.

  • Start with ./act_runner-0.2.11-linux-amd64 register and following the instructions then ./act_runner-0.2.11-linux-amd64 daemon & to actually launch the runner and making it available for jobs.

  • Now whenever GameCI's actions launch docker containers, they are handled by the Ubuntu machine directly: it's not docker-in-docker anymore, it's simply docker. Therefore, there is no issues with volumes and the action is working fine.

Hope this helps.

Thanks! This actually really does help! :)

[Lexian-droid]

Hello again, I wanted to ask, what did you type in the "Labels"? for me I just typed unity but it seems to not work, it connects it does all that, but the actions don't actually run in the VPS. Think you can help me out?

[Minimata]

It depends what labels you set when you registered the runner on the VPS. You can check them out in the "Actions > runners" tab in the settings of the Gitea instance or in the .runner file on the VPS that the runner created on registration.

To debug this you may also just launch the runner with ./act_runner-0.2.11-linux-amd64 daemon (without the &) and check the output you get when the jobs start. If the job is indeed attributed to the runner, it should log a line that looks like task [id] .... That's how you know it actually started some work.

[Lexian-droid]

I seem to have gotten it to work, it was just that in the workflow I wasn't changing "ubuntu-latest" to "unity"

I'm curious, when your test runner is started, do you get the error "404 not found" at the very end? I think it's trying to upload the artifacts but it gives an error because gitea doesn't have the endpoint, I don't really know how to fix it in all honesty.

[Minimata]

No I didn't have the 404 error you describe. All artifacts I ever had were uploaded successfully without having to do any setup as far as I can recall.