hub-feedback icon indicating copy to clipboard operation
hub-feedback copied to clipboard

Feature request: Build args on docker hub

Open cusspvz opened this issue 9 years ago • 59 comments

Since we can have ARGS on dockerfile, seems right to have them available on auto-builds as also (for having different tags based on the same Dockerfile)

cusspvz avatar Dec 16 '15 15:12 cusspvz

Together with LABEL, build args is very useful to apply custom metadata to images. For example:

FROM debian:wheezy

ARG branch
LABEL com.example.branch=$branch

Setting --build-arg branch={sourceref} can add the com.example.branch=master label to the image. It would be great if Docker Hub supports more build variables to provide metadata such as build id, git commit hash, creation time etc.

cheungpat avatar Dec 20 '15 10:12 cheungpat

Yes, it would be really useful. +404003

azenla avatar Jan 31 '16 06:01 azenla

I've been thinking the same thing since I started using buildargs. It would be perfect if there was a way to set specific buildargs for specific tags on my dockerhub image, instead of having to create separate tags/branches in my git repo.

andyneff avatar Feb 12 '16 15:02 andyneff

This would be even better than https://github.com/docker/hub-feedback/issues/292

yajo avatar Feb 26 '16 09:02 yajo

@Yajo note that this is regarding access to set --build-args option and not entire docker build cli args.

cusspvz avatar Feb 26 '16 17:02 cusspvz

Yes, I just meant that #292 could cover the same use cases, but fixing this would be much better for most of those.

yajo avatar Feb 26 '16 17:02 yajo

This would make multi-version maintenance of images a lot easier

schickling avatar Mar 30 '16 14:03 schickling

This is available in Docker Cloud, which uses the same backend than Hub for autobuilds. The way to do it is to define autobuild env variables, an write a build hook that does the docker build command with the required build arguments. https://docs.docker.com/docker-cloud/feature-reference/automated-build/ https://docs.docker.com/docker-cloud/feature-reference/automated-testing/

pchico83 avatar Mar 30 '16 15:03 pchico83

Can someone explain the method described by @pchico83? Because the documentation does not mention anything about writing a build hook, only hook/pre_build and hook/post_build as part of testing from what I can tell.

nalipaz avatar May 29 '16 16:05 nalipaz

@nalipaz although it is not documented, it is supported (I will open an issue to improve the documentation). For example, if you define an env var called VAR and you want to set it to a build argument called TEST, you can define a build hook adding a hooks/build file to the dockerfile folder:

.
..
hooks/build
Dockerfile
(other files)

whose content could be:

#!/bin/sh
docker build --build-arg TEST=$VAR -t $IMAGE_NAME .

Note that the hook is executed using the dockerfile folder as working dir, and $IMAGE_NAME is a variable we inject that corresponds with the docker tag being pushed.

pchico83 avatar May 30 '16 16:05 pchico83

That is much clearer, thanks @pchico83, and yes it would be very helpful to many I am sure were it documented. Thanks.

nalipaz avatar May 30 '16 16:05 nalipaz

@pchico83, @nalipaz , Can you please provide me an example of how this hooks is used? Do we use the same docker file commands? I tried with an example of setting an environment variable, which I later want to refer to in the Dockerfile, but it throws error

For example, in hooks/post_checkout, I added

ENV UI_BUILD x-1.2.2

But this throws me the following log. "Executing post_checkout hook... Unexpected error" Can you please throw some lights on this? Any help is appreciated.

Gurubol avatar Aug 12 '16 18:08 Gurubol

Yeah, a gist or example project would likely be helpful for this. I will see if I can find time to test and make one although I am not using this feature currently. I opted for using Travis CI to use a make file to pass in params to the build and then push the final image into docker hub.

nalipaz avatar Aug 12 '16 19:08 nalipaz

@Gurubol You are probably missing the bash shebang at the beginning of your hook. This is an example project with hooks: https://github.com/docker/dockercloud-events

pchico83 avatar Aug 17 '16 12:08 pchico83

Thanks to @pchico83 guidance, I was able to look around and discovered a number of useful pieces of information

  1. The docker image used in docker hub to build dockers is called docker/highland_builder
  2. The majority of the hidden hooks features are come from the builder.py
  3. Here is a simple hooks example
  4. There are a number of key environment arguments set upon launching a build script, all of which you can use in your hooks.
