ko icon indicating copy to clipboard operation
ko copied to clipboard

FR: Annotate images with build information

Open imjasonh opened this issue 3 years ago • 11 comments

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.

imjasonh avatar Oct 12 '20 18:10 imjasonh

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.

github-actions[bot] avatar Jan 11 '21 02:01 github-actions[bot]

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

jonjohnsonjr avatar Jan 11 '21 17:01 jonjohnsonjr

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.

github-actions[bot] avatar Apr 24 '21 01:04 github-actions[bot]

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.

imjasonh avatar Sep 20 '21 15:09 imjasonh

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

jonjohnsonjr avatar Sep 20 '21 18:09 jonjohnsonjr

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 avatar Sep 20 '21 18:09 imjasonh

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

ahmetb avatar Oct 26 '21 00:10 ahmetb

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?

imjasonh avatar Oct 26 '21 00:10 imjasonh

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

halvards avatar Oct 26 '21 00:10 halvards

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

ahmetb avatar Oct 26 '21 02:10 ahmetb

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

imjasonh avatar Oct 26 '21 13:10 imjasonh