Home > database >  Evaluating environment variables in github actions workflow
Evaluating environment variables in github actions workflow

Time:07-06

I'm positive that this is something easy but I'm not able to track down exactly what I'm looking for. I have a workflow that performs a build and creates an artifact. The artifact uses an environment variable in the filename. So far so good. Then when I try to pass this file name to S3 upload action, it isn't found because the environment variable isn't evaluated. Here is the relevant part of my workflow:

  - name: Build project
    run: ./build_project.sh

  - run: ls -l "${GITHUB_WORKSPACE}/build/${FILE_NAME}.zip" # file exists in directory
  - run: echo "${GITHUB_WORKSPACE}/build/${FILE_NAME}.zip" # echo returns the location properly

  - uses: hkusu/s3-upload-action@v2
    id: upload # specify some ID for use in subsequent steps
    with:
      aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
      aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
      aws-region: "eu-west-2"
      aws-bucket: ${{ secrets.AWS_BUCKET }}
      file-path: "${GITHUB_WORKSPACE}/build/${FILE_NAME}.zip" # Error: file does not exist
      output-file-url: "true" # specify true
  - name: Show URL
    run: echo '${{ steps.upload.outputs.file-url }}' # use this output

My actual question is how to replace "${GITHUB_WORKSPACE}/build/${FILE_NAME}.zip" with the file path and name when it actually runs the workflow. Also, I have tried a few of different combinations of things - no quotes, no curly braces, neither, both.

CodePudding user response:

Since these parameters are passed through to the s3-upload-action, the behaviour depends on whether the action expands shell parameters or not, but the input value will be literally

${GITHUB_WORKSPACE}/build/${FILE_NAME}.zip

i.e., unexpanded.

You can use expressions to work around this:

      file-path: ${{ github.workspace }}/build/${{ env.FILE_NAME }}.zip

You maybe have assumed that environment variables expand everywhere as they do when evaluated by a shell, such as in a run: step, but they don't.

  • Related