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

Check PublishData.json feeds #72333

Merged
merged 3 commits into from
Mar 14, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 41 additions & 1 deletion src/Tools/BuildBoss/CompilerNuGetCheckerUtil.cs
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@
using System.Reflection.PortableExecutable;
using System.Security.Cryptography;
using System.Text.RegularExpressions;
using Newtonsoft.Json.Linq;

namespace BuildBoss
{
Expand Down Expand Up @@ -72,6 +73,7 @@ public bool Check(TextWriter textWriter)
try
{
var allGood = true;
allGood &= CheckPublishData(textWriter);
allGood &= CheckPackages(textWriter);
allGood &= CheckExternalApis(textWriter);
return allGood;
Expand All @@ -83,6 +85,44 @@ public bool Check(TextWriter textWriter)
}
}

/// <summary>
/// Verify PublishData.json contains feeds for all packages that will be published.
/// </summary>
private bool CheckPublishData(TextWriter textWriter)
{
var allGood = true;

// Load PublishData.json
var publishDataPath = Path.Combine(RepositoryDirectory, "eng", "config", "PublishData.json");
var publishDataRoot = JObject.Parse(File.ReadAllText(publishDataPath));
var publishDataPackages = publishDataRoot["packages"]["default"] as JObject;

// Check all shipping packages have an entry in PublishData.json
var regex = new Regex(@"^(.*?)\.\d.*\.nupkg$");
var packagesDirectory = Path.Combine(ArtifactsDirectory, "packages", Configuration, "Shipping");
foreach (var packageFullPath in Directory.EnumerateFiles(packagesDirectory, "*.nupkg"))
{
var packageFileName = Path.GetFileName(packageFullPath);
var match = regex.Match(packageFileName);
if (!match.Success)
{
allGood = false;
textWriter.WriteLine($"Unexpected package file name '{packageFileName}'");
}
else
{
var packageId = match.Groups[1].Value;
if (!publishDataPackages.ContainsKey(packageId))
{
allGood = false;
textWriter.WriteLine($"Package doesn't have corresponding PublishData.json entry: {packageId} ({packageFileName})");
}
}
}

return allGood;
}

/// <summary>
/// Verify the contents of the compiler packages match the expected input
/// </summary>
Expand Down Expand Up @@ -360,7 +400,7 @@ void verifyFolder(string folderRelativeName)
}

// As a simplification we only validate the assembly names that begin with Microsoft.CodeAnalysis. This is a good
// hueristic for finding assemblies that we build. Can be expanded in the future if we find more assemblies that
// heuristic for finding assemblies that we build. Can be expanded in the future if we find more assemblies that
// are worth validating here.
var neededDllNames = neededDllNameSet
.Where(x => x.StartsWith("Microsoft.CodeAnalysis"))
Expand Down
2 changes: 1 addition & 1 deletion src/Tools/BuildBoss/ProjectCheckerUtil.cs
Original file line number Diff line number Diff line change
Expand Up @@ -174,7 +174,7 @@ private bool CheckDeploymentSettings(TextWriter textWriter)

/// <summary>
/// It's important that every reference be included in the solution. MSBuild does not necessarily
/// apply all configuration entries to projects which are compiled via referenes but not included
/// apply all configuration entries to projects which are compiled via references but not included
/// in the solution.
/// </summary>
private bool CheckProjectReferencesComplete(TextWriter textWriter, IEnumerable<ProjectKey> declaredReferences)
Expand Down
8 changes: 4 additions & 4 deletions src/Tools/BuildBoss/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ This is a tool to validate the state of our solutions, project files and other b
> BuildBoss.exe <solution / project / targets path / build log paths>
```

This tool is run on every CI job against our important solution files: [Roslyn.sln](https://github.com/dotnet/roslyn/blob/main/Roslyn.sln), and [CrossPlatform.sln](https://github.com/dotnet/roslyn/blob/main/CrossPlatform.sln).
This tool is run on every CI job against our important solution files: [Roslyn.sln](https://github.com/dotnet/roslyn/blob/main/Roslyn.sln).

Violations reported are important to fix as they represent correctness issues in our build. Many of the properties verified represent problems that otherwise won't be verified at check in time.

Expand Down Expand Up @@ -39,13 +39,13 @@ There are a number of properties which are simply unnecessary for build. They a

### Transitive references

Projects which represent full deployments must have a complete set of project references declared in the project file. Or in other words the declared set of project references much match the tranistive closure of project references. Any gap between the two sets won't be deployed on build which in turn will break F5, testing, etc ...
Projects which represent full deployments must have a complete set of project references declared in the project file. Or in other words the declared set of project references much match the transitive closure of project references. Any gap between the two sets won't be deployed on build which in turn will break F5, testing, etc ...

### Classifying projects

Our build process depends on being able to correctly classify our projects: exe, VSIX, dll, etc ... This can typically be inferred from properties like OutputType. But in other occasions it requires a more declarative entry via the `<RoslynProjectType>` property. The tool will catch places where projects are incorrectly classified.

This could be done using MSBuild targets but the logic is hard to follow and complicates the build. It's easier and more readable to have a declaritive entry in the file.
This could be done using MSBuild targets but the logic is hard to follow and complicates the build. It's easier and more readable to have a declarative entry in the file.

## Solution Content Verified

Expand All @@ -57,7 +57,7 @@ This is best demonstrated by example. Consider the following setup:
- Project App.csproj produces App.exe and references Util.csproj
- Solution App.sln includes App.csproj only

Now consider when App.sln is build with the following command line:
Now consider when App.sln is built with the following command line:

``` cmd
msbuild /p:Configuration=Release App.sln
Expand Down
Loading