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

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

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:

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

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!

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 …

image945×362 38.2 KB

This is also something I'm interested in, and from the other responses, it doesn't sound like the "for security" argument holds much water

I wanted to accomplish this that sounds super intuitive to me, but sadly I couldn't:

jobs:
  test:
    name: Sample
    runs-on: self-hosted
    steps:
      - name: Prepare docker full name
        run: echo "DOCKER_TAG=docker://docker-registry.url/project:${{ github.ref_name }}" >> $GITHUB_ENV
      - name: Show docker tag
        run: echo ${DOCKER_TAG}
      - uses: actions/checkout@v3
        name: Standard Checkout
      - uses: "${DOCKER_TAG}"
        name: Run

We are building docker images for branches in some specific cases that we would like to use later to run tests on, but I guess it won't be a possibility in the current state of things.

Small update on my issue:

I was able to circumvent the limitation by doing this in my case:

- name: Set docker tag
  run: |
    echo "DOCKER_TAG=docker-registry.url/project:${{ github.ref_name }}" >> $GITHUB_ENV
    echo ${DOCKER_TAG}
- uses: actions/checkout@v3
  name: Standard Checkout
  with:
    ref: ${{ github.ref_name }}
- uses: webfactory/ssh-agent@v0.7.0
  with:
    ssh-private-key: "${{ secrets.SSH_KEY }}"
- name: Run Tests
  env:
    ENV_TAGS: "${{ github.event.inputs.testParam }}"
  run: |
    docker pull ${{ env.DOCKER_TAG }}
    docker run --name bla -e ENV_TAGS=${ENV_TAGS} ${{ env.DOCKER_TAG }}
- name: Export target folder
        if: always()
        run: |
          docker cp bla:target/ .

This allows me to:

1. Compose the url required for the docker pull command including the project name and the branch-related tag
2. Check out the corresponding branch with the changes
3. Setup ssh-agent with the Org's ssh key to perform the docker commands
4. Do the docker run with the necessary parameters and pointing to the proper branch-related tag
5. Collect the results from the docker run with the docker cp so I can use it further for reporting on the github action

Seems to have worked for me. Would have been a lot easier with the uses: ${env.VAR} but the above unblocked me.