Command `describe` does not include `metadata`.

[etirta]

What steps did you take:
As per #124 (comment), I expect when we do imgpkg describe -b ..., if the bundle have metadata fields, it it will be printed as written in imgpkg/bundle.yml.

I put some data:

$ cat .imgpkg/bundle.yml 
metadata:
  oslManifestURL: ...

before I do imgpkg push -b ..., but it's not appearing when I do imgpkg describe -b ...:

$ imgpkg describe -b ... --output-type yaml
sha: sha256:bb59ca320f34063174bc9c00bc6f5b795d223c3b9b965851038ce85ebe4eb1d2
content:
...
image: ...
metadata: {}
origin: ...

Succeeded

What happened:
The metadata information is not printed.

What did you expect:
The metadata information is printed.

Anything else you would like to add:
The code seems to never populate this, just put an empty map as place holder.

Can this please be rectified, so I can retrieve this information vie impkg describe -b ...?

If I do imgpkg pull -b ..., the retrieved .imgpkg/bundle.yml has the information, but I don't want to have to pull it as the bundle can be huge, it's just a waste of time and local storage to pull the whole bundle just for me to get the .imgpkg/bundle.yml.

Environment:

• imgpkg version (use imgpkg --version): 0.34.1
• Docker registry used (e.g. Docker HUB): Harbor, Artifactory
• OS (e.g. from /etc/os-release): Various (Ubuntu, CentOS, photon).

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[joaopapereira]

I did update some labels on this issue.
We never implemented that part of the UX because there was no one asking for it, but now we do 😄
This is something that it would be great to have when you do a describe.

For this, some exciting work needs to be done because today, we only read the ImagesLock file from the bundle image. To complete this feature, we would need to do something like the following steps:

1. Read the BundleLock file as well. Take a look at the ImagesLock reader
2. Have that information be retrievable by implementing maybe something like Bundle.BundleLock() that can use a similar implementation to the retrieval of ImagesLock
3. Call the above function on the describe API to populate the metadata.

Is this something that you would be interested in contributing?