API changes to support SPDX 3.0 #924

pragnya17 · 2025-02-07T18:54:04Z

Update the validation/parsing and generation workflows to reflect the different SPDX 3.0 defined entities.
Add a cmd line parameter for different compliance standards. For example, parse SbomFileExample.txt -complianceStandard NTIA
Make sure there are no duplicate spdx elements
Unit testing command line API changes, workflows, utility methods

github-actions · 2025-02-07T18:58:43Z

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

github-actions · 2025-02-07T19:00:01Z

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

github-actions · 2025-02-07T19:15:50Z

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

…s other breaking changes

github-actions · 2025-02-07T20:01:20Z

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

src/Microsoft.Sbom.Api/Executors/ComponentDetectionBaseWalker.cs

src/Microsoft.Sbom.Api/Executors/GenerateResult.cs

DaveTryon · 2025-02-07T23:32:29Z

src/Microsoft.Sbom.Api/Executors/IJsonSerializationStrategy.cs

+
+namespace Microsoft.Sbom.Api.Workflows.Helpers;
+
+public interface IJsonSerializationStrategy


I'm not seeing this interface in any test classes. Is that a gap we should address?

This is tested in the workflow tests where there are UTs to switch to different serialization strategies based on the manifest version. So I don't think that there's necessarily a gap here.

src/Microsoft.Sbom.Api/Executors/IJsonSerializationStrategy.cs

src/Microsoft.Sbom.Api/Executors/JsonSerializationStrategyFactory.cs

src/Microsoft.Sbom.Api/Executors/Spdx2SerializationStrategy.cs

src/Microsoft.Sbom.Api/Executors/Spdx3SerializationStrategy.cs

src/Microsoft.Sbom.Api/Output/MetadataBuilder.cs

src/Microsoft.Sbom.Api/Workflows/Helpers/ExternalDocumentReferenceGenerator.cs

src/Microsoft.Sbom.Parsers.Spdx30SbomParser/Generator.cs

DaveTryon · 2025-02-10T20:04:32Z

test/Microsoft.Sbom.Api.Tests/SBOMGeneratorTest.cs

@@ -100,4 +102,25 @@ public async Task When_GenerateSbomAsync_WithNoRecordedErrors_Then_EmptyEntityEr
        mockRecorder.Verify();
        mockWorkflow.Verify();
    }
+


Code coverage for the generator hits most of the happy paths, but leaves a lot of error cases untouched. Should we try to cover more of the error paths?

I cover most of the SPDX 30 generation cases in \source\repos\sbom-tool\test\Microsoft.Sbom.Parsers.Spdx30SbomParser.Tests\Parser\GeneratorTests.cs. This file is specifically for api generator tests, which didn't change much because I didn't have to add any api params to the generator (compared to the parser which had an actual api param change).

If there's a code coverage report or something that's not covered specifically, I can take a look, feel free to lmk what you think

test/Microsoft.Sbom.Api.Tests/Workflows/ManifestGenerationWorkflowTests.cs

test/Microsoft.Sbom.Api.Tests/Workflows/SbomParserBasedValidationWorkflowTests.cs

DaveTryon · 2025-02-10T20:20:58Z

test/Microsoft.Sbom.Api.Tests/Workflows/SbomParserBasedValidationWorkflowTests.cs

@@ -379,4 +464,143 @@ public async Task SbomParserBasedValidationWorkflowTests_ReturnsSuccessAndValida
        fileSystemMock.VerifyAll();
        osUtilsMock.VerifyAll();
    }
+
+    [TestMethod]
+    public async Task SbomParserBasedValidationWorkflowTests_SetsComplianceStandard_Succeeds()


Code smell: If we need to have > 100 lines of code to run a 2 line test, we probably have some fundamental problems with our interface story

Since I am setting the compliance standard in the workflow (when the parser gets created), all of these mocks are created in order to run the workflow which will set the compliance standard that I am asserting for.

Maybe I can create a work item to take this issue up in a separate PR? I think it would involve some extensive rewriting of interfaces

