We are reporting the layers makeup in the project, but we are cannot determine easily if a resource or package belongs to a certain layer (or a certain image when we scan a tarball with multiple images).
A possible solution would be to introduce a concept of tag that would be a single free text field in a CodebaseResource and a DiscoveredPackage that a pipeline could set. And this would be reported in the XLSX and JSON outputs.
Then the docker pipeline could set this "tag" field to a value that would structured using a short image id + layer id with proper prefixes so things sort out nicely.
For instance, given an image with an id 785df58b6b3e120f59bce6cd10169a0c58b8837b24f382e27593e2eea011a0d8 and two layers from bottom to top as 0690c89adf3e8c306d4ced085fc16d1d104dcfddd6dc637e141fa78be242a707 and 7a1d89d2653e8e4aa9011fd95034a4857109d6636f2ad32df470a196e5dd1585 we could get these two tags:
- img-785df5-layer-01-0690c8
- img-785df5-layer-02-7a1d89
This is not too long, clear and sortable.
(The length of the hex to keep could be fixed to 6 chars or computed to ensure unicity)
An alternative could be to generalize this approach to an arbitrary mapping of "extra_data" name/value pairs that would be then reported as extra columns in the XLSX output or as a plain mapping in the JSON output. This would allow to create new "columns" for an image id, a layer order and a layer id.
We are reporting the layers makeup in the project, but we are cannot determine easily if a resource or package belongs to a certain layer (or a certain image when we scan a tarball with multiple images).
A possible solution would be to introduce a concept of tag that would be a single free text field in a CodebaseResource and a DiscoveredPackage that a pipeline could set. And this would be reported in the XLSX and JSON outputs.
Then the docker pipeline could set this "tag" field to a value that would structured using a short image id + layer id with proper prefixes so things sort out nicely.
For instance, given an image with an id 785df58b6b3e120f59bce6cd10169a0c58b8837b24f382e27593e2eea011a0d8 and two layers from bottom to top as 0690c89adf3e8c306d4ced085fc16d1d104dcfddd6dc637e141fa78be242a707 and 7a1d89d2653e8e4aa9011fd95034a4857109d6636f2ad32df470a196e5dd1585 we could get these two tags:
This is not too long, clear and sortable.
(The length of the hex to keep could be fixed to 6 chars or computed to ensure unicity)
An alternative could be to generalize this approach to an arbitrary mapping of "extra_data" name/value pairs that would be then reported as extra columns in the XLSX output or as a plain mapping in the JSON output. This would allow to create new "columns" for an image id, a layer order and a layer id.