Test review Core I-J

[paulirwin]

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a change, please open an issue to discuss the change or find an existing issue.

Partial work for #259 for the core I-J tests assembly.

[NightOwl888]

Thanks for the PR.

There are a few requested changes as well as some other feedback.

[NightOwl888]

It looks like there were a couple of omissions.

1. This line will need to be reenabled to prevent the NONE option from being passed.
2. This line will need to be fixed to exclude the NONE option from being tested. Here is how we do it elsewhere.

I am still torn on whether to just hide the NONE option from users because it really isn't a thing anywhere but in the FindMerges() method and it isn't very likely users would enable asserts to find out that they are passing something that isn't valid to calls to other methods that accept MergeTrigger. We could add guard clauses to all of those methods to make it fail without enabling asserts, but it is much simpler just to make it invisible.

[NightOwl888]

I setup a new repository with our Azure DevOps templates and discovered that there are some breaking changes.

Breaking Change 1

There is a breaking change introduced by Microsoft in the .NET 8 SDK, which appends the Git commit hash to the AssemblyInformationalVersion: dotnet/sdk#34568. We already add a shortened Git commit hash, so this will add it twice. The fix should definitely be in this PR, since this is where we introduce building with the .NET 8 SDK.

More info about it is here: https://learn.microsoft.com/en-us/dotnet/core/compatibility/sdk/8.0/source-link. I have tested the solution and it seems to meet our needs. However, the first build after I changed it caused the NuGet packages to be built without any DLLs in them, but the second build succeeded. Not sure whether that was a fluke or a problem.

We can put the fix in the default Directory.Build.targets file of the solution (in each repository):

  <PropertyGroup Label="Versioning">
    <GenerateAssemblyVersionInfo>false</GenerateAssemblyVersionInfo>
  </PropertyGroup>

Breaking Change 2

The default for a new pipeline in Azure DevOps is to create a shallow clone. Previously, it would create a deep clone by default.

This doesn't break anything on Lucene.Net, but all of the other repositories that we own use NerdBank.GitVersioning, and this is a problem for generating the correct version number. There is an issue about it here: dotnet/Nerdbank.GitVersioning#837 and the fix is here: https://github.com/dotnet/Nerdbank.GitVersioning/blob/main/doc/cloudbuild.md#azure-pipelines

We would need to apply that on the "Build" job of all of our repositories. On Lucene.NET, it is already done this way for performance reasons.

Our Other Repositories

This is a list of all of the repositories that use the same Azure DevOps (and command line build) templates that will need to be patched to account for this.

• J2N
• ICU4N
• RandomizedTesting
• Spatial4n
• Morfologik.Stemming
• NetFx.Polyfills (fixes already applied)

While we could just fix the issue in this PR and add 2 issues to each of the other repositories, I think it might be simpler just to submit a PR to each repository with the patches and a link back to this PR.

[paulirwin]

@NightOwl888 Thanks for the info and research! I think your comment was intended for PR #930 though?

[NightOwl888]

@NightOwl888 Thanks for the info and research! I think your comment was intended for PR #930 though?

@paulirwin - You are absolutely right. I goofed. I will re-post over there. Also, I realized I missed one.