Repository navigation
Proposal: add a Build label #20
Description
I would like to propose a Build label that contains a hint how to build the docker image. This label will carry some free text.
Example:
# Dockerfile
LABEL Build docker build --rm --tag myimage .
and a bash alias docker-build='$(grep LABEL Dockerfile | grep Build | cut -d " " -f 3- )'
Activity
rhatdan commentedon Jun 17, 2015
Anyone else ahve a comment on this? I have no problem with it.
rhatdan commentedon Jun 17, 2015
@riekrh @philips
philips commentedon Jun 18, 2015
I don't understand the value. For example where is the build executed? e.g. what is "." in the above example.
Likely we should prefix this stuff with docker.io/build or something too.
goern commentedon Jun 18, 2015
.is the current working directory...the value might be a rather personal, I have lots of containers that I need to build and dont have a makefile or dont use hub.docker.io for. using something like https://github.com/DBuildService/dock feels oversized.
rhatdan commentedon Jun 19, 2015
@philips I think @goern is after how what the image built. So using other syntax besides docker would be fine, it could have the syntax used to build a rocket image, or new ways we are looking to build container images.
But I am not sure how much value this has since you would not necessarily have all of the build artefacts to tell a user how he could build it.
philips commentedon Jun 19, 2015
Right, that is what I am getting at, you have the command but zero context of the working directory it was executed in, so it is pretty light on utility.
cgwalters commentedon Jun 19, 2015
Maybe
build_system_versioninjected by the system? E.g.:That'd be really useful to know in a lot of cases.
I feel like as for handling the actual build, it should be up to the build system to choose whether or not to inject the metadata/scripts/artifacts into the actual image.
cgwalters commentedon Jun 19, 2015
For example, the Fedora/CentOS/Red Hat base images are generated by ImageFactory, and the kickstart file used is stored in
/root/anaconda-ks.cfgas a side effect.Zyzyx commentedon Jul 13, 2015
I agree with Colin and Brandon here. A build system can drop the dockerfile (or whatever) into the image and that should be sufficient.
The build_system_version label is an interesting idea, but ideally it's something we should never need if image build system are producing content to spec. A brief history lesson here: CentOS used to look at the build host string in RPMs before Red Hat used Koji. The reason was because builders back then were quirky and not consistent, so when they attempted to rebuild, they would customize the environment based on the build host string.
I see parallels here. These days the value of the label isn't all that useful now that the rpm build systems we have are fairly mature.
cgwalters commentedon Jul 13, 2015
What I was thinking of is a two level process -
build_system_versiotells you which build system produced the image, and then you say: Ok for ImageFactory, their website tells me to look in /root/anaconda-ks.cfg. For the Docker Hub, their website says I can go to the images' website on the Hub. For Dock, the Dockerfile is injected into /root, etc.Zyzyx commentedon Jul 13, 2015
Right, we have several build systems and no spec. Content is slightly different depending on how it is manufactured. I don't doubt build_system_version's usefulness today, but I wanted to point out that over time, it diminishes if we're doing things right.