Closed epananth closed 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 |
PR to unblock pr builds https://github.com/dotnet/arcade/pull/9337
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.
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.
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
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)
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
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
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
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 :(
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
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..
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.