Containerized action workspace directories seems to be rewritten on-the-fly

[nervo]

In a containerized action, where docker volumes are automatically mounted, the default github.workspace property (something like /home/runner/work/my-repo-name/my-repo-name) is automatically converted to the volume destination path (/github/workspace). Btw, this conversion seems to be applied on-the-fly on all action parameters, stopping ability to use the original workspace path (/home/runner/work/my-repo-name/my-repo-name) in custom behaviors (such as - for instance - mounting workspace volumes in a docker-in-docker context)

Steps to reproduce the behavior:

1. Define some environment variables in a containerized action

      - name: Test
        uses: gofrolist/molecule-action@v2
        env:
          DEST_WORKSPACE: ${{ github.workspace }}
          SRC_WORKSPACE: ${{ runner.workspace }}/${{ github.event.repository.name }}
          SRC_WORKSPACE_FOO: ${{ runner.workspace }}/foo/${{ github.event.repository.name }}

3. See error

• DEST_WORKSPACE is /github/workspace and not /home/runner/work/my-repo-name/my-repo-name, that's fine :)
• SRC_WORKSPACE should be the original /home/runner/work/my-repo-name/my-repo-name as it's exactly how checkout action compose it but is /github/workspace
• SRC_WORKSPACE_FOO where the original workspace is poorman's obfuscated by injected a "foo" string is /home/runner/work/my-repo-name/foo/my-repo-name

Expected behavior I expected to be able to use the original workspace /home/runner/work/my-repo-name/my-repo-name directory string in custom situations.

Runner Version and Platform

The last available one on linux

[haacked]

I'm running into an issue with this where I have a compile step that produces an output that needs to be referenced by a build step that runs as a containerized action.

The compile step reports the output as /home/runner/work/my-repo/my-repo/somepath

The containerized action cannot find the output, possibly because of a mistake on my part. Unfortunately, the paths it reports where it searched all use /github/workspace/somepath. It's confusing to try and debug this.

[chrispat]

@haacked But shouldn't your compile output still be relative to $GITHUB_WORKSPACE?

[haacked]

@chrispat I assume so.

Is this correct?

$GITHUB_WORKSPACE == /home/runner/work/my-repo/my-repo == /github/workspace

[chrispat]

Yes.

[haacked]

Ah, so this is also true based on my experiments.

${{ runner.workspace }} = /home/runner/work/my-repo ${{ github.workspace }} = /home/runner/work/my-repo/my-repo

[chrispat]

I would say never rely on specific paths as they could change you should use the variables we provide to locate the root of your repository.

[haacked]

I got it working in my case. It was confusing because I couldn't find any documentation of the /github/workspace path. It's not mentioned anywhere. So when my containerized action said something like "File foo.dll not found in /github/workspace/bin/release" I didn't know what that meant.

[ruvceskistefan]

Hi @nervo, @haacked, As far as I can see @chrispat explained everything to you, so is it clear now? If so and if you agree, I think I can close this issue.

[ruvceskistefan]

I'm going to close out this issue until we hear back from you, please let us know if you are still seeing this issue!

[ghost]

Can this be re-opened? Seeing this issue:

An error occurred trying to start process '/usr/bin/bash' with working directory '/home/runner/work/repo-name/repo-name/terraform'. No such file or directory

  terraform:
    defaults:
      run:
        working-directory: ./terraform
    runs-on: ubuntu-latest
    steps:
      - name: Configure AWS credentials for test
        uses: aws-actions/[email protected]
        ...

[matt-mercer]

I'd also like to add my backing to this issue .. it's all well and good saying don't use explicit paths, but it is not uncommon for some tools to bake in explicit paths, I'm working with python, a couple of examples I've hit, virtualenv console scripts and coverage.xml files contain a reference to the explicit location the coverage was generated.

It is a totally reasonable request for either:

• the workspace volume mount location to mirror the host location or
• the workspace volume mount location to be configurable on any action

this is is the sort of annoyance that can ( and has today for me ) burn days of effort trying to workaround issues of compatibility between tests generated on the host, and static analysis tooling running in a an action.

[Mi-La]

Is it ok to use ${{runner.workspace}} (or ${RUNNER_WORKSPACE}) even though such key is not documented on the runner context?