Using set-env I was able to achieve the desired result.

On Windows, VS related environment variables are set by a third-party batch script, so I had to add them with set-env manually after calling the batch script. Instead of filtering the relevant environment variables, I just make every environment variable global using set-env. The script can be found here.

Thanks for creating that script.  I would be a little careful with that script as you are stomping on PATH rather an updating it with append-path.  In most cases it probably won’t be an issue but you never know. 

I’ve been going round in cycles with this as I had my set-env like

::set-env VERSION=0.0.21-preview

Which looks like it’s working but it needs to be

::set-env name=VERSION::0.0.21-preview

Link has moved to:

https://help.github.com/en/actions/reference/workflow-commands-for-github-actions#setting-an-environment-variable

How do I actually use these variables?

I’m setting a variable like this in a script:

echo "::set-env name=app_version::$version"

And trying to use it in my workflow:

    - name: Upload Artifacts
      uses: actions/upload-artifact@v2
      with:
        name: app-${{ app_version }}
        path: ${{ github.workspace }}/path-to-upload

But before my action runs I get this error:

Invalid workflow file
The workflow is not valid. .github/workflows/publish.yml (Line: 55, Col: 15): Unrecognized named-value: 'app_version'.

I have tried initialising it at both the job and workflow level like below but I still get the same error:

env:
   app_version: 0.0.0

The set-env command sets an environment variable, so you have to access it via the env context:

      with:
        name: app-${{ env.app_version }}

When inside a run command or some called program use whatever means the programming language offers to access environment variables, e.g. "${app_version}" in bash.

This method was deprecated due to a security vulnerability please see Support saving environment variables between steps for the new method.

It’s also possible to use job-scoped environment variables, no? See this link: https://kevsoft.net/2020/04/25/creating-a-job-scoped-computed-environment-variable-in-github-actions.html

for example:

name: Example Workflow
on: [push]
jobs:

example-job:

name: An example job

runs-on: ubuntu-latest

env:

MY_COMMON_ENV: 'XYZ'

steps:

- name: step 1

run: echo $MY_COMMON_ENV

- name: step 2

run: echo $MY_COMMON_ENV

...

Yes, but if you need to set an environment variable dynamically in a step, then you need to use environment files.