${{ github.action_path }} makes no sense when action is run inside self-hosted custom container.

[sebastian-freitag]

Describe the bug
${{ github.action_path }} points to a location in the host filesystem of the github runner host. Not to /__w/_actions/...

To Reproduce
Steps to reproduce the behavior:

1. Create a custom container.
2. Create a workflow that uses the custom docker container on a self-hosted runner.
3. Try to follow the guide for the new composite actions that requires to use ${{ github.action_path }}, for example to locate a shell script of a composite action.

Expected behavior
The shell script is found and executed, just like when doing this with a normal ubuntu-latest runner.

Runner Version and Platform

v2.273.4 on Linux.

OS of the machine running the runner? OSX/Windows/Linux/...
Linux.

What's not working?

(...)
##[error]Process completed with exit code 127.
Run pylot-tech/actions_checkout@v1
/__w/_temp/615e5631-1155-478e-93e8-8e5cc51fb88e.sh: line 1: /home/github-runner/actions-runner-new/_work/_actions/pylot-tech/actions_checkout/v1/clone.sh: No such file or directory

[AltiusRupert]

Hi Sebastian,,
SImilar issue here.
Did you figure out a way of running your script ?

[AltiusRupert]

See also #649

[sebastian-freitag]

Hi Sebastian,,
SImilar issue here.
Did you figure out a way of running your script ?

By not using ${{ github.action_path }} and instead hard-coding the location:

runs:
  using: "composite"
  steps:
    - run: /__w/_actions/(... repo of my script ...)/v1/clone.sh
      shell: bash

Ugly, quick solution.

[AltiusRupert]

Hi Sebastian,
Thanks for your answer.

I too found this same workaround in the meantime.

[zotrix]

seems like env variable GITHUB_ACTION_PATH set to correct path.
so step could be called via GITHUB_ACTION_PATH instead of ${{ github.action_path }}

  - run: ${GITHUB_ACTION_PATH}/setup.sh
    shell: sh

[travislikestocode]

Here's a workaround that will allow you to use existing composite actions without modifying them. This should work on self-hosted runners using a BASH shell with gnu utils. Note that this includes a workaround for #691 as well with the step ID get-user. The one for this bug is the workdir step. I'm including it in case someone finds this bug first.

jobs:
  docker_workaround:
    runs-on: [ your-tags ]
    outputs:
      uid_gid: ${{ steps.get-user.outputs.uid_gid }}
      workdir: ${{ steps.get-workdir.outputs.workdir }}
    steps:
      - id: get-user
        run: echo "::set-output name=uid_gid::$(id -u):$(id -g)"

      - id: get-workdir
        run: echo "::set-output name=workdir::$(echo '${{ runner.workspace }}' | sed s:/[^/]*$::)"

Then on the job which uses a composite action:

  the-job:
    name: I am a job
    needs:
      - docker_workaround
    runs-on: [ your-tags ]
    container:
      image: your-image
      options: --user ${{ needs.docker_workaround.outputs.uid_gid }}
      volumes:
        - ${{ needs.docker_workaround.outputs.workdir }}:${{ needs.docker_workaround.outputs.workdir }}
...

[FearlessHyena]

Any chance of getting ${{ github.action_path }} to point to the correct location without the workaround?

[nikola-jokic]

Hey everyone,

We created a PR fixing this issue 😊.

[ricardo-noyolalozano]

4 years later and this is still broken

[ElvenSpellmaker]

Hey everyone,

We created a PR fixing this issue 😊.

Any update on this please? It's still an issue now (definitely for GHES at least).

[joaoantoniocardoso]

I hope this can be fixed soon

[zachspar]

We created a PR fixing this issue 😊.

@nikola-jokic not sure why this is closed... still a problem!