RFC for Bill of Materials work #57
Conversation
text/0028-bill-of-materials.md
Outdated
|
|
||
| ### Stacks | ||
| Stacks (such as those found in the [Paketo Stacks repository](https://github.com/paketo-buildpacks/stacks)) | ||
| should have BOM metadata that includes in-depth information on all of the OS |
There was a problem hiding this comment.
Can we document the label key and value format we would like to use here?
There was a problem hiding this comment.
Could this be provided in a format that is standardized across the buildpack ecosystem?
There was a problem hiding this comment.
@ekcasey @matthewmcnew check out the section we added below and let us know your thoughts
There was a problem hiding this comment.
@matthewmcnew yes I agree that we should. However, I think it is okay for Paketo to essentially incubate this feature while CNB works on improving the BOM. With the understanding that we may need to make adjustments if/when CNB makes this a standard.
text/0028-bill-of-materials.md
Outdated
|
|
||
| ### Runtime and Compilation Dependencies | ||
| Dependencies that provide runtimes and/or are used for compilation should have | ||
| BOM metadata surfaced about them. This includes both the dependencies in the |
There was a problem hiding this comment.
Currently, build-only dependencies should be added to the build BOM in build.toml. It is probably worth calling out that distinction explicitly.
https://github.com/buildpacks/spec/blob/main/buildpack.md#bills-of-materials
There was a problem hiding this comment.
We do call out that we will not only capture the dependencies that are in the final image but ones used during build. Do we need hammer this point harder? Would you like use to call out that they are logged in 2 different BOMs by the lifecycle?
|
@ekcasey @matthewmcnew @fg-j - We reviewed this in the working group meeting. Just a quick reminder to submit feedback or resolve any ongoing conversations. Thanks! |
text/0028-bill-of-materials.md
Outdated
| "version" : "<package source version>", | ||
| "upstreamVersion" : "<package source upstream version>" | ||
| }, | ||
| "summary" : "<package summary>" |
There was a problem hiding this comment.
We should probably include a licenses key.
There was a problem hiding this comment.
The reason we left this out is because we were investigating tools to collect licenses for the stacks, and the best option we founddpkg-licenses which only guarantees up to 90% of all license information, due to the lack of standardization in licenses. The tradeoff between the work involved getting that last 10% of license metadata, and user need wasn't worth it at the time we investigated this, so we left it out as something in the minimal set of fields.
Issue where we mentioned this: paketo-buildpacks/stacks#70
I do think it would be good to include license information in the future, but I would be okay leaving it out of this RFC for now.
text/0028-bill-of-materials.md
Outdated
| { | ||
| "name" : "<package name>", | ||
| "version" : "<package version>", | ||
| "arch" : "<compatible architecture>", |
There was a problem hiding this comment.
The processor architecture that the package is compatible with, such as amd64.
While it's perhaps not the most valuable BoM field, it's information that we already currently surface for the stacks in the io.paketo.stack.packages label, so we thought we might as well surface more information than less.
sophiewigmore
force-pushed
the
sophie/bom
branch
from
077a268 to
818c121
Compare
text/0028-bill-of-materials.md
Outdated
| version = "<dependency source version>", | ||
| upstream-version = "<dependency source upstream version>" | ||
| ``` | ||
| The optional set of keys may include: |
There was a problem hiding this comment.
Is there any reason to call out optional keys? I was assuming anything in the schema that wasn't required was optional.
There was a problem hiding this comment.
Good call. Addressed in 7575872
There was a problem hiding this comment.
Sorry for nitpicking on this but I am still confused after the above linked changes. In my mind there are only two things we need to specify. The complete schema (any field in which could optionally be filled out, for any type of entry) and any required fields for specific entry types. I don't understand why we re repeating subsets of the schema if to indicate required fields.
Are these the suggested fields (in which case maybe we could teak the wording to make that clear)? Or does this imply that other fields in the schema are disallowed for these dependency types (I don't think we should do this)?
There was a problem hiding this comment.
Following this comment/our discussion around this at the 7-27 Working Group meeting, we have gone ahead and streamlined the RFC to solely include the top-level schema to show possible fields, and removed the dependency-type schemas. They are recommended fields, the only required fields are "name" and "version".
Signed-off-by: Sophie Wigmore <[email protected]>
Co-authored-by: Kashyap Vedurmudi <[email protected]>
Signed-off-by: Forest Eckhardt <[email protected]>
Signed-off-by: Sophie Wigmore <[email protected]>
Co-authored-by: Ryan Moran <[email protected]>
Co-authored-by: Emily Casey <[email protected]>
Signed-off-by: Forest Eckhardt <[email protected]>
Co-authored-by: Ryan Moran <[email protected]>
Signed-off-by: Forest Eckhardt <[email protected]>
ForestEckhardt
force-pushed
the
sophie/bom
branch
from
88a0090 to
9fc9c0a
Compare
Signed-off-by: Sophie Wigmore [email protected]
Summary
Readable
Resolves #56
Checklist