Add support for --build-arg in Docker-based Action

[nmontmarquette]

I have what I believe to be a minor issue that's forcing me into a disproportional detour.
I want to be able to specify the Docker base image based on a workflow user input. The idea being to save a bit of runtime starting with know Python-good image and not having to start any lower and install a specific Python on top of a lower level, more generic image.

Normally, I'd simply have a Dockerfile that uses an ARG statement and then I'd use the docker build command with the --build-arg parameter. The Docker build would then create a varying image based on the supplied parameter or simply use 3.9 as default if none was supplied.

ARG DOCKER_PYTHON_VERSION=3.9
FROM python:$DOCKER_PYTHON_VERSION
...

docker build --file ./action-pipenv/Dockerfile  --build-arg DOCKER_PYTHON_VERSION=${PIPENV_PYTHON_VERSION} ./action-pipenv

The current Docker Action is unfortunately not supporting either:
a) The docker build --build-arg parameter
b) An indirect value for the Docker Action image field. I haven't looked thoroughly through the runner code yet, but from experimentation it looks like only a static value is allowed. I can use a variable in the args sub-field, but I cannot use a variable in the image field. Note, the args field is meant to be used in docker run not in docker build.

...

inputs:
  pipenv-command:
    description: "The full pipenv command to be executed"
    required: true
  pipenv-python-version:
    description: "The specific Python version to use, else latest will be used"
    required: false
    default: "3.8"

...

runs:
  using: "docker"
  #image: "docker://python:{{ inputs.pipenv-python-version }}"  # Github Actions won't see `inputs` or `github.inputs` 
  image: "docker://python:3.8"
  args:
    - ${{ inputs.pipenv-command }}  # In this case the `inputs` variable works as expected

Because the docker route is a dead-end for me, I'd have to go composite route duplicating most everything the Docker action does for what I believe is a minor issue :-( Alternatively, not as elegant, the ability to have a dynamic image field could be of some help.

Any suggestion?

[henrygriffiths]

Hi @nmontmarquette,

I've run into this same issue when using the docker action, and ended up just using the docker command within a basic run steps to login to a registry, build, and push.

steps:
- run: echo "${{ secrets.BOT_PAT }}" | docker login ghcr.io -u ${{ env.BOT_USERNAME }} --password-stdin
- run: docker build --file ./action-pipenv/Dockerfile --tag ghcr.io/org/name:version  --build-arg DOCKER_PYTHON_VERSION=${{ inputs.pipenv-python-version }} ./action-pipenv
- run: docker push ghcr.io/org/name:version

Hopefully this helps 😄

[nmontmarquette]

Thanks, I did ended up dropping the idea of creating a dedicated Github Actions in favour of running the commands directly in the workflow file. The alternate was to convoluted for the little it actually did :-)

[hpedrorodrigues]

This is a totally different use case, but it is one that could benefit from this same change: gruntwork-io/terragrunt-action#74

[OR13]

Would be nice to be able to specify a build arg here:

runs:
  using: 'docker'
  image: 'Dockerfile'
  args:
    - ${{ inputs.name }}

https://docs.github.com/en/actions/sharing-automations/creating-actions/creating-a-docker-container-action

or perhaps an example that uses a private ghcr image that is built with build args in a different step.