Env variables in uses

It would be nice to be able to use enviornmental variables in a uses varaible. This will allow for easy changing of versions for actions such as checkout.

name: svt-av1
on: [push, pull_request]
env:
  checkout: 'actions/checkout@v2

jobs:
  build:
    runs-on: ubuntu-18.04
    steps:
    - uses: ${{ env.checkout }}
      with:
        fetch-depth: 1
1 Like

In order to enact policies like only using actions defined in the org or repo we can’t allow actions to dynamically change at runtime.  So using any sort of dynamic value in uses is not something we will be able to support.

This makes it more work to update multiple jobs to a newer version of an action or even different workflows since you could in theory just have the maintainers put the versions in a github secret and call it on all their workflows and update everything at once though i think its still better to just do it as a global env variable in the script so it is easier to see and modify in pull requests. If you do not thing this is something that will ever be support then i guess we can go ahead and mark this as solved then.

Hi,

On every push, I want to create a release. I can’t figure out how to use the runtime variable $env:NBGV_SimpleVersion there. Any idea? I tried so many version, but no luck.

If I don’t put a version, the step will fail because the tag name will be already exist on the next run.

In that image, I want to replace the HERE_VERSION with $env:NBGV_SimpleVersion which is set by the step aarnott/nbgv@v0.3
Image

Thanks

The counter argument to stability/safety, is that master changes every time there’s a commit. That sounds like a problem to me.

Having a mechanism to centrally control versions for uses seems like it’s a good idea. In fact, my build breaking because terraform actions merged some PR to master was how I found out that I needed to copy paste the string v0.12.4 everywhere. My first thought was to use ${{ env.TERRAFORM_VERSION }} which broke with an obscure error of env not existing. I wasted a good amount of time figuring out why until I finally ended up here because the error was very misleading.

Maybe a better approach is to apply the policy after templating or reconsider how this works (I think it’s weird to have this limitation on a build server where you are running arbitrary tests, docker, bash, etc. anyway).