[Feature Request] Build args support in Docker container actions

[yoannchaudet]

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

[MChevy422]

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

[collinkleest]

@MChevy422 has there been any updates on this, I know this is old. A lot of developers would use this.

[BobbyMcWho]

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.

[dgw]

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!

[jdolitsky]

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.

[JavierZolotarchuk]

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

[JavierZolotarchuk]

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

[fcano-ut]

This seems like a waste of resources. You need to install docker inside a docker container, just to be able to pass build args.
Also, ideally I'd expect GitHub to be able to "cache" the built image somehow instead of building from scratch every time the action is used. But in this approach, the image needs to be built every time.

Not trying to undermine your solution (I'm quite grateful that there's a workaround actually) but just saying that this is just a "patch" until we have feature support.

[adamjakab]

As @JavierZolotarchuk says. this is a workaround and not a solution / answer.
Marking this as the answer 4 years ago achieved only one thing... that nobody is looking at this because this is a thread with an answer. Pls remove the "answered" tag.

[mmailhos]

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.

[w9jds]

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.

[aaronzs]

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

[nemith]

docker run is unfortunate if you rely on on any environment variables as you have to whitelist everone of them with -e or do some hackery with .env files.

[zmingxie]

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.

[bmacnaughton]

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:

• it will not have the GITHUB_WORKSPACE or any of the other directories mapped
• final container will not have all the GITHUB environment variables
• you’ll have to manually pass arguments from one entrypoint.sh to the other

you can manually map the various directories and pass env vars.

[bmacnaughton]

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.

[mvarrieur]

Also ran into this today, the workarounds don’t work for my use case so we are stuck unfortunately.

[clarencedesmarais]

Ran into this issue today. Was wondering how to actually pass ARG in my docker container. Any updates on this ?

[tmtenbrink]

This would be really helpful, especially if it also allows passing --cache-to and --cache-from arguments.

[set-soft]

I tried manually mapping directories and it doesn’t work.
I can’t pass data from the intermediate container to the second one.
Mapped volumes aren’t visible and any data I write in new volumes just disapear as soon as the second contianer finishes.
Any idea?

[nishit130]

Hey, any update on the feature request? Would love to see it. I have the exact same use case as mentioned by op. I want to install a dependency inside Dockerfile which needs to have dynamic version (i.e version to be picked up by env).

[ccfontes]

This looks to me more like a bug than a feature request.

[madhums]

Any update on this? This is much needed!

[gabrielrufino]

Up

[zachspar]

Would love to see this feature.

[MarwaOuledElHadjAli]

Any updated on this feature request please ?
The issue was marked as answered but it wasn't the case