Open imjasonh opened 4 years ago
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen
. Mark the issue as
fresh by adding the comment /remove-lifecycle stale
.
The go version used to build the binary layer
This seems uncontroversial. The go version is embedded in the binary anyway, so adding this to image metadata won't have any negative effect.
The ko version used to build the image
I'm okay with this, but it does have an unfortunate side effect. Right now, most versions of ko
produce the exact same image, so image builds are reproducible even across most version of ko
. Obviously, this isn't something we can guarantee -- we just ensure that builds are reproducible for a given ko + go version.
If we start embedding ko
version information, we will change the image digest, and start producing more images than we otherwise would, i.e. every time we bump the version. I don't think that's really a problem, but it's a little annoying.
The original importpath (incl version if possible) that was built
We kind of already do:
$ crane config gcr.io/go-containerregistry/crane | jq .history[2]
{
"author": "ko",
"created": "0001-01-01T00:00:00Z",
"created_by": "ko publish ko://github.com/google/go-containerregistry/cmd/crane",
"comment": "go build output, at /ko-app/crane"
}
I'd be fine with adding more here (version, vcs id, etc) or making it more accessible (annotation, label). We could even include the go buildid (see https://github.com/google/ko/pull/269) on a layer annotation if we wanted to start doing remote caching...
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen
. Mark the issue as
fresh by adding the comment /remove-lifecycle stale
.
Except for ko
version, this information is already embedded in the Go binary and now available via ko deps
.
It's nice that different versions of ko
produce the same image right now, but long term I think we'll want to report the exact ko
version for reproducibility/auditability, even if it means producing new images.
Would it be bad to put the ko
version here: https://github.com/google/go-containerregistry/blob/40ba044ce038467e87299d229dcae9f5b2ea815f/pkg/v1/config.go#L34
Would it be bad to put the
ko
version here: https://github.com/google/go-containerregistry/blob/40ba044ce038467e87299d229dcae9f5b2ea815f/pkg/v1/config.go#L34
Doesn't really matter to me where we put it, so long as we can document the expectation of where to find it. Once it's anywhere, we can even change it without breaking possible expectations about cross-ko
-version reproducibility.
@imjasonh Are you referring to OCI annotations? If so, I also needed this. (Context: I am trying to publish images to GHCR.io but the only way to get it to associate images to a particular repo/tag in the UI is to label the OCI images with these annotations.)
I wasn't thinking that exactly but it would also e ~easy to support. What OCI annotations does the GitHub UI expect? source
and revision
?
org.opencontainers.* were not working until somewhat recently (https://twitter.com/clarkbw/status/1380685873067397123?s=21) but it might be working now
This seems more related to https://github.com/google/ko/issues/366, which will happen some time after Go 1.18, and only be available to images built using Go 1.18.
In the meantime, it looks like the UI inspects labels, not annotations, so:
ko publish \
--image-label org.opencontainers.image.source=$(git remote get-url origin) \
--image-label org.opencontainers.image.revision=$(git rev-parse HEAD) \
./cmd/app
ko
-published images should be annotated with information to help derive provenance, to aid debugging or reproducibility. This information could include:More fields might turn out to be useful in the future, but that's a start. These could be annotations on the image/index manifest, or possibly just on the "main" binary layer.