Unless I missed it, it does not seem possible today to specify Docker build arguments (i.e. arguments passed when building an action’s container.
Being able to specify a “build-args” section in an action metadata file would be nice.
Potential scenario: specify the tag of base image with a variable (whose value would be defined in the action metadata file and potentially controlled by inputs or environment variables).
Hello @yoannchaudet,
Thank you for your feedback! We’re always working to improve GitHub and the GitHub Community Forum, and we consider every suggestion we receive. I’ve logged your feature request in our internal feature request list. Though I can’t guarantee anything or share a timeline for this, I can tell you that it’s been shared with the appropriate teams for consideration.
Once again, thank you for your input!
Greatly appreciated
MChevy422
Yes, PLEASE! This is a blocker for something I want to do in an action, and it’s tough to find a non-hacky feeling solution.
Hi @mchevy422,
Please tally an extra vote for this feature on my behalf!
For further context, I came across this thread while searching for a way to let the action user select what version of the base image to use for a Docker action. That is, it would default to the base image’s “latest” tag, but something like this step in a job would select a different version tag and build the action using that instead:
- name: Run my-action with custom base image version
uses: dgw/my-action@v1
with:
base: 1.2.8
And base could be passed back to the Dockerfile build via (for example):
inputs:
base:
description: 'Base Docker image version to use'
required: true
default: latest
(Could also add a new field to with, but to me it makes more sense that the version would be an input.)
Thanks!
Specifically, I’d like to see the build arg to have access to the git commit of the source repo, for example
runs:
using: 'docker'
image: 'Dockerfile'
build-args:
- name: VERSION
value: ${{ thisrepo.gitcommit }}
Especially when building off of somebody’s “@master” version of the action, would be nice to know the git commit that built it.
A work around until the feature is implemented is that we use the docker image that creates the action as handrails to create the image that we really want with all the arguments we need.
Basically what we have to do is create a docker image in the entrypoint.sh and run it.
entrypoint.sh example:
#!/bin/sh -l
ALPINE_VERSION=$1
cd docker-action
echo "creating docker image with alpine version: $ALPINE_VERSION"
# here we can make the construction of the image as customizable as we need
# and if we need parameterizable values it is a matter of sending them as inputs
docker build -t docker-action --build-arg alpine_version="$ALPINE_VERSION" . && docker run docker-action
For the entrypoint.sh to work correctly it is necessary that the necessary dependencies are installed on the main image to be able to use docker ( I recommend that the main image be an alpine so that it is as light as possible ).
NOTE: By main image I mean the image resulting from built the DockerFile referenced in the action.yml file.
Here is a simple example of how to do it.
https://github.com/JavierZolotarchuk/parameterizable-docker-action-example
A work around until the feature is implemented is that we use the docker image that creates the action as handrails to create the image that we really want with all the arguments we need.
Basically what we have to do is create a docker image in the entrypoint.sh and run it.
entrypoint.sh example:
#!/bin/sh -l
ALPINE_VERSION=$1
cd docker-action
echo "creating docker image with alpine version: $ALPINE_VERSION"
# here we can make the construction of the image as customizable as we need
# and if we need parameterizable values it is a matter of sending them as inputs
docker build -t docker-action --build-arg alpine_version="$ALPINE_VERSION" . && docker run docker-action
For the entrypoint.sh to work correctly it is necessary that the necessary dependencies are installed on the main image to be able to use docker ( I recommend that the main image be an alpine so that it is as light as possible ).
NOTE: By main image I mean the image resulting from built the DockerFile referenced in the action.yml file.
Here is a simple example of how to do it.
https://github.com/JavierZolotarchuk/parameterizable-docker-action-example
This is needed.
Use case: run some code analysis (or any language specific tools) with the same Docker image version as the language version used in the repo (such as running FROM golang:1.13.2 in a repo using Go 1.13.2). The only way to do this is to pass the docker image tag from the Action input to the build-arg.
I would like to see this as well. In my actions firebase-actions a common request is to allow you to run the emulator, as select the node version (as functions requires a very specific version). For the emulator I would like to avoid including the JDK unless absolutely needed as it will increase build times quite a bit. I need the build-args to allow me to provide them the ability to flag for emulation (install the JDK) and set the version of node they would like the container to use.
I’d like to see this feature as well. My current solution is using composite.
runs:
using: 'composite'
steps:
- id: build
run: docker build . <build-args> -t image:tag
shell: bash
- id: run
run: docker run --rm -v $(pwd):/github/workspace --workdir /github/workspace image:tag
shell: bash
Thanks for the suggestion from @javierzolotarchuk
I managed to get my GitHub action updated with an optional build version argument using the suggestion: https://github.com/zmingxie/packer-ami-builder
However, this approach causes one side-effect which we won’t be able to live tail the build log within the GitHub Action web console. Logs will only be accessible after the build is completed.
Really hope GitHub will add this feature soon.
thanks for this nice workaround. it solved my issue though a github actions solution would not require the intermediate container (as you know) and would be much cleaner. things people should be aware of:
you can manually map the various directories and pass env vars.
i originally tried to solve this with a slightly different approach, using
runs:
using: 'docker'
image: '${{matrix.os-version}}.Dockerfile'
but that syntax is not accepted. it’s a bit of a mystery to me just where interpolation is allowed and where it is not allowed. ultimately, i ended up using javierzolotarchuk’s solution.
Also ran into this today, the workarounds don’t work for my use case so we are stuck unfortunately.