FR: Annotate images with build information

[imjasonh]

ko-published images should be annotated with information to help derive provenance, to aid debugging or reproducibility. This information could include:

• The go version used to build the binary layer
• The ko version used to build the image
• The original importpath (incl version if possible) that was built

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.

[github-actions]

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.

[jonjohnsonjr]

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 #269) on a layer annotation if we wanted to start doing remote caching...

[github-actions]

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.

[imjasonh]

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.

[jonjohnsonjr]

Would it be bad to put the ko version here: https://github.com/google/go-containerregistry/blob/40ba044ce038467e87299d229dcae9f5b2ea815f/pkg/v1/config.go#L34

[imjasonh]

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.

[ahmetb]

@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.)

[imjasonh]

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?

[halvards]

source: https://docs.github.com/en/packages/learn-github-packages/connecting-a-repository-to-a-package#connecting-a-repository-to-a-container-image-using-the-command-line

[ahmetb]

org.opencontainers.* were not working until somewhat recently (https://twitter.com/clarkbw/status/1380685873067397123?s=21) but it might be working now

[imjasonh]

This seems more related to #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