ko-build / ko

Build and deploy Go applications
https://ko.build
Apache License 2.0
7.47k stars 389 forks source link

FR: Annotate images with build information #221

Open imjasonh opened 3 years ago

imjasonh commented 3 years ago

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.

github-actions[bot] commented 3 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.

jonjohnsonjr commented 3 years ago

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

github-actions[bot] commented 3 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.

imjasonh commented 2 years ago

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 commented 2 years ago

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

imjasonh commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

imjasonh commented 2 years ago

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