dotnet / arcade

Tools that provide common build infrastructure for multiple .NET Foundation projects.
MIT License
673 stars 347 forks source link

Tracking sbom update #9325

Closed epananth closed 2 years ago

epananth commented 2 years ago
Repo name Restored internal tools? Do we need to do anything here? Infra error / Repo Error / Sbom manifest tool error
vsUnitTesting ✔️ N/A
dotnet-diagonistics-internal-components ✔️
vs-code-debugger Fixed it (https://github.com/microsoft/dropvalidator/issues/455) SBOM manifest tool error
dotnet-winforms-designer (https://github.com/microsoft/dropvalidator/issues/455) SBOM manifest tool error
MS.VS.Debugger.BrokeredServices They need help to set up arcade update from the bot, they have some changes but it's not working We can tell then what has to be done, so that they can get the latest arcade update for sbom Repo error
dotnet-msbuild release/6.0 Yes, backport to 6.0
razor-tooling (https://github.com/microsoft/dropvalidator/issues/455) SBOM manifest tool error Sbom manifest tool error
roslyn release/6.0 and https://github.com/dotnet/roslyn/pull/61144 Not sure yet
Fsharp (https://github.com/microsoft/dropvalidator/issues/455) SBOM tool error
epananth commented 2 years ago

PR to unblock pr builds https://github.com/dotnet/arcade/pull/9337

epananth commented 2 years ago

Merged the PR, will have to wait to get this change promoted. Once that is done, I will fix the pipelines and the pr build failures should go away.

epananth commented 2 years ago

I got a few repos onboarded to the sbom generation feature. Then I tried Roslyn and to the way things are set up in repo is pretty different from all the other repos we have.

Here we have components of component generation one vsman file. Need to dig more to understand the way they generate vsmanifest.

JoeRobich commented 2 years ago

To add more context about Roslyn case, there are three projects which set the <VisualStudioInsertionComponent> property to "Microsoft.CodeAnalysis.LanguageServices" in their project files. Each project generates a VS component of its own and, because they all share the same <VisualStudioInsertionComponent>, they are combined into one component of subcomponents.

When generating the "Microsoft.CodeAnalysis.LanguageServices" VS Component we need to include a <MergeManifest> entry for each project's generated subcomponent .json and .sbom files.

Such that the following code: https://github.com/dotnet/arcade/blob/b7796f653e48e001123963f17387c052891b48e6/src/Microsoft.DotNet.Arcade.Sdk/tools/VisualStudio.SetupPackage.vsmanproj#L79-L83

would expand into:

<ItemGroup>
  <MergeManifest Include="$(SetupOutputPath)\Microsoft.CodeAnalysis.ExpressionEvaluator.json">
    <SBOMFileLocation>$(ArtifactsDir)sbom\Microsoft.CodeAnalysis.ExpressionEvaluator\spdx_2.2\manifest.spdx.json</SBOMFileLocation>
  </MergeManifest>
  <MergeManifest Include="$(SetupOutputPath)\Microsoft.CodeAnalysis.VisualStudio.Setup.json">
    <SBOMFileLocation>$(ArtifactsDir)sbom\Microsoft.CodeAnalysis.VisualStudio.Setup\spdx_2.2\manifest.spdx.json</SBOMFileLocation>
  </MergeManifest>
  <MergeManifest Include="$(SetupOutputPath)\Roslyn.VisualStudio.Setup.ServiceHub.json">
    <SBOMFileLocation>$(ArtifactsDir)sbom\Roslyn.VisualStudio.Setup.ServiceHub\spdx_2.2\manifest.spdx.json</SBOMFileLocation>
  </MergeManifest>
</ItemGroup>

The concern is that at the time VS Components are being generated, we have already lost the mapping of <VisualStudioInsertionComponent> name to the projects which share the same name. We may need to capture this mapping at an earlier part of the build so that we can then use it during the packaging stage.

cc: @tmat

jakubch1 commented 2 years ago

We reached point where we get such failure: Pipelines - Run 20220527.4 logs (visualstudio.com)

we are now generating 4 vsixes:

Completed generating SBOM manifest for Microsoft.CodeCoverage.Console.ARM64.
Completed generating SBOM manifest for Microsoft.CodeCoverage.Console.X64.
Completed generating SBOM manifest for Microsoft.CodeCoverage.Console.X86.
Completed generating SBOM manifest for Microsoft.VisualStudio.TestTools.DynamicCodeCoverage.

but those 3 vsix files: Microsoft.CodeCoverage.Console.* has same package name called Microsoft.CodeCoverage.Console.Targeted. New PR is here: Pull request 401553: [main] Update dependencies from dotnet/arcade - Repos (visualstudio.com)

jakubch1 commented 2 years ago

Our PR build (with /p:GenerateSbom=false) is also failing: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6218589&view=logs&j=ca395085-040a-526b-2ce8-bdc85f692774&t=b7dc3a0b-0789-5d07-70ca-f7fe10632eeb

epananth commented 2 years ago

Spoke to one of the engineers in SBOM team

1) Alpine leg error - This change which was reverted, fell off SBOMs team radar, they will push the changes 2) https://github.com/microsoft/dropvalidator/issues/455 - We don't have anything actionable from our side. I am going to give them instructions to repro this, that might help us to get a better error. 3) https://github.com/microsoft/dropvalidator/issues/454 - Jakub from vs-code-debugger team is talking to them about this error. For some reason the test fails, he has some solution for this, he is communicating this to SBOM team 4) Fsharp and Roslyn - I've created a pr to unblock their arcade updates. Yet to find out what they need to do, to make sbom generation to work. https://github.com/dotnet/arcade/pull/9556

epananth commented 2 years ago

Our PR build (with /p:GenerateSbom=false) is also failing: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6218589&view=logs&j=ca395085-040a-526b-2ce8-bdc85f692774&t=b7dc3a0b-0789-5d07-70ca-f7fe10632eeb

with the PR https://github.com/dotnet/arcade/pull/9556, this error should go away

epananth commented 2 years ago

We reached point where we get such failure: Pipelines - Run 20220527.4 logs (visualstudio.com)

we are now generating 4 vsixes:

Completed generating SBOM manifest for Microsoft.CodeCoverage.Console.ARM64.
Completed generating SBOM manifest for Microsoft.CodeCoverage.Console.X64.
Completed generating SBOM manifest for Microsoft.CodeCoverage.Console.X86.
Completed generating SBOM manifest for Microsoft.VisualStudio.TestTools.DynamicCodeCoverage.

but those 3 vsix files: Microsoft.CodeCoverage.Console.* has same package name called Microsoft.CodeCoverage.Console.Targeted. New PR is here: Pull request 401553: [main] Update dependencies from dotnet/arcade - Repos (visualstudio.com)

this is more like what Roslyn and F sharp error :(

epananth commented 2 years ago

Spoke to @tmat

He suggested move sbom generation to .vsmanproj right before generation of vs manifest. Get the .vsix file name from the .stubfile

Going to try this out

epananth commented 2 years ago

I did some tests, and I figured the place we were expecting the .vsix files are not present. this was important cos one componentname can have multiple vsixs..

Going to chat with @tmat again..

epananth commented 2 years ago

PR https://github.com/dotnet/arcade/pull/9629

epananth commented 2 years ago

Arcade side work is completed. I created a new FR issue to track the manifest tool error https://github.com/dotnet/arcade/issues/10104, @ilyas1974 will help drive this one.