ContainerApplicationGenericLabels
ContainerApplicationGenericLabels copied to clipboard
projectatomic
Proposal: add a Build label
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- )'
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.
. 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.
@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.
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.
Maybe build_system_version injected by the system? E.g.:
LABEL build_system_version DBuildService/dock 0.7.3
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.
For example, the Fedora/CentOS/Red Hat base images are generated by ImageFactory, and the kickstart file used is stored in /root/anaconda-ks.cfg as a side effect.
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.
What I was thinking of is a two level process - build_system_versio tells 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.
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.