Comments (11)
Anyone else ahve a comment on this? I have no problem with it.
from containerapplicationgenericlabels.
@riekrh @philips
from containerapplicationgenericlabels.
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.
from containerapplicationgenericlabels.
.
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.
from containerapplicationgenericlabels.
@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.
from containerapplicationgenericlabels.
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.
from containerapplicationgenericlabels.
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.
from containerapplicationgenericlabels.
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.
from containerapplicationgenericlabels.
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.
from containerapplicationgenericlabels.
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.
from containerapplicationgenericlabels.
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.
from containerapplicationgenericlabels.
Related Issues (20)
- Label for Syscall Tables HOT 13
- Use dash case instead of underscore in label names HOT 7
- Reason to have "name" label? HOT 5
- `authoritative_source_url` and `authoritative_source` HOT 4
- Image name that includes string '--' not acceptable in docker 1.8+ HOT 3
- Define a set of Red Hat supported labels
- Proposal: add TEST label HOT 1
- vendor/red hat page is harder to read than top-level (tables) HOT 1
- authoritative-source shouldn't be required for images located on docker hub HOT 1
- What is the right LABEL name for authoritative source? HOT 1
- Proposal: Add a License Label HOT 7
- Add vendor links in the main readme
- Include missing OpenShift labels e.g. wants
- maintainer instruction is deprecated as of docker engine 1.13 HOT 3
- Missing help label description HOT 2
- Describe optional and required environment variables HOT 3
- Why are labels io.k8s.display-name and io.openshift.tags required? HOT 3
- document "usage" label?
- Clarify relation to opencontainers/image-spec
- drop authoritative-source-url label
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from containerapplicationgenericlabels.