Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define a richer image output #68

Open
imjasonh opened this issue Apr 24, 2023 · 2 comments
Open

Define a richer image output #68

imjasonh opened this issue Apr 24, 2023 · 2 comments

Comments

@imjasonh
Copy link
Member

Currently the only output of a ko_build is its image_ref, the fully qualified image reference by digest (e.g., foo.io/repo/image@sha256:abcdef...). This is enough to make it useful to deployment targets, but we can do better.

As things like tf-crane and tf-apko and tf-cosign start to come up, we should define a common shareable schema for this, so that they can all agree on the types.

This will be a little complicated because, like ggcr, things can produce an Image or a multi-platform Index, and the contents of those and the types of things that can attach to them are affected by which they are.

I don't think we should bifurcate into ko_image and ko_index, apko_image/apko_index, cosign_signed_image/cosign_signed_index, etc. -- this is why we moved from ko_image to the more abstract ko_build.

Some things we might want to express in a general-purpose output schema:

  • media_type, and is_image / is_index
  • layers (populated if is_image), list of:
    • digest
    • size
    • file contents? 🤔
  • manifests (populated if is_index), map of platform -> object:
    • digest
    • layers (see above)
    • sbom (see next)
  • sbom, list of purl objects:
    • purl (raw purl string), scheme, type, namespace, name, version, qualifiers (map[string]string), subpath

This would let us extract SBOM information from a ko- or crane- or apko-built artifacts, so that terraform plan can show us what dependency packages changed.

layers composes with tf-crane to let you crane_append your own layer. manifests can compose with a future crane_something that mutates or builds up manifests from scratch.

sbom can compose with something like cosign_attest_sbom that takes the previously built-but-not-signed SBOM and attests/signs it.

I think we can start to define this schema anywhere, but eventually I think it makes most sense to live in tf-crane, where it becomes sort of like the TF equivalent of ggcr.

@imjasonh
Copy link
Member Author

@jonjohnsonjr makes a good point that we should have a descriptor type that encompasses digest+size and all the other descriptor fields.

I think we probably want a media_type type that has a string .value and .is_image/.is_index.

@imjasonh
Copy link
Member Author

After chainguard-dev/terraform-provider-oci#6 we have most of the types/schemas we need.

That adds an internal Manifest.FromDescriptor(*remote.Descriptor), which we can either:

  1. make external and do a remote.Get on the just-pushed image (suboptimally requiring another HTTP request), or
  2. make our own version that takes a build.Result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant