RFC for new pack inspect-image command #5
Conversation
Signed-off-by: Emily Casey <ecasey@pivotal.io>
text/0000-pack-inspect-image.md
Outdated
| # Summary | ||
| [summary]: #summary | ||
|
|
||
| An `inspect-image` command will be added to the `pack` CLI, allowing buildpack users to easily view metadata about an image generated by the Cloud Native Buildpack Lifecycle. The command will print the stack ID, stack metadata (run-image and run-image-mirrors), the buildpacks that contributed to the image, the bill of materials, and the processes types. |
There was a problem hiding this comment.
This may be out of scope for this RFC, but as we're starting to get more and more of the hyphenated commands, I wonder if we should consider other command patterns, such as:
pack [topic]:[command](in this casepack image:inspectpack [topic] [command](in this casepack image inspect(similar todocker)
I'm not necessarily against hyphenated commands, I just want to make sure we're choosing that pattern for good reasons.
There was a problem hiding this comment.
I'm open to the idea of changing the pattern of all of our cli commands, but it seems like that should be a different RFC or issue. I wouldn't want the implementation of this RFC to be blocked on that discussion.
text/0000-pack-inspect-image.md
Outdated
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| - Should we add the buildpack id and version to the BOM entries? | ||
| - Is there a better format for the BOM output than YAML? TOML would be in keeping with our ecosystem but it's harder to read. |
There was a problem hiding this comment.
It's my understanding that BOMs can become quite large. I wonder how we could mitigate this during output to keep a nice experience? Perhaps if a BOM is longer than a certain number of lines, we dump it to a file instead and give a link?
Otherwise, I think this new command makes a lot of sense.
text/0000-pack-inspect-image.md
Outdated
| # Unresolved Questions | ||
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| - Should we add the buildpack id and version to the BOM entries? |
There was a problem hiding this comment.
For auditing purposes is it important to know where the buildpacks come from?
|
From the last specification WG, we've decided to split the bill of materials into a |
* new flag conventions introduce natural extension points Signed-off-by: Emily Casey <ecasey@pivotal.io>
|
@hone any additional questions? Would like to begin implementing this. |
rendered
Signed-off-by: Emily Casey ecasey@pivotal.io