-
Notifications
You must be signed in to change notification settings - Fork 447
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 sourcelink tests #17309
Add sourcelink tests #17309
Conversation
src/SourceBuild/content/test/Microsoft.DotNet.SourceBuild.SmokeTests/Utilities.cs
Outdated
Show resolved
Hide resolved
src/SourceBuild/content/test/Microsoft.DotNet.SourceBuild.SmokeTests/SourcelinkTests.cs
Outdated
Show resolved
Hide resolved
src/SourceBuild/content/test/Microsoft.DotNet.SourceBuild.SmokeTests/SourcelinkTests.cs
Outdated
Show resolved
Hide resolved
src/SourceBuild/content/test/Microsoft.DotNet.SourceBuild.SmokeTests/SourcelinkTests.cs
Outdated
Show resolved
Hide resolved
string[] files = Directory.GetFiles(Path.GetDirectoryName(Config.SourceBuiltArtifactsPath), runtimeSymbolsPackageNamePattern, SearchOption.AllDirectories); | ||
Assert.True(files.Length > 0, "Did not find runtime symbols archive"); | ||
|
||
yield return files[0]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is the return type IEnumerable<string>
but only ever returning one item?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll be updating this code soon, to enumerate all symbols archives.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this work still pending?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is coming up very soon. PR for creating symbols archives will be out today or tomorrow. Update to sourcelink validation to consume those archives will follow few days later, barring any unforeseen issues.
src/SourceBuild/content/test/Microsoft.DotNet.SourceBuild.SmokeTests/SourcelinkTests.cs
Show resolved
Hide resolved
…eTests/Utilities.cs Co-authored-by: Matt Thalman <mthalman@microsoft.com>
@@ -17,10 +17,14 @@ internal static class ExecuteHelper | |||
string args, | |||
ITestOutputHelper outputHelper, | |||
bool logOutput = false, | |||
bool logInfo = true, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Default parameters should be named in such a way that the default value is the type's default value. Therefor this parameter's default value should be false and therefore name should be inverted.
bool logInfo = true, | |
bool excludeInfo = false, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - will fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 72aacfc
Action<Process>? configureCallback = null, | ||
int millisecondTimeout = -1) | ||
{ | ||
outputHelper.WriteLine($"Executing: {fileName} {args}"); | ||
if (logInfo) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Later on there is some more info logged. Should it be conditioned on this parameter as well?
outputHelper.WriteLine($"Process did not exit. Killing {fileName} {args} after waiting {millisecondTimeout} milliseconds.");
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I consider that one an error message, and only wanted to provide an option to skip logging info/status messages.
/// <summary> | ||
/// Verifies that all symbols have valid sourcelinks. | ||
/// </summary> | ||
[SkippableFact(Config.ExcludeSourcelinkEnv, skipOnTrueEnv: true)] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the scenario for excluding these tests? I am trying to understand the need for the environment variable to exclude them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Time savings, mostly. It shouldn't be an issue today and probably unnecessary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
xunit/dotnet already supports a mechanism to run a subset of tests via the --filter option. That is what I utilize in my dev scenarios. We use ENVs only for CI configuration purposes. I think this should be removed as we intend to run this all of the time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 72aacfc
/// Extracts the dotnet-sourcelink tool package from PSB arhive. | ||
/// </summary> | ||
/// <returns>Path to sourcelink tool binary.</returns> | ||
private string GetSourcelinkToolPath() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does a lot more than retrieve the sourcelink tool path. Naming this to something like InitializeSourceLinkTool
feels more appropriate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it does a lot more, today. Sourcelink tool might become part of SDK in the future and the method name would still be the same if we modify its contents.
However, I agree that your proposed name is more generic. Will fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 72aacfc
|
||
public class SourcelinkTests : SmokeTests | ||
{ | ||
private static string SourcelinkRoot { get; } = Path.Combine(Directory.GetCurrentDirectory(), "sourcelink"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider using a name that associates the directory directly with the tests that create them.
private static string SourcelinkRoot { get; } = Path.Combine(Directory.GetCurrentDirectory(), "sourcelink"); | |
private static string SourcelinkRoot { get; } = Path.Combine(Directory.GetCurrentDirectory(), nameof(SourcelinkTests)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've followed the existing patterns in this codebase, i.e.:
installer/src/SourceBuild/content/test/Microsoft.DotNet.SourceBuild.SmokeTests/OmniSharpTests.cs
Line 24 in 8bdf61a
private string OmniSharpDirectory { get; } = Path.Combine(Directory.GetCurrentDirectory(), "omnisharp"); |
However, this is an easy fix and will update it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah - yes, I think both instances should be updated - your call.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 72aacfc
|
||
foreach (string file in failedFiles) | ||
{ | ||
OutputHelper.WriteLine($"Failed sourcelink verification: {file}"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a general suggestion that can I find helpful is to emit a header and put the files alone on separate lines. This is helpful for copy/paste specifically.
Sourcelink Verification Failures:
FilePath1
FilePath2
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes - I did think of this option, but never got to implementing it. Will do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 72aacfc
private string GetSourcelinkToolPath() | ||
{ | ||
const string SourcelinkToolPackageNamePattern = "dotnet-sourcelink*nupkg"; | ||
const string SourcelinkToolBinaryFilenamePattern = "dotnet-sourcelink.dll"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What makes this a pattern? It appears to be the actual filename.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, true - copy/paste issue. Will update - thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 72aacfc
|
||
string toolPackageDir = Directory.CreateDirectory(Path.Combine(SourcelinkRoot, "sourcelink-tool")).FullName; | ||
Utilities.ExtractTarball(Config.SourceBuiltArtifactsPath, toolPackageDir, SourcelinkToolPackageNamePattern); | ||
string[] files = Directory.GetFiles(toolPackageDir, SourcelinkToolPackageNamePattern, SearchOption.AllDirectories); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This pattern appears to be used three times. Consider making a shared Utility method for it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quoted code shows tarball extraction which appears twice. Are you suggesting a Utility method for the pattern that follows the extraction - getting a single file and failing if there are 0 or more than 1?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry my comment was not very clear. I am referring to this pattern:
files = Directory.GetFiles(extractedToolPath, SourcelinkToolBinaryFilenamePattern, SearchOption.AllDirectories);
Assert.False(files.Length > 1, $"Unexpected - found more than one sourcelink tool binary with filename pattern: {SourcelinkToolBinaryFilenamePattern}");
Assert.False(files.Length == 0, $"Did not find sourcelink tool binary with expected filename pattern: {SourcelinkToolBinaryFilenamePattern}");
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this. One of the instances is going away in the near future, when we start using Symbols archives. The code gets harder to read, line lengths balloon, or line breaks get introduced that just invite bugs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For clarity this is what I mean. Usage Utility.GetFile(path, pattern)
public static string GetFile(string path, string pattern)
{
files = Directory.GetFiles(path, pattern, SearchOption.AllDirectories);
Assert.False(files.Length > 1, $"Found multiple files matching the pattern {pattern}
: {Enivronment.NewLine}{string.Join(files, Enivronment.NewLine)}");
Assert.False(files.Length == 0, $"Did not find any files matching the pattern {pattern}
");
return file[0];
}
To me it actually helps the readability of the code because it simplifies this method.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that would be a generic simplification,. I wanted to provide a way to supply, and use, custom messages, which bloated the code in the caller method, and made it almost unreadable.
I'll do the suggested solution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with c499278
return symbolsRoot; | ||
} | ||
|
||
private IList<string> ValidateAllFiles(string path, string sourcelinkToolPath) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renaming this in terms of symbols would help the readability IMO.
private IList<string> ValidateAllFiles(string path, string sourcelinkToolPath) | |
private IList<string> ValidateSymbols(string path, string sourcelinkToolPath) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - will update this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 72aacfc
/// Extracts packages to subdirectories of the common symbols root directory. | ||
/// </summary> | ||
/// <returns>Path to common symbols root directory.</returns> | ||
private string ExtractPackages(IEnumerable<string> packages) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renaming this in terms of symbols would help the readability and be more consistent with GetAllSymbolsPackages IMO.
private string ExtractPackages(IEnumerable<string> packages) | |
private string ExtractSymbolPackages(IEnumerable<string> packages) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks - will update this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed with 72aacfc
Fixes: dotnet/source-build#3052
For now, we process just the runtime symbols as they are available in source-build artifacts. After PDB work is done, we'll modify the code in
GetAllSymbolsPackages()
to discover all symbols archives. That work is tracked with: dotnet/source-build#3612PDB work has the following related issues: dotnet/source-build#3547, dotnet/source-build#3609, dotnet/source-build#3610