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 sourcelink tests #17309

Conversation

NikolaMilosavljevic
Copy link
Member

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#3612

PDB work has the following related issues: dotnet/source-build#3547, dotnet/source-build#3609, dotnet/source-build#3610

@NikolaMilosavljevic NikolaMilosavljevic requested a review from a team as a code owner September 5, 2023 21:03
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];
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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?

Copy link
Member Author

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.

@@ -17,10 +17,14 @@ internal static class ExecuteHelper
string args,
ITestOutputHelper outputHelper,
bool logOutput = false,
bool logInfo = true,
Copy link
Member

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.

Suggested change
bool logInfo = true,
bool excludeInfo = false,

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks - will fix.

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 72aacfc

Action<Process>? configureCallback = null,
int millisecondTimeout = -1)
{
outputHelper.WriteLine($"Executing: {fileName} {args}");
if (logInfo)
Copy link
Member

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.");

Copy link
Member Author

@NikolaMilosavljevic NikolaMilosavljevic Sep 6, 2023

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)]
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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.

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 72aacfc

/// Extracts the dotnet-sourcelink tool package from PSB arhive.
/// </summary>
/// <returns>Path to sourcelink tool binary.</returns>
private string GetSourcelinkToolPath()
Copy link
Member

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.

Copy link
Member Author

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.

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 72aacfc


public class SourcelinkTests : SmokeTests
{
private static string SourcelinkRoot { get; } = Path.Combine(Directory.GetCurrentDirectory(), "sourcelink");
Copy link
Member

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.

Suggested change
private static string SourcelinkRoot { get; } = Path.Combine(Directory.GetCurrentDirectory(), "sourcelink");
private static string SourcelinkRoot { get; } = Path.Combine(Directory.GetCurrentDirectory(), nameof(SourcelinkTests));

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've followed the existing patterns in this codebase, i.e.:

private string OmniSharpDirectory { get; } = Path.Combine(Directory.GetCurrentDirectory(), "omnisharp");

However, this is an easy fix and will update it.

Copy link
Member

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.

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 72aacfc


foreach (string file in failedFiles)
{
OutputHelper.WriteLine($"Failed sourcelink verification: {file}");
Copy link
Member

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
...

Copy link
Member Author

@NikolaMilosavljevic NikolaMilosavljevic Sep 6, 2023

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.

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 72aacfc

private string GetSourcelinkToolPath()
{
const string SourcelinkToolPackageNamePattern = "dotnet-sourcelink*nupkg";
const string SourcelinkToolBinaryFilenamePattern = "dotnet-sourcelink.dll";
Copy link
Member

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.

Copy link
Member Author

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!

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 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);
Copy link
Member

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.

Copy link
Member Author

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?

Copy link
Member

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}");

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'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.

Copy link
Member

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.

Copy link
Member Author

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.

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 c499278

return symbolsRoot;
}

private IList<string> ValidateAllFiles(string path, string sourcelinkToolPath)
Copy link
Member

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.

Suggested change
private IList<string> ValidateAllFiles(string path, string sourcelinkToolPath)
private IList<string> ValidateSymbols(string path, string sourcelinkToolPath)

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks - will update this.

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 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)
Copy link
Member

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.

Suggested change
private string ExtractPackages(IEnumerable<string> packages)
private string ExtractSymbolPackages(IEnumerable<string> packages)

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks - will update this.

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 72aacfc

@NikolaMilosavljevic NikolaMilosavljevic enabled auto-merge (squash) September 6, 2023 21:41
@NikolaMilosavljevic NikolaMilosavljevic merged commit 9a21558 into dotnet:release/8.0.1xx Sep 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants