Workflow level `env` does not work properly in all fields.

Describe the bug When using workflow level environment variables they do not work when I use them to substitute for jobs.build.name or jobs.build.runs-on. See workflow file below for example:

name: Testing workflow leve env vars
on:
  push:
    branches:
      - develop

env:
  aws_account: cfaittoolsnp
  environment: dev

jobs:
  build:
    name: Deploy|${{ env.aws_account }}
    runs-on: ${{ env.aws_account }}
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - name: Init
      run: |
        echo ${{ env.aws_account }}

To Reproduce Steps to reproduce the behavior: 1.- Run the workflow file above to receive the following error: The workflow is not valid. .github/workflows/dev.yml (Line: 15, Col: 11): Unrecognized named-value: 'env'. Located at position 1 within expression: env.aws_account,.github/workflows/dev.yml (Line: 16, Col: 14): Unrecognized named-value: 'env'. Located at position 1 within expression: env.aws_account

Expected behavior The expected behavior is that using the workflow file above the build.name would be Deploy|cfaittoolsnp and the build.runs-on would be cfaittoolsnp.

Runner Version and Platform

Running latest version of linux self-hosted runner.

OS of the machine running the runner? linux (ubuntu 18.04)

[tjcorr]

This is also an issue with reusable workflow. For example:

env:
  DOTNET_VERSION: 5.0.x    

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  call-workflow-passing-data:
      uses: ....reusable.yml@main
      with:
          dotnetversion: ${{ env.DOTNET_VERSION }}`

Does not work.

[xor-freenet]

@restjohn wrote:

The concept to realize, I think, is that the intent of environment variables is for them to be available in the context that a job step is executing, not in the context of DEFINING a job, which is basically the context of the GitHub Actions platform itself. […] Now, there might be potential for a less cumbersome solution than having to use outputs and needs references, such as user-defined variables and functions that can augment the job definition context, but env is certainly not the correct place for that.

Thanks for your input 😃

It may be true that that is how the implementation is implemented and intended currently (or not true, who knows?)

But: The sole purpose of an implementation of software is to serve the users needs, it has no purpose of its own.

Therefore, if it cannot serve the needs of the users, it has to change.

It should not be the other way around, the users should not be asked to change their needs to follow the needs of the implementation 😃