Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC for Bill of Materials work #57

Merged
merged 17 commits into from
Aug 10, 2021

Conversation

sophiewigmore
Copy link
Member

@sophiewigmore sophiewigmore commented May 10, 2021

Signed-off-by: Sophie Wigmore swigmore@vmware.com

Summary

Readable

Resolves #56

Checklist

  • I have viewed, signed, and submitted the Contributor License Agreement.
  • I have linked issue(s) that this PR should close using keywords or the Github UI (See docs)
  • I have added an integration test, if necessary.
  • I have reviewed the styleguide for guidance on my code quality.
  • I'm happy with the commit history on this PR (I have rebased/squashed as needed).

@sophiewigmore sophiewigmore requested a review from a team as a code owner May 10, 2021 19:37

### 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we document the label key and value format we would like to use here?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this be provided in a format that is standardized across the buildpack ecosystem?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ekcasey @matthewmcnew check out the section we added below and let us know your thoughts

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.


### 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
@linux-foundation-easycla
Copy link

linux-foundation-easycla bot commented May 11, 2021

CLA Signed

The committers are authorized under a signed CLA.

@dmikusa
Copy link
Contributor

dmikusa commented Jun 1, 2021

@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!

"version" : "<package source version>",
"upstreamVersion" : "<package source upstream version>"
},
"summary" : "<package summary>"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably include a licenses key.

Copy link
Member Author

@sophiewigmore sophiewigmore Jun 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

{
"name" : "<package name>",
"version" : "<package version>",
"arch" : "<compatible architecture>",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the utility of arch?

Copy link
Member Author

@sophiewigmore sophiewigmore Jun 16, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
Copy link
Member

@ryanmoran ryanmoran left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see that each of the types of BOM entries seem to be conforming to a standardized schema. Could we show that complete schema at some point in the RFC?

text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
version = "<dependency source version>",
upstream-version = "<dependency source upstream version>"
```
The optional set of keys may include:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any reason to call out optional keys? I was assuming anything in the schema that wasn't required was optional.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. Addressed in 7575872

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)?

Copy link
Member Author

@sophiewigmore sophiewigmore Jul 28, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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".

text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
text/0028-bill-of-materials.md Outdated Show resolved Hide resolved
ForestEckhardt and others added 6 commits August 10, 2021 19:53
Signed-off-by: Sophie Wigmore <swigmore@vmware.com>
Co-authored-by: Kashyap Vedurmudi <37810054+kvedurmu@users.noreply.github.com>
Signed-off-by: Forest Eckhardt <feckhardt@pivotal.io>
Signed-off-by: Sophie Wigmore <swigmore@vmware.com>
sophiewigmore and others added 11 commits August 10, 2021 19:53
Co-authored-by: Ryan Moran <155736+ryanmoran@users.noreply.github.com>
Co-authored-by: Emily Casey <emilykimballcasey@gmail.com>
Signed-off-by: Forest Eckhardt <feckhardt@pivotal.io>
Co-authored-by: Ryan Moran <155736+ryanmoran@users.noreply.github.com>
Signed-off-by: Forest Eckhardt <feckhardt@pivotal.io>
@sophiewigmore sophiewigmore merged commit 022f8e7 into paketo-buildpacks:main Aug 10, 2021
@sophiewigmore sophiewigmore deleted the sophie/bom branch August 10, 2021 20:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Create RFC for Bill-of-Materials inclusion across Paketo projects
8 participants