BUILD_PATH=/
MAX_LOG_SIZE=67108864
SOURCE_BRANCH=master
DOCKER_REPO=index.docker.io/andyneff/docker_hook_test
DOCKERCFG=REDACTED
LOGS_POST_SPEC=REDACTED
BUILD_CODE=b9manhaqhfyqtmdqupcjyuq
README_POST_SPEC=REDACTED
SOURCE_TYPE=git
DOCKER_HOST=unix:///var/run/docker.sock
DOCKERFILE_POST_SPEC=REDACTED
DOCKER_TAG=latest
PUSH=true
PYTHONUNBUFFERED=1
SOURCE_URL=https://github.com/andyneff/docker_hook_test.git
DOCKERFILE_PATH=
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DOCKER_VERSION=1.11.2
COMPOSE_VERSION=1.7.1

Redacted fields contained what looked like keys I assume would be harmless and expired by now, but I'm not sure ;)

But the take away is also have access to SOURCE_BRANCH and DOCKER_TAG, in addition to IMAGE_NAME, GIT_SHA1, GIT_MSG, and COMMIT_MSG, which can all be useful in making custom build-args :)

Hope this helps with this pretty awesome undocumented feature!

andyneff avatar Aug 18 '16 03:08 andyneff

Here is a test image I use to check which hook are triggered when and which variables are available : https://github.com/thibaultdelor/testAutobuildHooks

Check the result of the build here : https://hub.docker.com/r/thibaultdelor/testautobuildhooks/builds/

t-botz avatar Sep 01 '16 03:09 t-botz

I really need this. I have multiple Dockerfiles because I have multiple distros to support, so they're each in their own folder, meaning they don't have the whole repo in their context, so the repo is cloned during docker build and I just need to be able to pass ⁠⁠⁠⁠--build-arg branch=$(git rev-parse HEAD) in the automated build so that I can checkout the right commit. Argh.

andyleejordan avatar Oct 17 '16 21:10 andyleejordan

@andschwa I prefer to have multiple named Dockerfiles in the root of the repo and then just run docker build -f myrepo.Dockerfile and not need to copy the repo. Either way, you can achieve this using my post above. See here for a full example when we are doing almost exactly what you are referring to. Just customize the hooks/build to your hearts content. Hope this helps

andyneff avatar Oct 17 '16 21:10 andyneff

need this feature for the automatically build, would be really nice.

huan avatar Nov 02 '16 17:11 huan

I'm in the same boat as @andschwa, we have build profiles and need to steer this via the code commit. Ideally, we'd love to get all the meta data surrounding the github/bitbucket webhook posted to us in environment variables or (better yet) buildargs! That way we can decide how to customise the build process per automated build.

tommed avatar Mar 03 '17 18:03 tommed

Something I forgot to mention earlier, but because of this line, a Dockerfile MUST exist at the "Dockerfile Location" column in the "Build settings".

So if you are using a filename other than ./Dockerfile, even though your hook will know what to do, the build script will erroneously fail. You must either:

  • Have "Dockerfile Location" point to a directory in the git repo containing a file named Dockerfile
  • Have "Dockerfile Location" point to a file in the git repo that will exist
  • Create a dummy Dockerfile (this is the least ideal solution for me)

Also, don't forget to give your hooks/* files 755 permissions.

Update

Your hooks directory must be in the "Dockerfile Location" directory

andyneff avatar Jun 26 '17 17:06 andyneff

Really need this feature to avoid having a ton a dockerfiles to produce similar images. +1

gbolo avatar Sep 28 '17 04:09 gbolo

Nearly 2 years since this was originally requested. It would make life so much easier if this was possible. A definite +1 for me.

ju5t avatar Oct 14 '17 19:10 ju5t

It would be clearly convenient if no hooks are needed and just clearly set the environment variable. With the DockerCloud UI, it really is hard to tell if hooks are needed and first impression would be just setting in the ENVIRONMENT VARIABLES on the CONFIGURE AUTOMATED BUILDS page will be enough to act as build arguments

Dean-Christian-Armada avatar Nov 17 '17 04:11 Dean-Christian-Armada

ARG with default value seems ok then? just no way to change them as I understand from this?

felixcheung avatar Jan 11 '18 06:01 felixcheung

I think the idea is you'd be able to set via webhook to override those set in the Dockerfile

geekgonecrazy avatar Jan 19 '18 06:01 geekgonecrazy

Is there any chance that this request will be realized? I am still waiting to access SOURCE_BRANCH as variable without explicitely setting it!

col-panic avatar Mar 20 '18 07:03 col-panic

@col-panic SOURCE_BRANCH is there https://docs.docker.com/docker-cloud/builds/advanced/

alexeyzimarev avatar Mar 21 '18 08:03 alexeyzimarev

@alexeyzimarev Are those available in Docker Hub as well?

mitar avatar Mar 21 '18 08:03 mitar

I'm using SOURCE_BRANCH variable in hooks/post_checkout script on Docker Hub's automated build as https://hub.docker.com/r/norionomura/swiftlint/.

norio-nomura avatar Mar 21 '18 08:03 norio-nomura