Added build automation, documentation, and other upgrades#1
Conversation
…ckages.props files to share common settings and enable Central Package Management.
…zed packaging for analyzers, code fixes, and the sample project
… as .folderproj (NoTargets) projects that allow the IDE to edit the underlying file structure
…rectory.Build.props files to src and tests folders
…ugging documentation
…deAnalysis.Dev.CodeFixes.Tests
…de generation so it is not a committed file
…uild title based off of localized resource and actual code element.
… make use of shared TryGetJ2NTypeAndMember() method to reduce duplicated code.
…kageReference on Microsoft.CodeAnalysis.CSharp
…tead of properties for DiagnosticDescriptors or the AnalyzerReleases release management analyzers do not recognize the diagnositic ids as being implemented.
…Files, as it is only necessary if these are needed within one of our analyzers
…nto organizational LuceneDev1xxx folders.
…yzerReleases which require a specific format to be parsed)
…ression and PackageLicenseFile at the same time. Removed the PackageLicenseFile property, but kept the automation to pack the file into the NuGet package.
…es files to Solution Items
|
Alright. Since you haven't approved the run here yet, I did it over here: https://github.com/NightOwl888/lucenenet-codeanalysis-dev/actions/runs/17786867169. The CI and Powershell test automation runs fine. However, I discovered that I omitted the |
paulirwin
left a comment
There was a problem hiding this comment.
This is a partial review, I've only gotten through the build/eng files so far.
…a placeholder token {{vnext}} in the AnalyzerReleases.Shipped.md file, only if preceeded by "## Release ".
…to update AnalyzerReleases documents.
…rrected release branching info to show branches with 3 version components.
… patch, and prerelease when choosing a version number.
… state as the release-build-outcomes.svg file.
Release DocumentationAlright, I completely revamped the make-release.md document. While I didn't do an end to end test, I checked the For example, if we specify 3-component version numbers in the
I think that it would be sensible to keep the major version of this package aligned with the version of Lucene.NET, but bumping the major version is going to take some care to do because there are a couple of places where 1.x is hard coded.
Busting the VS cache is really hard to do, so maybe it would be best to stay on 1.x until we can dedicate the time to research how to make these version numbers dynamic. Anyway, I think anything else that needs to happen can occur after it is merged. Afterward, we should be able to do a release (and update the release procedure with any missing/unclear info in the process). This is ready for review. |
d4d3dc6
into
paulirwin:feature/initial-apache-release
* Upgrade NuGet packages, add Sample project and enable debugging, remove VSIX, fix unit tests and analyser warnings
* Add remaining samples
* Add github action file
* Fix comment generation in Resources.Designer.cs, remove from source control
* Rename unit test project
* Add more detail to analyzer titles
* Rename GitHub workflow file
* Change GitHub Actions triggers
* Add strong name key signing
* Add README and Diagnostic IDs reservations file
* Fix NuGet pack output path and settings
* Added Dirctory.Build.props, Directory.Build.targets. and Directory.Packages.props files to share common settings and enable Central Package Management.
* Added version.json file for Nerdbank.GitVersioning
* Added Lucene.Net.CodeAnalysis.Dev.Package project to provide centralized packaging for analyzers, code fixes, and the sample project
* Added Lucene.Net.CodeAnalysis.Dev.Vsix project for Visual Studio live debugging
* Renamed Helpers namespace to Utility
* Migrated DiagnosticDescriptor declarations to their own Descriptors class
* SWEEP: Converted all tests to use Microsoft.CodeAnalysis.Analyzer.Testing
* Lucene.Net.CodeAnalysis.Dev.sln: Added Solution Items folder
* Lucene.Net.CodeAnalysis.Dev.sln: Added .github, docs, and eng folders as .folderproj (NoTargets) projects that allow the IDE to edit the underlying file structure
* Moved Lucene.Net.snk file to the eng directory
* Lucene.Net.CodeAnalysis.Dev.sln: Added Directory.Build.targets and Directory.Build.props files to src and tests folders
* Added GitHub workflows for build/release automation
* docs: Added building-and-testing, make-release, and visual-studio-debugging documentation
* Added Powershell script to run the Release Audit Tool
* rat.ps1: Changed RAT version to 0.13, since that is what we know works
* SWEEP: Ran the Apache Release Audit Tool to add missing license headers
* docs/make-release.md: Added section for Release Audit Tool
* Added .editorconfig and .gitattributes for most often hand-edited files
* Added Lucene.Net.CodeAnalysis.Dev.CodeFixes project and Lucene.Net.CodeAnalysis.Dev.CodeFixes.Tests
* Lucene.Net.CodeAnalysis.Dev.CodeFixes: Fixed CodeFixResources.resx code generation so it is not a committed file
* LuceneDev1001_FloatingPointFormattingCSCodeFixProvider: Dynamically build title based off of localized resource and actual code element.
* LuceneDev1001_FloatingPointFormattingCSCodeFixProvider: Refactored to make use of shared TryGetJ2NTypeAndMember() method to reduce duplicated code.
* Lucene.Net.CodeAnalysis.Dev.CodeFixes.csproj: Removed unnecessary PackageReference on Microsoft.CodeAnalysis.CSharp
* tests/Directory.Build.targets: Set IsPublishable=true if IsTestProject is true
* Lucene.Net.CodeAnalysis.Dev.Tests.csproj: Enabled nullable reference type support
* Lucene.Net.CodeAnalysis.Dev.Utilty.Descriptors: Use static fields instead of properties for DiagnosticDescriptors or the AnalyzerReleases release management analyzers do not recognize the diagnositic ids as being implemented.
* Lucene.Net.CodeAnalysis.Dev: Cleaned up usings
* Lucene.Net.CodeAnalysis.Dev: Removed AnalyzerReleases from AdditionalFiles, as it is only necessary if these are needed within one of our analyzers
* SWEEP: Moved all analyzers, code fixes, and analyzer/code fix tests into organizational LuceneDev1xxx folders.
* SWEEP: Added Apache 2.0 license headers to all .props, .targets, and .*proj files
* SWEEP: Added Apache 2.0 license headers to all .yml and .ps1 files
* SWEEP: Added Apache 2.0 license headers to all .md files (except AnalyzerReleases which require a specific format to be parsed)
* eng/nuget.props: Added LICENSE.txt and NOTICE.txt to the NuGet package.
* eng/nuget.props: Resolved conflict - cannot specify PackageLicenseExpression and PackageLicenseFile at the same time. Removed the PackageLicenseFile property, but kept the automation to pack the file into the NuGet package.
* Lucene.Net.CodeAnalysis.Dev.sln: Added .editorconfig and .gitattributes files to Solution Items
* Added Git commit hook to insert the current NuGetPackageVersion into a placeholder token {{vnext}} in the AnalyzerReleases.Shipped.md file, only if preceeded by "## Release ".
* docs/make-release.md: Simplified release procedure and included step to update AnalyzerReleases documents.
* version.json: Updated version.json to enforce 3-component release branch numbers.
* docs/make-release: Added workflow for release build outcomes. Also corrected release branching info to show branches with 3 version components.
* docs/make-release.md: Added info about deciding between major, minor, patch, and prerelease when choosing a version number.
* release-build-outcomes.md: Updated Mermaid markup to reflect the same state as the release-build-outcomes.svg file.
* Markdown-Formatting.Tests.ps1: Removed stray assert
* .github/workflows/ci.yml: Removed x86 tests and SDK setup
* docs/make-release.md: Corrected slash in release branch notes
* docs/make-release.md: Added info about how to check the version of the current commit
* nuget.props: Converted to nuget.targets and added target to set <PackageReleaseNotes> after Nerdbank.GitVersioning injects the PackageVersion into the pipeline.
* renovate.json: Disabled dependency dashboard issue and enabled fork processing for Forking Renovate
* .github/workflows/renovate-dependencies.yml: deleted, since we will be using Forking Renovate and we probably won't be able to run this workflow, anyway.
* Lucene.Net.CodeAnalysis.Dev.Package.csproj: Removed conditions for CodeFixes project and fixed paths to include (future) code fix resource files in the package if we ever localize it.
* Lucene.Net.CodeAnalysis.Dev.Vsix/source.extension.vsixmanifest: Changed Publisher attribute to Apache Software Foundation
---------
Co-authored-by: Shad Storhaug <shad@shadstorhaug.com>
Since there were quite a few changes to add the automation to apache#1 that will definitely affect the ability to merge apache#2, I created a branch based off of feature/initial-apache-release with the changes. This will let you harmonize the 2 branches, or simply accept these changes, squash merge them into apache/lucenenet-codeanalysis-dev/main and then copy the changes out of apache#2 to their new home location.
Note that while I tested the automation fairly well in the SPDX.CodeAnalysis repository, the automation config was transferred without being run. So, there may need to be a few tweaks to get it up and running.
One thing in particular is that we need approval to enable Renovate, which can either run as a GitHub app or as a GitHub workflow. The app would be preferable, but I made a workflow because the app runs on a 3rd party server and Apache probably won't be receptive to it. Either way, we will need a PAT for it to run that will need to be set to the
RENOVATE_TOKENGitHub secret and we will need approval from INFRA.This adds build automation and upgrades the project to use the latest Roslyn features plus makes other updates.
.github,eng(engineering), anddocsin the IDE, which allows adding, renaming, or removing files without editing the.slnfileDescriptorsclass to define the analyzers as shared static fields to eliminate much of the repetitive boilerplate code when creating new analyzersMicrosoft.CodeAnalysis.Analyzer.TestingandMicrosoft.CodeAnalysis.CodeFix.Testingpackages, which use async tests, allow per-test dependency injection, and allow for more advanced configuration with less code than our previous approach.editorconfigand.gitattributessettings for xplat contributionsOther than the Renovate workflow mentioned above, all GitHub Actions tasks have been approved by INFRA.
Note that I didn't harmonize the debugging or build/test documentation with the README. In particular, Visual Studio users should be instructed to use the VSIX for debugging while Ryder users can use the
Sampleproject.I haven't yet worked out how to harmonize the sample project to be used when debugging inside of the Visual Studio test instance, since it requires there to be a solution to open that has similar classes that have code analysis violations to see it operate. The primary difference is that in Visual Studio, we can set breakpoints while it is running inside of the test instance which allows us to see how it works in reality rather than just plugging in a bunch of mocks during testing.