Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add exclusion support to source-build SDK tests #15650

Merged

Conversation

NikolaMilosavljevic
Copy link
Member

Fixes dotnet/source-build#3266

This adds support for exclusions in SDK diffing tests. The initial change adds 3 exclusions, for directories that are primary causes of maintenance issues with SDK tests. These directories are only present in one SDK (Microsoft or source-build) and cause test failure whenever there are new, or deleted, files in those directory trees.

Microsoft-only directories:

./sdk/x.y.z/TestHostNetFramework/?*
./sdk/x.y.z/Sdks/Microsoft.NET.Sdk.WindowsDesktop/?*

Source-build only directories:

./sdk/x.y.z/TestHost/?*

Exclusion list is processed using FileSystemName.MatchesSimpleExpression which supports simple file-matching wildcards.

In the example above, we intentionally use ?* and not just * - we want to keep the directory entry in the diff, so that the test fails if any of these directories get removed, or added to the SDK that is not carrying it today, i.e. if ./sdk/x.y.z/Sdks/Microsoft.NET.Sdk.WindowsDesktop/ gets added to source-build SDK.

Additional opportunities

We could add more exclusions. Here are some examples:

Microsoft-only directory that should never be added to source-build SDK:
./sdk/x.y.z/Sdks/Microsoft.NET.Sdk.Publish/tools/net472/?*

Localized content under ./sdk/x.y.z/Extensions/, i.e. ./sdk/x.y.z/Extensions/cs/?* This issue will be fixed - tracked in microsoft/vstest#4305


File.WriteAllLines(outputFileName, files);
}

private static IEnumerable<string> FilteredFileList(IEnumerable<string> files, IEnumerable<string> exclusions)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To follow standard naming conventions, the method name should contain a verb. Perhaps including the Exclusion term would help the readability as it indicates what filter is being applied.

Suggested change
private static IEnumerable<string> FilteredFileList(IEnumerable<string> files, IEnumerable<string> exclusions)
private static IEnumerable<string> RemoveExclusions(IEnumerable<string> files, IEnumerable<string> exclusions)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I'll update that. The idea was that the method returns a list that is filtered.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed with 9392ef3


File.WriteAllLines(outputFileName, files);
}

private static IEnumerable<string> FilteredFileList(IEnumerable<string> files, IEnumerable<string> exclusions)
{
return files
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider utilizing a expression bodied method here. It is a nice simplification IMO.

private static IEnumerable<string> FilteredFileList(IEnumerable<string> files, IEnumerable<string> exclusions) =>
    files.Where(item => !exclusions.Any(p => FileSystemName.MatchesSimpleExpression(p, item)));

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good - will update.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed with 9392ef3

files,
GetExclusionFilters(
Path.Combine(BaselineHelper.GetAssetsDirectory(), "SdkDiffExclusions.txt"),
tarballPath == Config.MsftSdkTarballPath ? "msft" : "sb"));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breaks the roles and responsibilities of the method and hard codes it to a specific tarballPath. If the caller ever changes the path, this implementation will break. I think it would be better to pass sdkType into WriteTarballFileList as a parameter.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to avoid adding an extra parameter. But, I will add a simple string parameter to indicate the sdk type.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed with 9392ef3


private static IEnumerable<string> GetExclusionFilters(string exceptionFilePath, string sdkType)
{
var text = File.ReadAllText(exceptionFilePath);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider utilizing ReadAllLines instread of having the code perform the line splitting.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed with 9392ef3


private static IEnumerable<string> GetExclusionFilters(string exceptionFilePath, string sdkType)
{
string[] lines = File.ReadAllLines(exceptionFilePath);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For brevity, consider in-lining below

return File.ReadAllLines(exceptionFilePath)
                .Where(line => line.StartsWith(sdkType + ",")) // process only specific sdk exclusions
                .Select(line =>
                {
                    // Ignore comments
                    var index = line.IndexOf('#');
                    return index >= 0 ? line[prefixSkip..index].TrimEnd() : line[prefixSkip..];
                })
                .ToList();

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed with 0048bcd


# nuget localization is not available for Linux builds - https://github.com/NuGet/Home/issues/12440
msft,./sdk/x.y.z/*?/NuGet.*?.resources.dll
msft,./sdk/x.y.z/Sdks/NuGet.Build.Tasks.Pack/*?/NuGet.*?.resources.dll
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a few questions about the remaining diffs.

  1. Would it be appropriate to add an exclusion for the known diffs that are caused by ilmerge not being supported in source-build?
  2. The following differences are caused by Pull in MAUI repo(s) in order to source-build MAUI manifest nupkgs source-build#3242 and should be added as exclusions IMO.
-./sdk-manifests/x.y.z/microsoft.net.sdk.android/
-./sdk-manifests/x.y.z/microsoft.net.sdk.android/WorkloadManifest.json
-./sdk-manifests/x.y.z/microsoft.net.sdk.android/WorkloadManifest.targets
-./sdk-manifests/x.y.z/microsoft.net.sdk.ios/
-./sdk-manifests/x.y.z/microsoft.net.sdk.ios/WorkloadManifest.json
-./sdk-manifests/x.y.z/microsoft.net.sdk.ios/WorkloadManifest.targets
-./sdk-manifests/x.y.z/microsoft.net.sdk.maccatalyst/
-./sdk-manifests/x.y.z/microsoft.net.sdk.maccatalyst/WorkloadManifest.json
-./sdk-manifests/x.y.z/microsoft.net.sdk.maccatalyst/WorkloadManifest.targets
-./sdk-manifests/x.y.z/microsoft.net.sdk.macos/
-./sdk-manifests/x.y.z/microsoft.net.sdk.macos/WorkloadManifest.json
-./sdk-manifests/x.y.z/microsoft.net.sdk.macos/WorkloadManifest.targets
-./sdk-manifests/x.y.z/microsoft.net.sdk.maui/
-./sdk-manifests/x.y.z/microsoft.net.sdk.maui/WorkloadManifest.json
-./sdk-manifests/x.y.z/microsoft.net.sdk.maui/WorkloadManifest.targets
-./sdk-manifests/x.y.z/microsoft.net.sdk.tvos/
-./sdk-manifests/x.y.z/microsoft.net.sdk.tvos/WorkloadManifest.json
-./sdk-manifests/x.y.z/microsoft.net.sdk.tvos/WorkloadManifest.targets
  1. Do you have an understanding of what the cause is of the following two resource.dll diffs are?
    ./sdk/x.y.z/cs/Microsoft.Build.NuGetSdkResolver.resources.dll

If you don't know now that is fine. I think issues should be logged if they don't already exist for the remaining entries in the baseline.
./sdk/x.y.z/cs/Microsoft.CodeCoverage.IO.resources.dll

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll address 1st and 2nd points. I'm not 100% sure if 3rd is related to NuGet-repo localization - will check and include it if it is - same for Microsoft.CodeCoverage.IO.resources.dll.

private static IEnumerable<string> RemoveExclusions(IEnumerable<string> files, IEnumerable<string> exclusions) =>
files.Where(item => !exclusions.Any(p => FileSystemName.MatchesSimpleExpression(p, item)));

private static IEnumerable<string> GetExclusionFilters(string exceptionFilePath, string sdkType)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Consider renaming exceptionFilePath to exclusionsFilePath for consistency.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed with 93d517d

Copy link
Member

@MichaelSimons MichaelSimons left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - as a follow-up, please log issue(s) for the remaining unexplained differences in the baseline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor SdkContentTests to be less fragile and provide more value
3 participants