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]
  checkout: 'actions/checkout@v2

    runs-on: ubuntu-18.04
    - uses: ${{ env.checkout }}
        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.

1 Like

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.


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


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).


Is there any work being done on this at the moment?

I am working exclusively with docker in my WFs and it is almost impossible to test any image built in a WF. Since services, steps, etc cannot use images defined dynamically, I am forced to use docker run directly in my steps.

In my opinion the safety argument doesn’t hold here since I have to implement my own docker run action in order to start my containers with the right image. There is no way that some random shell script written by an average Joe like me is safer than the services and docker jobs written by knowledgeable people a GH!

Surely, you could allow variables in the version (or tag?) part of uses and still maintain this property?

As far as I can tell, this is blocking testing actions:

    name: "Test"
    runs-on: ${{ matrix.os }}
          - 'ubuntu-latest'
          - 'macos-latest'
      - name: Run this action!
        uses: me/this-repo@${{ github.sha }}

Right. Quite often, Github Actions don’t let me do something nicely that I then have little issue reproducing in a script. Most recent example: no if in composite action steps, so …