hub-feedback
hub-feedback copied to clipboard
Feature request: Build args on docker hub
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)
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.
Yes, it would be really useful. +404003
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.
This would be even better than https://github.com/docker/hub-feedback/issues/292
@Yajo note that this is regarding access to set --build-args
option and not entire docker build
cli args.
Yes, I just meant that #292 could cover the same use cases, but fixing this would be much better for most of those.
This would make multi-version maintenance of images a lot easier
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/
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 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.
That is much clearer, thanks @pchico83, and yes it would be very helpful to many I am sure were it documented. Thanks.
@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.
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.
@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
Thanks to @pchico83 guidance, I was able to look around and discovered a number of useful pieces of information
- The docker image used in docker hub to build dockers is called docker/highland_builder
- The majority of the hidden hooks features are come from the builder.py
- Here is a simple hooks example
- 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!
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/
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.
@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
need this feature for the automatically build, would be really nice.
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.
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
Really need this feature to avoid having a ton a dockerfiles to produce similar images. +1
Nearly 2 years since this was originally requested. It would make life so much easier if this was possible. A definite +1 for me.
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
ARG with default value seems ok then? just no way to change them as I understand from this?
I think the idea is you'd be able to set via webhook to override those set in the Dockerfile
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 SOURCE_BRANCH
is there https://docs.docker.com/docker-cloud/builds/advanced/
@alexeyzimarev Are those available in Docker Hub as well?
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/.