Expression parsing in 'runs.image' yaml value.

[jbvirt]

I am running on GitHub Enterprise Server 3.3.6 and have run into a bit of a snag when creating a docker action.

Essentially, I would like to be able to dynamically pull a different base image depending on what inputs are passed in but unfortunately it seems that expressions in the runs.image yaml value are not expanded.
Here is an example:

name: test
inputs:
  container: 
    description: "Container to use as a base."
    required: true
    default: mycontainer/my-image-with-version
runs:
  using: docker
  image: docker://${{ inputs.container }}

Unfortunately, this results in docker trying to pull the image docker://${{ inputs.container }}, and failing. Using environment variables does not work either.

This seems like a massive limitation on the flexibility of Docker actions.
Is the functionality I need present on the latest version of GHES?
Is there a way to work around this?

There is no way to pass build-arg's into a Dockerfile either, so that won't work either.

[jbvirt]

I was able to work-around this issue by wrapping my test action in a separate composite action which pulled the desired image and tagged it to a hard-coded tag used by the test action. It's certainly not an ideal solution, and will not work in parallel with different images, but it works.

[jbvirt]

Another update: A composite action actually does not work optimally, as an error will be thrown if the image does not exist at the start of the run. The solution to this is to pull & tag the image in a separate, precursor, job.

[airtower-luna]

The solution to this is to pull & tag the image in a separate, precursor, job.

That will only work if both jobs run on the same self-hosted runner. GitHub hosted runners are discarded after each job. And if you have multiple self-hosted runners a different one might pick up the second job, and then you get a different image than expected, or maybe it's missing anyway.

How about calling docker run with the desired image in the composite action instead of using a Docker action?

[jbvirt]

Thanks for the response, that’s a good point.
The problem with using Docker run is that I need to ensure that the workspace is passed in as expected.

I am developing using act for rapidly testing changes locally, a self hosted runner hosted on my development machine with docker, and the production machine hosted on an EC2 instance.

The issue with both act as well as self hosted runner in docker is I can’t pass in the local workspace because it will look for the path on the host machine, not the container. (as expected, when using Docker in Docker).

The docker action seems to get around this issue and sets the volume and workspace appropriately, no matter if it is running on docker in docker or not.

The issue that I am unsure which context variables to use in order to replicate the same behavior. Passing in the workspace variable as a volume does not behave the same in the three different environments.

[airtower-luna]

The issue that I am unsure which context variables to use in order to replicate the same behavior. Passing in the workspace variable as a volume does not behave the same in the three different environments.

You can see the exact docker run command used to run a Docker action in the log, like here. It's a pretty long list of environment variables and volumes. 😅 I wouldn't recommend trying to replicate it exactly (because it's a lot of effort and might change), rather check what the container you want to run actually needs.

If the list of versions you want to support is limited you could also take another approach: Make a composite action with a uses steps for each version and an if condition to check if that particular version should run. Lots of boilerplate code, but it would work.

[jbvirt]

Thanks again for the response.
My question specifically is are these paths used to mount volumes exposed in context variables and, if so, which context variables are they?

-v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/hello-github-actions/hello-github-actions":"/github/workspace"

The first three look like they could be hard-coded if need be, but the last one is more difficult as it looks like it uses ${{ github.workspace }} which I've had issues reliably using with act (since it seems to treat Docker actions differently in that it copies the workspace instead of mounts it?).

The irony is that my first approach of using a composite action wrapper works just fine in act, but not in the actual runners. I don't suppose there's a way to make GitHub Actions delay the pulling/building of the needed docker images until they ae actually used?

[jbvirt]

Ok, ultimately, I was able to work around my problem by having the test action pull from an existing container (such as image: docker://nginx:latest or a self-hosted container, but NOT a Dockerfile) and then using a wrapping composite action to overwrite the tag. This seems to work on all my test environments.