SBOM content diff checker between SPDX 2.2 and SPDX 3.0 by pragnya17 · Pull Request #1011 · microsoft/sbom-tool (original) (raw)
This PR writes a diff checker to compare the content equality between an SPDX 2.2 SBOM and SPDX 3.0 SBOM. The diff checker takes in both files, converts them to the internal SBOM classes, and then uses the comparers to check if the content is equal. This ignores any differences in whitespace and order.
There is also an E2E test here that serves two purposes:
- Test SBOM determinism. SBOMs were not deterministic before due to this bug - Fix for package dependency bug #1101. By generating the SBOM 2 times, we test that the content is deterministic using the diff checker.
- Checks the content equality between SPDX 2.2 and 3.0 documents and E2E tests the diff checker.
ppandrate added 2 commits
ppandrate added 5 commits
This comment was marked as duplicate.
ppandrate added 3 commits
…om relationship converter
This comment was marked as duplicate.
This comment was marked as duplicate.
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approved with a couple of optional suggestions
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
1 similar comment
This PR changes files in the API project. Does it change any of the API interfaces in any way? Please note that this includes the following types of changes:
- Changing the signature of an existing interface method
- Adding a new method to an existing interface
- Adding a required data member to a class that an existing interface method consumes
Because any of these changes can potentially break a downstream consumer with customized interface implementations, these changes need to be treated as breaking changes. Please do one of the following:
Option 1 - Publish this as a breaking change
- Update the documentation to show the new functionality
- Bump the major version in the next release
- Be sure to highlight the breaking changes in the release notes
Option 2 - Refactor the changes to be non-breaking
- Review this commit, which adds a new interface in a backward-compatible way
- Refactor the change to follow this pattern so that existing interfaces are left completely intact
- Bump the minor version in the next release
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})