github-actions · 2025-02-10T23:10:57Z

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

pragnya17 · 2025-02-10T23:16:32Z

/azp run

github-actions · 2025-02-12T00:04:16Z

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

pragnya17 · 2025-02-12T16:49:57Z

/azp run

github-actions · 2025-02-13T00:58:18Z

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

pragnya17 · 2025-02-13T01:11:43Z

/azp run

DaveTryon · 2025-02-13T18:27:52Z

src/Microsoft.Sbom.Api/Workflows/Helpers/RelationshipsArrayGenerator.cs

        this.recorder = recorder;
+        this.generationData = this.SbomConfig.Recorder.GetGenerationData();


At construction, SbomConfig is null, so this is throwing a NullReferenceException. If the intent is to call SbomConfig.Recorder.GetGenerationData only once, you need to defer the call until after SbomConfig has been set. You could initialize it in the setter for SbomConfig, or you can defer reading it from SbomConfig until generationData is actually read. Happy to discuss this directly, if you wish.

I had initially moved it to the constructor since we didn't want to have this. outside of the constructor, but I don't think there's a way around that here since sbomConfig needs to be set before calling GetGenerationData()

src/Microsoft.Sbom.Api/Output/MetadataBuilder.cs

github-actions · 2025-02-14T04:00:50Z

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

github-actions · 2025-02-14T23:22:50Z

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

pragnya17 · 2025-02-14T23:24:25Z

/azp run

github-actions · 2025-02-15T00:41:05Z

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

pragnya17 · 2025-02-15T00:44:11Z

/azp run

github-actions · 2025-02-15T17:32:46Z

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

pragnya17 · 2025-02-15T17:36:04Z

/azp run

github-actions · 2025-02-15T22:05:06Z

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

pragnya17 · 2025-02-15T22:06:42Z

/azp run

ppandrate added 7 commits January 22, 2025 16:32

update UT to use spdx 3.0 generator

e0d9061

generator api changes + restructuring classes

414a3fb

merge conflict

3e4fd88

wokring generator api changes with UT

bbdd751

working UT for compliance standard

9010c31

parsing deduplication

0c6c7a3

generator deduplication + add context

b5a943e

pragnya17 requested a review from a team as a code owner February 7, 2025 18:54

merge conflict

c462e85

remove from public docs until release

886040a

clean up changes + update interface pins

da1a30f

update spdxmetadata - including this breaking change since this PR ha…

06ef615

…s other breaking changes

DaveTryon reviewed Feb 7, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/ComponentDetectionBaseWalker.cs Show resolved Hide resolved

DaveTryon reviewed Feb 7, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/GenerateResult.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 7, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/GenerateResult.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 7, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/IJsonSerializationStrategy.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 7, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/JsonSerializationStrategyFactory.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 7, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/JsonSerializationStrategyFactory.cs Show resolved Hide resolved

DaveTryon reviewed Feb 7, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/Spdx2SerializationStrategy.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 8, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/Spdx3SerializationStrategy.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 8, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/Spdx3SerializationStrategy.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 8, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Executors/Spdx3SerializationStrategy.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 8, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Output/MetadataBuilder.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 8, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Workflows/Helpers/ExternalDocumentReferenceGenerator.cs Show resolved Hide resolved

DaveTryon reviewed Feb 8, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Workflows/Helpers/ExternalDocumentReferenceGenerator.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 10, 2025

View reviewed changes

src/Microsoft.Sbom.Parsers.Spdx30SbomParser/Generator.cs Show resolved Hide resolved

DaveTryon reviewed Feb 10, 2025

View reviewed changes

test/Microsoft.Sbom.Api.Tests/Workflows/ManifestGenerationWorkflowTests.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 10, 2025

View reviewed changes

test/Microsoft.Sbom.Api.Tests/Workflows/SbomParserBasedValidationWorkflowTests.cs Outdated Show resolved Hide resolved

DaveTryon reviewed Feb 10, 2025

View reviewed changes

fix unit tests

0116139

Refactor constants

a12527f

