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

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

One thing to note is that ${{runner.workspace}} inside the run part of the step, yields different results than ${{runner.workspace}} being inside the working-directory of a step.

In my case the working-directory will spit out a /__w/REPOSITORY/, while run will spit out a /home/ubuntu/actions-runner/_work/REPOSITORY/.

Hello @fhammerl,

Did you make any progress on this issue ?

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.

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.

Wh I do differently is that I have the helm charts in a separate rep and aI pull them in

      - name: Checkout helm repo
        uses: actions/checkout@v3
        with:
          repository: woutersf/drupal-helm-charts-k8s
          path: upstream_helm
          token: ${{ secrets.GIT_CHECKOUT_TOKEN }}
          ref: '${{ inputs.aks_branch }}'

and then in a later step

      # Validate helm stuff to not leave a broken state.
      - name: DRY RUN
        run: |
          cd helm
          helm upgrade --dry-run --timeout 15m --install -n ${{ inputs.app_key }}-${{ inputs.environment }} -f values-${{ inputs.environment }}.yaml --set deploy.runid=${{ github.run_id }} --set image.tag=${{ inputs.version }}  --set image.version=${{ inputs.version }}  ${{ inputs.app_key }} .

This takes the yaml files in the CICD and trues to apply them to kubernetes. the files are available over the multiple steps.

If you realley want the files on the pods, that’s what kubectl cp is for but That should not be needed to apply helm charts.

    steps:
      -
        name: Checkout
        uses: actions/checkout@v3

To move files in and out of a POD i use the following:

      # COPY FILE TO WORKSPACE
      - name: COPY FILE FROM POD TO WORKSPACE
        shell: bash 
        run: |
         kubectl cp -n ${{ inputs.app_key }}-${{ inputs.environment }} ${{ inputs.app_key }}-${{ inputs.environment }}/$POD_NAME:/tmp/${{ inputs.app_key }}-${{ inputs.environment }}-${{ github.run_id }}.sql.gz ${{ github.workspace }}/${{ inputs.app_key }}-${{ inputs.environment }}-${{ github.run_id }}.sql.gz

I would suspect that first a checkout step fetches the helm charts you need and then in a next step your example would suffice.