Track more metadata through the get step

[AtanasNikov]

Is your feature request related to a problem? Please describe.

Hello,

Following up on the discussion started here:
https://github.com/orgs/concourse/discussions/9287

The idea behind extending the registry-image script is to allow teams to track more metadata through the get step in their pipelines.

Describe the solution you'd like

As a proof of concept, we tested several variants. Below is an example using an OCI image, showing how the output looks in the default version versus a modified one.

Default version:

Modified version:

For the implementation, we will focus on extending the in.go script to display:

• image.ConfigFile().Config.Labels
• image.Manifest().Annotations

Our current concerns are the length of the output and the number of label fields.

• When the message becomes too long, the UI requires horizontal scrolling to see the full content:

• Limit the amount of fields to be shown on UI so the page won't become too long to read and load.

We are testing with different amount of fields and length.

Maybe it would make sense to limit the output length after x characters and number of labels at 50-100 max, what is your opinion on the whole topic?

Describe alternatives you've considered

No response

Additional context

No response

[taylorsilva]

Are you adding new config options to the resource for this? Or do you pull in all labels found in the container?

Our current concerns are the length of the output and the number of label fields.

I would probably not change the default behaviour and instead add a new config option, metadata_labels or something like that, which takes a list of strings (maybe regex?) and adds labels that match any of the strings/regex's. This way users can control which labels they want included in the metadata.

Maybe it would make sense to limit the output length after x characters and number of labels at 50-100 max, what is your opinion on the whole topic?

We generally avoid trying to do stuff like that. Users get mad when you mangle their data in arbitrary ways. That said, we could possibly improve the UI, but that's a separate issue from this one. I wouldn't touch the data found in labels, leave it as-is. I appreciate the usability concern.

[AtanasNikov]

Currently we didn't add a config property as we wanted to validate the behaviour of the implementation, but we can add any if you require such. In the current implementation if the image has labels/annotations, those are visualised. With that being said, we can always create an on and off switch etc.? Do you have particular configuration options in mind?

[taylorsilva]

Nothing in mind. Mostly thinking that the default behaviour of the resource should not change and that this should be an opt-in config that users specifically configure in the resource. As long as that is adhered to I'll probably be fine with whatever you've been cooking up.