image source repository and related metadata

[jmtd]

Hi, I wonder if there is any interest in labelling images with metadata relating to the source code repository from which it was built. Since with docker images the Dockerfile is only one piece of the puzzle (and other scripts or artifacts might be ADDed in, RUN, etc.) and typically these are collected together in a version control repository, to find out precisely what was used to build an image, one may need to refer to the repository and to a specific commit within.

So it might be useful to label with at least the commit-id, but probably also a repository URL, and if it can't be inferred from the URL, a repository type.

[jonboulle]

FWIW, we do something similar in goaci, for now just extracting the VCS information/hash and adding that as a label (e.g. "git": "abcdefghi") to the resulting ACI: https://github.com/appc/goaci/blob/master/vcs.go#L104

Would be great if we could standardise on a format here.

R.I.Pineear has a nice blog post (partially) about this. I like the idea of repository and build metadata embedded in the image.

I think both docker and the ACI spec only allow string values, but the docker documentation shows an example with a JSON blob, represented as a string. Not sure if this is a good idea.

By the way, @jonboulle, the code you linked to references image "labels" although the spec says they should only be used for image discovery and dependency, and "annotations" should be used instead. It's a bit confusing :)

[rhatdan]

I would think url would make the most sense here. What Name would you want for this?

[smarterclayton]

Yeah, let's standardize. OpenShift is going to be writing and reading those, so we're happy to swap to read whatever the standard becomes.

[philips]

Perhaps we steal from Debian? https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields

An example would be:

vcs-git: https://github.com/projectatomic/ContainerApplicationGenericLabels -b foobar

[TomasTomecek]

@philips

I feel like if we should agree on something, it shouldn't require post processing to get all the information; therefore I'm in favor of adding another field for ref

vcs-git-url: https://github.com/projectatomic/ContainerApplicationGenericLabels
vcs-git-ref: master

vcs-git-ref: pr/314

vcs-git-ref: 4c16021fff38ee11838cb0769010a7ed4ebf3b90

or maybe having it even more generic:

vcs-type: git
vcs-url: http://...
vcs-ref: ...

[jmtd]

@philips You've beaten me to it, I was going to suggest exactly that :)

There are a few variations I think worth considering. First, should this leave open support for VCS other than git? I guess probably. So one label should probably be what VCS is being used. You can't always infer this from the URL (https://example.org/somepath/ could be git, or svn, or..)

Secondly, the '-b foo' suffix on the URL is a wart IMHO. I can't remember exactly when it came in, but it was an afterthought. I would prefer a different label, that could be overloaded for different VCS types. "thing to check-out from the source repo". With git, it would be a post-clone checkout. With svn, it might be a fragment to append to the check-out command. Examples

vcs-type: git
vcs-url: http://example.org/repo
vcs-commit: abc1234def
...
vcs-type: svn
vcs-url: http://example.org/repo
vcs-commit: /branches/foo-branch

[jmtd]

@TomasTomecek we seem to agree :) I prefer your vcs-ref though. I'll work up a PR for discussion!

[goldmann]

+1

[rhatdan]

Since this is merged I can close this issue.