github.workspace and runner.workspace are incorrect inside container jobs

[tspascoal]

Describe the bug

github.Workspace and runner.Workspace don't point to container valid paths when executing inside a container job.

The values are also inconsistent with the values for env variables GITHUB_WORKSPACE and RUNNER_WORKSPACE (both contain a valid path.

To Reproduce
Steps to reproduce the behavior:

1. Create a workflow with the following jobs

jobs:
  runner:
    runs-on: ubuntu-latest

    steps:
      - name: dump
        run: |
          echo 'github.workspace === ${{ github.workspace }}'
          echo "GITHUB_WORKSPACE === $GITHUB_WORKSPACE"
          echo 'runner.workspace === ${{ runner.workspace }}'
          echo "RUNNER_WORKSPACE === $RUNNER_WORKSPACE"
  container:    
    runs-on: ubuntu-latest
    container:
      image: node:14.16
      
    steps:
      - name: dump
        run: |
          echo 'github.workspace === ${{ github.workspace }}'
          echo "GITHUB_WORKSPACE === $GITHUB_WORKSPACE"
          echo 'runner.workspace === ${{ runner.workspace }}'
          echo "RUNNER_WORKSPACE === $RUNNER_WORKSPACE"

2. Check the value in the container job for ${{ github.workspace }} and $GITHUB_WORKSPACE which are not the same
3. Check the value in the container job for ${{ runner.workspace }} and $RUNNER_WORKSPACE which are not the same

Expected behavior

On the container job github.workspaceand runner.workspace should point to a path in the directory /__w

Runner Version and Platform

Version of your runner? 2.295.0

OS of the machine running the runner? ubuntu 20.04.4 (ubuntu-latest)

What's not working?

The values for github.workspace and runner.workspace are incorrect in the container job (and inconsistent with respective env variables)

Job Log Output

If applicable, include the relevant part of the job / step log output here. All sensitive information should already be masked out, but please double-check before pasting here.

Output of container dump step in the container job

github.workspace === /home/runner/work/testContainers/testContainers
GITHUB_WORKSPACE === /__w/testContainers/testContainers
runner.workspace === /home/runner/work/testContainers
RUNNER_WORKSPACE === /__w/testContainers

Runner and Worker's Diagnostic Logs

If applicable, add relevant diagnostic log information. Logs are located in the runner's _diag folder. The runner logs are prefixed with Runner_ and the worker logs are prefixed with Worker_. Each job run correlates to a worker log. All sensitive information should already be masked out, but please double-check before pasting here.

[fhammerl]

Hi @tspascoal,

Thanks for reporting this issue. We've investigated this issue before and are working on resolving it 👍

2022-08-22 Update: Correctly translating github.workspace causes some regressions, considering introducing github.host-workspace

[nqb]

Hello @fhammerl,

Did you make any progress on this issue ?

[wesbrownfavor]

Has anyone figured out a workaround for this?

[DmitriyBobrovskiy]

We've started experiencing same issues since we moved to running jobs inside containers and what was the most interesting is the fact that we used in all cases ${{ github.workspace }} variable. Our pipeline looked like this:

  build:
    name: Build, Test & Publish
    runs-on: self-hosted
    container:
      image: internalregistry.io/internal-image:3
    steps:
      - uses: actions/checkout@v3
          
      - name: Build, Test and analyze
        shell: bash
        run: |
          dotnet test 

      - name: Publish
        shell: bash
        run: |
          for f in $(find src -name '*.csproj'); do
            d=$(dirname  $f)
            outputFolder=${{ github.workspace }}/${{ env.ARTIFACT }}/$d
            ( cd "$d" && dotnet publish --no-self-contained -c $BUILD_CONFIGURATION -o $outputFolder )
          done

      - name: Publish artifacts
        uses: actions/upload-artifact@v3.1.1
        with:
          name: ${{ env.ARTIFACT }}-v${{ github.run_number }}
          retention-days: 1
          path: ${{ github.workspace }}/${{ env.ARTIFACT }}/src
          if-no-files-found: error

And $outputFolder looked like this /__w/<project_name>/<project_name>/<env.ARTIFACT>/src/SomeProject.
But still in Publish artifacts step we were getting error:

Error: No files were found with the provided path: /__w/<project_name>/<project_name>/<env.ARTIFACT>/src. No artifacts will be uploaded.

Then we changed workflow to this to overcome this problem and it started working:

  build:
    name: Build, Test & Publish
    runs-on: self-hosted
    container:
      image: internalregistry.io/internal-image:3
    steps:
      - uses: actions/checkout@v3
          
      - name: Build, Test and analyze
        shell: bash
        run: |
          dotnet test 

      - name: Publish
        shell: bash
        run: |
          echo "GITHUB_WORKSPACE=$GITHUB_WORKSPACE" >> $GITHUB_ENV
          for f in $(find src -name '*.csproj'); do
            d=$(dirname  $f)
            outputFolder=${{ env.GITHUB_WORKSPACE }}/${{ env.ARTIFACT }}/$d
            ( cd "$d" && dotnet publish --no-self-contained -c $BUILD_CONFIGURATION -o $outputFolder )
          done

      - name: Publish artifacts
        uses: actions/upload-artifact@v3.1.1
        with:
          name: ${{ env.ARTIFACT }}-v${{ github.run_number }}
          retention-days: 1
          path: ${{ env.GITHUB_WORKSPACE }}/${{ env.ARTIFACT }}/src
          if-no-files-found: error

Now paths in both steps look similar: /__w/<project_name>/<project_name>/<env.ARTIFACT>/src.
So in short we saved $GITHUB_WORKSPACE to environment variables and started using it instead of ${{ github.workspace }}. Maybe we don't even need to save it and can just use it out of the box, didn't try this.

[woutersf]

I started using Artifacts.
In the first Job 1: push file to Artifact

  # Archive zip
  - name: Archive artifact
    uses: actions/upload-artifact@v3
    with:
      name: files-${{ github.run_id }}.tar.gz
      retention-days: 1
      if-no-files-found: error
      path: |
        ${{ github.workspace }}/files-${{ github.run_id }}.tar.gz

In the second Job, download the file in order to use it.

  # Fetch Dump from artifact storage
  - uses: actions/download-artifact@v2
    with:
      name: files-${{ github.run_id }}.tar.gz

After all other tasks: Delete the artifact, we dont want to keep it outside of the job run

  # Delete artifact
  - uses: geekyeggo/delete-artifact@v2
    with:
      name: |
          files-${{ github.run_id }}.tar.gz

The infra people at our organisation wanted the workers to be ephermeral and not link in storage.
The "workaround" with the arifacts actually works quite well.

[SS1823]

It's almost 2 years, you could at least update the documentation, so people would not hit this bug.
The same goes for #2185 (and maybe other context variables where path is involved)
Why not just bind the paths 1:1 instead making them shorter? Would solve all these problems.

[obewan]

I got a nice workaround for this, thanks to Pi AI for the help, by using working-directory directive for the container and for the steps, like:

jobs:
  build:
    name: Build
    defaults:
      run:
        working-directory: ./github-actions-docker

    runs-on: ubuntu-latest
    container:
      image: ghcr.io/me/myimage

    steps:
      - uses: actions/checkout@v4

      - name: Configure CMake
        run: |
          cmake -B build -DCMAKE_BUILD_TYPE=Debug
        env:
          CXX: g++-12
        working-directory: ${{github.workspace}}

      - name: Build
        run: cmake --build build --config Debug -- -j 2
        working-directory: ${{github.workspace}}

      - name: Run unit tests
        run: ./tester
        working-directory: ${{github.workspace}}/build/test/doctests

Then beware to not use ${{github.workspace}} directly in the run commands, just use the working-directory directive instead.

[ghost]

Any update on this? Even when setting a custom environmental variable, the runner actions strips this out during run-time:

Run echo "CUSTOM_WORKSPACE=/actions-runner/_work/<repo>/<repo>" >> $GITHUB_ENV
  echo "CUSTOM_WORKSPACE=/actions-runner/_work/<repo>/<repo>" >> $GITHUB_ENV
  shell: sh -e {0}

Run echo "CUSTOM WORKSPACE: $CUSTOM_WORKSPACE"
  echo "CUSTOM WORKSPACE: $CUSTOM_WORKSPACE"
  echo "github.workspace: /actions-runner/_work/<repo>/<repo>"
  shell: sh -e {0}
  env:
    CUSTOM_WORKSPACE: /actions-runner/_work/<repo>/<repo>
CUSTOM WORKSPACE: /__w/<repo>/<repo>
github.workspace: /actions-runner/_work/<repo>/<repo>

Is there any solution to the runner referencing an absolute directory on the host? I'm running a docker container that needs to mount checked out directories.

[ghost]

If anyone comes across this, a fix that works but could be better is the following:

- name: Set abs-path file
  run: |
    echo "${{ github.workspace }}" >> abs-path
    cat abs-path

echo the {{ github.workspace }} variable into a file on the runner. This will give the absolute host path which can then be read in later steps, in my case, docker in docker for rootless builds on the runner. Any way I tried, the runner appears to re-write the /actions-runner/__work/<route>/ to /__w/<route> - hopefully this saves some people a few hours...

[st3fan]

Not affiliated with GitHub but I think it is fair to assume that this inconsistency will never be fixed as it would break containers and actions that depend on the current behaviour.

[ffMathy]

@st3fan never say never. That's what major version upgrades are for. That way, it would be OK.