Add SdkArchiveDiff task to verify the sdk archive has all the expected files #18748
Conversation
...et.SourceBuild.Tasks.SdkArchiveDiff/Microsoft.DotNet.SourceBuild.Tasks.SdkArchiveDiff.csproj
Outdated
Show resolved
Hide resolved
...et.SourceBuild.Tasks.SdkArchiveDiff/Microsoft.DotNet.SourceBuild.Tasks.SdkArchiveDiff.csproj
Show resolved
Hide resolved
…eBuild.Tasks.SdkArchiveDiff/Microsoft.DotNet.SourceBuild.Tasks.SdkArchiveDiff.csproj Co-authored-by: Viktor Hofer <[email protected]>
…eBuild.Tasks.SdkArchiveDiff/Microsoft.DotNet.SourceBuild.Tasks.SdkArchiveDiff.csproj Co-authored-by: Viktor Hofer <[email protected]>
|
This isn't currently fully running in any CI pipelines since the sdk repo is still excluded in non-sourcebuild VMR builds and sourcebuild only runs on the centos.8-x64 rid. Is there a pipeline that runs the VMR in source-build mode with a portable RID? |
No, source-build is non-portable by definition. The sdk repository is already enabled in the unified-build. Do you mean the installer repo? That should soon be running as part of unified-build: #18632 |
|
Installer now builds live in the unified-build pipeline. |
…into TarballDiff
|
Looks like it found a few differences in the ubuntu release, adding a I'll fix the |
|
Interesting! /cc @ViktorHofer |
| <Error Text="Multiple valid dotnet-sdk archives found." | ||
| Condition="'@(_BuiltSdkArchivePath->Count())' != '1'" /> | ||
|
|
||
| <GetClosestOfficialSdk BuiltArchivePath="@(_BuiltSdkArchivePath)" |
There was a problem hiding this comment.
I would be surprised if this fails to find a matching SDK...does this happen?
There was a problem hiding this comment.
Are you referring to the Condition="'@(_BuiltSdkArchivePath)' != ''" or something else? I think we error in the tasks before we'd hit the conditions for GetClosestOfficialSdk and FindArchiveDiffs, so I'll remove the conditions.
There was a problem hiding this comment.
I would be surprised if the returned _ClosestOfficialSdkPath is empty.
There was a problem hiding this comment.
Gotcha, yeah that should never happen, we'll error out in the task first. I removed those conditions.
Co-authored-by: Viktor Hofer <[email protected]>
...ntent/eng/tools/tasks/Microsoft.DotNet.SourceBuild.Tasks.SdkArchiveDiff/GetClosestArchive.cs
Outdated
Show resolved
Hide resolved
| </_sdkFilesDiff> | ||
| <_sdkFilesDiff Include="@(_ContentDifferences)" Condition="'%(_contentDifferences.Kind)' == 'Unchanged'" > | ||
| <DiffIndicator> </DiffIndicator> | ||
| </_sdkFilesDiff> |
There was a problem hiding this comment.
I'm not sure having the Unchanged files is really valuable in the diff, it just makes the file larger than necessary and ideally if there's no diff the file would be empty/non-existing.
| </_sdkFilesDiff> | ||
| <_sdkFilesDiff Include="@(_ContentDifferences)" Condition="'%(_contentDifferences.Kind)' == 'Removed'" > | ||
| <DiffIndicator>-</DiffIndicator> | ||
| </_sdkFilesDiff> |
There was a problem hiding this comment.
Checking the Ubuntu run I see:
+ templates/{VERSION}/microsoft.dotnet.common.itemtemplates.{VERSION}.nupkg
+ sdk/{VERSION}/Containers/containerize/containerize.exe
- templates/{VERSION}/microsoft.dotnet.common.itemtemplates.{VERSION}.nupkg
- sdk/{VERSION}/Containers/containerize/containerize
- sdk/{VERSION}/DotnetTools/dotnet-watch/{VERSION}/tools/net9.0/any/runtimes/win/lib/net9.0/System.Diagnostics.EventLog.Messages.dll
The "templates" one doesn't make sense to me since it seems to be the same?
There was a problem hiding this comment.
Yeah, that one is weird. I wonder if it's related to having two Versions in the path? I'll look into it.
| </ItemGroup> | ||
|
|
||
| <PropertyGroup> | ||
| <SdkArchiveDiffsReport>$(ArtifactsLogDir)SdkArchiveContent.diff</SdkArchiveDiffsReport> |
There was a problem hiding this comment.
instead of .diff what if we generate xunit/mstest xml reports instead? those could be picked up by the AzDO test tab so we don't have to build custom UI.
Adds a task to validate that the final sdk archive has the same files as the daily installer builds. It will download the latest daily build from the same aka.ms links found in the installer table, so it's not a perfect version match, but it should be accurate enough. It also will only report any differences as messages, it won't fail the build.
Part of the fix for dotnet/source-build#4119