Clean up and refactor code, address PR comments

2c3d594

DaveTryon reviewed Feb 13, 2025

View reviewed changes

src/Microsoft.Sbom.Api/Output/MetadataBuilder.cs Outdated Show resolved Hide resolved

working API changes

9fb1129

bug fixes and cleanup

b91f763

fix manifestinfovalidator, remove unnecessary changes

08afffd

fix bug in spdx 2.0 sbom generation when array is empty

99cbb60

fix serializer

687c836

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

API changes to support SPDX 3.0 #924

API changes to support SPDX 3.0 #924

pragnya17 commented Feb 7, 2025

github-actions bot commented Feb 7, 2025

github-actions bot commented Feb 7, 2025

github-actions bot commented Feb 7, 2025

github-actions bot commented Feb 7, 2025

DaveTryon Feb 7, 2025 •

edited

Loading

pragnya17 Feb 12, 2025

DaveTryon Feb 10, 2025

pragnya17 Feb 13, 2025

DaveTryon Feb 10, 2025

pragnya17 Feb 12, 2025

pragnya17 Feb 12, 2025

github-actions bot commented Feb 10, 2025

pragnya17 commented Feb 10, 2025

github-actions bot commented Feb 12, 2025

pragnya17 commented Feb 12, 2025

github-actions bot commented Feb 13, 2025

pragnya17 commented Feb 13, 2025

DaveTryon Feb 13, 2025 •

edited

Loading

pragnya17 Feb 14, 2025

github-actions bot commented Feb 14, 2025

github-actions bot commented Feb 14, 2025

pragnya17 commented Feb 14, 2025

github-actions bot commented Feb 15, 2025

pragnya17 commented Feb 15, 2025

github-actions bot commented Feb 15, 2025

pragnya17 commented Feb 15, 2025

github-actions bot commented Feb 15, 2025

pragnya17 commented Feb 15, 2025


		namespace Microsoft.Sbom.Api.Workflows.Helpers;

		public interface IJsonSerializationStrategy

		this.recorder = recorder;
		this.generationData = this.SbomConfig.Recorder.GetGenerationData();

API changes to support SPDX 3.0 #924

Are you sure you want to change the base?

API changes to support SPDX 3.0 #924

Conversation

pragnya17 commented Feb 7, 2025

github-actions bot commented Feb 7, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

github-actions bot commented Feb 7, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

github-actions bot commented Feb 7, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

github-actions bot commented Feb 7, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

DaveTryon Feb 7, 2025 • edited Loading

Choose a reason for hiding this comment

pragnya17 Feb 12, 2025

Choose a reason for hiding this comment

DaveTryon Feb 10, 2025

Choose a reason for hiding this comment

pragnya17 Feb 13, 2025

Choose a reason for hiding this comment

DaveTryon Feb 10, 2025

Choose a reason for hiding this comment

pragnya17 Feb 12, 2025

Choose a reason for hiding this comment

pragnya17 Feb 12, 2025

Choose a reason for hiding this comment

github-actions bot commented Feb 10, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

pragnya17 commented Feb 10, 2025

github-actions bot commented Feb 12, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

pragnya17 commented Feb 12, 2025

github-actions bot commented Feb 13, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

pragnya17 commented Feb 13, 2025

DaveTryon Feb 13, 2025 • edited Loading

Choose a reason for hiding this comment

pragnya17 Feb 14, 2025

Choose a reason for hiding this comment

github-actions bot commented Feb 14, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

github-actions bot commented Feb 14, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

pragnya17 commented Feb 14, 2025

github-actions bot commented Feb 15, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

pragnya17 commented Feb 15, 2025

github-actions bot commented Feb 15, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

pragnya17 commented Feb 15, 2025

github-actions bot commented Feb 15, 2025

Option 1 - Publish this as a breaking change

Option 2 - Refactor the changes to be non-breaking

pragnya17 commented Feb 15, 2025

DaveTryon Feb 7, 2025 •

edited

Loading

DaveTryon Feb 13, 2025 •

edited

Loading