GITHUB_WORKSPACE variable empty

Hi

I noticed if I wanted to access the GITHUB_WORKSPACE variable after using the checkout action, it is not available in the env context.

It was until I noticed weide-zhou’s reply here where they suggest the variable is in actual fact part of the github context.

Does anyone else feel like this document, which explains default environment variables, could do a little better highlighting that detail? i.e. explicitly saying GITHUB_WORKSPACE (and maybe others?) are not part of the env context.

1 Like

This is a general limitation:

You can only use the env context in the value of the with and name keys, or in a step’s if conditional. For more information on the step syntax, see “Workflow syntax for GitHub Actions.”

However, it doesn’t appear to work for the name attribute?!

      - name: env.GITHUB_WORKSPACE = ${{ env.GITHUB_WORKSPACE }}
        run: |
          echo "GITHUB_WORKSPACE = $GITHUB_WORKSPACE"

The step shows as env.GITHUB_WORKSPACE =  despite what the documentation states…

This morning I discovered it does not work within a value of with:

name: "01b - Using Actions"

on:
  push:
    branches:
      - master

jobs:
  main:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v2.3.3

        # https://github.com/marketplace/actions/azure-blob-storage-upload
      - name: Azure Blob Upload
        uses: bacongobbler/azure-blob-storage-upload@v1.1.1
        with:
          connection_string: ${{ secrets.AZURE_STORAGE_BLOB_SAS_CONNECTIONSTRING }}
          container_name: winadmins-githubactions
          sync: true
          source_dir: ${{ env.GITHUB_WORKSPACE }}

Does it work if you use ${{ github.workspace }} from the github context instead? Note though that if the action runs in the container the actual path inside the container may be different, but the matching mountpoint will be set as --workdir for the Docker container.

Yes, it does work if I use ${{ github.workspace }} instead of ${{ env.GITHUB_WORKSPACE }}. That is the main driver for me making this post :smile:

I don’t actually know too much about that particular action, I’m merely a user but from reading the logs I can infer it’s spinning up a container. --workdir is used with value /github/workspace as its value.

Not too sure what that means. Is there a suspect fundamental issue with the docs or the env context? Or is it the fact that the environment is being shifted to inside a container?

That depends: If it look like the action receives an empty value for ${{ env.GITHUB_WORKSPACE }} that’d look like a bug to me. But if it looks like the directory the value points at doesn’t exist inside the container, yeah, that’s likely because the environment into the container looks different.

That difference fell on my feet a few days ago: I added clang analyzer (for static code analysis) to a build that runs inside a job container, and then use the github/codeql-action/upload-sarif action to upload the results to the repository security tab. That action tries to turn any absolute paths inside the results file into relative ones, so they match paths inside the repository. By default it uses github.workspace for that, but that didn’t actually match anything inside the file. I had to add a step that stores the working directory inside container, and then pass that to the upload action instead.