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

Build summary for ko resolve #406

Open
HeavyWombat opened this issue Aug 2, 2021 · 8 comments
Open

Build summary for ko resolve #406

HeavyWombat opened this issue Aug 2, 2021 · 8 comments

Comments

@HeavyWombat
Copy link
Contributor

HeavyWombat commented Aug 2, 2021

We do builds with ko resolve to have images and also a deployment YAML. However, we were wondering whether there would be an easy way to get a list of all images (and their digest) that are created as part of the resolve run (without parsing the output). If not, would a command line flag, e.g. --bom (bill of materials, or similar) an option? Thanks in advance for feedback.

@imjasonh
Copy link
Member

imjasonh commented Aug 2, 2021

In theory all the information you want is available somewhere in the mass of output that ko spams at you. Lines like:

2021/08/02 08:25:07 gcr.io/imjasonh/windows/github.com/tektoncd/pipeline/cmd/pullrequest-init@sha256:60ddf2f4cf2392f95da20ec6895b89143a6299bb8331898f58af9de81dcfa6e6: digest: sha256:60ddf2f4cf2392f95da20ec6895b89143a6299bb8331898f58af9de81dcfa6e6 size: 1328

...but I agree it's not terribly useful.

I'm a bit hesitant to call this better output a "BOM", because that term is quickly expanding to mean anything and everything anybody wants it to mean. 🙃

Are you envisioning some secondary yaml/json output in some file somewhere that you can post-process? It should live outside the current working directory, since that will likely pollute your Git workspace.

Another similar idea is something like ko extract described in #358 (comment) -- something that could crawl a YAML document looking for strings that look like ko-produced images, and output them. I swear I wrote code for this recently but I can't seem to find it now. 🤔 Anyway, that could be useful for lots of stuff, and it would compose well too, like ko resolve | ko extract, or even cat release.yaml | ko extract, or other bash monstrosities 😈

@HeavyWombat
Copy link
Contributor Author

HeavyWombat commented Aug 2, 2021

I am not big fan of the term BOM myself, so I would be more than happy to have some secondary YAML/JSON that contains the container images - brief and simple. Rational is that we want to properly sign container images that we build and we want to do that with all ko created images, too. Therefore, I am looking into options.

@jonjohnsonjr
Copy link
Collaborator

You can kinda do that today:

$ ko resolve -f ./test/test.yaml --oci-layout-path /tmp/ko --push
2021/08/02 08:22:08 Using base gcr.io/distroless/static:nonroot for github.com/google/ko/test
2021/08/02 08:22:09 Building github.com/google/ko/test for linux/amd64
2021/08/02 08:22:10 Saving ko://github.com/google/ko/test
2021/08/02 08:22:10 Saved ko://github.com/google/ko/test
2021/08/02 08:22:10 Publishing gcr.io/jonjohnson-test/ko/test-46c4b272b3716c422d5ff6dfc7547fa9:latest
2021/08/02 08:22:11 existing blob: sha256:0d7d70899875b098ace120b574f57b39e91415ceaf9b348d6abe168537509f5a
2021/08/02 08:22:12 pushed blob: sha256:db05b9e5a36da708e15e18678d61e7e143a2c374939ba0951769dda7dd6485aa
2021/08/02 08:22:12 pushed blob: sha256:894b866a04cb174420d7f0ff17c7734315bc9f22f99f14700584ea0875f17e9c
2021/08/02 08:22:13 pushed blob: sha256:0ed487903593000fed432ac6618542e7cadb9248e4f790ca8a4e9d99a64ca53c
2021/08/02 08:22:14 gcr.io/jonjohnson-test/ko/test-46c4b272b3716c422d5ff6dfc7547fa9:latest: digest: sha256:cbebf1c14c167cd48d99a294fdfafe58452bf58ce77183f50661bd7b9abd7800 size: 752
2021/08/02 08:22:14 Published gcr.io/jonjohnson-test/ko/test-46c4b272b3716c422d5ff6dfc7547fa9@sha256:cbebf1c14c167cd48d99a294fdfafe58452bf58ce77183f50661bd7b9abd7800

$ cat /tmp/ko/index.json 
{
   "schemaVersion": 2,
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 752,
         "digest": "sha256:cbebf1c14c167cd48d99a294fdfafe58452bf58ce77183f50661bd7b9abd7800"
      }
   ]
}

Do you also need where it was pushed?

@HeavyWombat
Copy link
Contributor Author

This looks great. I did not know that. If we could get the details where it was pushed to, it would be perfect.

@jonjohnsonjr
Copy link
Collaborator

If we could get the details where it was pushed to, it would be perfect.

How do you want to use it? What should happen if the same image is pushed to multiple repositories or with multiple tags?

Do you just want something like a map from very image reference that was pushed to its digest?

@HeavyWombat
Copy link
Contributor Author

The map sounds pretty good. Basically, what I am looking for is that if ko builds for example six images during resolve, I would like to know each image reference and its respective digest. Pretty much what is logged as Published gcr.io/jonjohnson-test/ko/test-46c4b272b3716c422d5ff6dfc7547fa9@sha256:cbebf1c14c167cd48d99a294fdfafe58452bf58ce77183f50661bd7b9abd7800 I guess.

@jonjohnsonjr
Copy link
Collaborator

Definitely seems possible -- if we wanted to just reuse the index for this, we could add that map as annotations at the top level:

$ cat /tmp/ko/index.json 
{
   "schemaVersion": 2,
   "manifests": [
      {
         "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
         "size": 752,
         "digest": "sha256:cbebf1c14c167cd48d99a294fdfafe58452bf58ce77183f50661bd7b9abd7800"
      }
   ],
   "annotations": {
      "gcr.io/jonjohnson-test/ko/test-46c4b272b3716c422d5ff6dfc7547fa9:latest": "sha256:cbebf1c14c167cd48d99a294fdfafe58452bf58ce77183f50661bd7b9abd7800"
   }
}

Maybe an abuse of annotations, but I think it's fine. This could also just be a completely separate document that doesn't require creating the OCI layout on disk...

@github-actions
Copy link

github-actions bot commented Nov 1, 2021

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. Keep fresh with the 'lifecycle/frozen' label.

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

No branches or pull requests

3 participants