Check PublishData.json feeds (#72333)

* Update BuildBoss docs

* Check PublishData.json

Author: jjonescz

src/Tools/BuildBoss/CompilerNuGetCheckerUtil.cs

@@ -15,6 +15,7 @@
 using System.Reflection.PortableExecutable;
 using System.Security.Cryptography;
 using System.Text.RegularExpressions;
+using Newtonsoft.Json.Linq;
 
 namespace BuildBoss
 {
@@ -72,6 +73,7 @@ public bool Check(TextWriter textWriter)
             try
             {
                 var allGood = true;
+                allGood &= CheckPublishData(textWriter);
                 allGood &= CheckPackages(textWriter);
                 allGood &= CheckExternalApis(textWriter);
                 return allGood;
@@ -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>
@@ -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"))

src/Tools/BuildBoss/ProjectCheckerUtil.cs

@@ -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)

src/Tools/BuildBoss/README.md

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