Fail CI build if there are any non-baselined API changes

[AndriySvyryd]

• Added the new EFCore.ApiBaseline.Tests project that will fail on CI if any baseline is outdated and silently update it when run locally.
• Removed the script-based baselining.
• Updated .baseline.json files for EFCore.Cosmos, EFCore.Relational, EFCore.SqlServer, and EFCore to reflect new, changed, or removed API members and types.
• Enhanced the API diff reporting tool (ApiChief) to:
  • Track and mark types as new or removed to produce more accurate diff output.
  • Include unchanged members in diff output when stage is changed.

[Copilot]

Pull request overview

Updates CI pipelines to use the repo’s build.cmd/build.sh entrypoints so that API baseline generation/delta checking runs during CI and fails the build when API changes aren’t baselined.

Changes:

• Switched public pipeline build steps from eng/common/cibuild.* to ./build.* so CI runs tools/MakeApiBaselines.ps1.
• Switched the internal-tests Windows build step from eng\common\cibuild.cmd to build.cmd to align with the new API baseline enforcement path.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
azure-pipelines-public.yml	Uses repo build.cmd/build.sh in public CI builds, enabling API baseline enforcement.
azure-pipelines-internal-tests.yml	Updates the internal Windows build to use build.cmd, which runs API baseline checks.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 26 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 31 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

eng/Tools/ApiChief/Model/ApiType.cs:30

• Changing ApiType to public makes its shape part of ApiChief's public surface area, including the public mutable fields (Methods, Fields, Properties). If these types are only being made public to support the new test project, consider keeping them internal and adding InternalsVisibleTo for the test assembly (or exposing a narrower public API) to avoid locking in these implementation details.

public sealed class ApiType : IEquatable<ApiType>
{
    [JsonIgnore]
    public string FullTypeName { get; set; } = string.Empty;

    [JsonPropertyOrder(0)]
    public string Type { get; set; } = string.Empty;

    [JsonPropertyOrder(1)]
    [JsonIgnore(Condition = JsonIgnoreCondition.WhenWritingDefault)]
    public ApiStage Stage { get; set; }

    [JsonPropertyOrder(2)]
    public ISet<ApiMember>? Methods;

    [JsonPropertyOrder(3)]
    public ISet<ApiMember>? Fields;

    [JsonPropertyOrder(4)]
    public ISet<ApiMember>? Properties;

[roji]

Added the new EFCore.ApiBaseline.Tests project that will fail on CI if any baseline is outdated and silently update it when run locally.

I'd prefer it if the project failed locally as well, and to just run an explicit command to update it.

BTW consider adding info on how all this works in the repo instructions file, for agents (and for Shay...).

[AndriySvyryd]

I'd prefer it if the project failed locally as well, and to just run an explicit command to update it.

Why? How often do you introduce or change public API unintentionally? You will still clearly see the baseline changes after the test is run. Adding an extra step seems would just slow you down (and add frustration) without any benefit for the vast majority of cases.

[roji]

How often do you introduce or change public API unintentionally?

It happens; after all, one of the points of having public API baselines (and a setup to fail if the baseline isn't aligned to the source) is precisely to protect against unintentional public API changes. Public API changes feel important enough that they should involve an intentional gesture. I also kinda dislike the same thing doing one thing in CI and a different thing locally (e.g. more difficult to debug/understand when things go wrong).

No super strong feelings though, if you really care I'm OK with your way too.

[github-actions]

API review baseline changes for src/EFCore.Relational/EFCore.Relational.baseline.json

The diff below was generated by ApiChief between the base and selected PR versions.

+ class Microsoft.EntityFrameworkCore.Diagnostics.MigrationVersionEventData : Microsoft.EntityFrameworkCore.Diagnostics.DbContextTypeEventData
+ virtual string? MigrationVersionEventData.MigrationVersion { get; }
+ MigrationVersionEventData.MigrationVersionEventData(EventDefinitionBase eventDefinition, Func<EventDefinitionBase, EventData, string> messageGenerator, Type contextType, string? migrationVersion);

  static class Microsoft.EntityFrameworkCore.Diagnostics.RelationalEventId
+ static readonly Microsoft.Extensions.Logging.EventId Microsoft.EntityFrameworkCore.Diagnostics.RelationalEventId.OldMigrationVersionWarning

  static class Microsoft.EntityFrameworkCore.Diagnostics.RelationalLoggerExtensions
+ static void RelationalLoggerExtensions.OldMigrationVersionWarning(this IDiagnosticsLogger<Migrations> diagnostics, Type contextType, string? migrationVersion);

API review baseline changes for src/EFCore.SqlServer/EFCore.SqlServer.baseline.json

The diff below was generated by ApiChief between the base and selected PR versions.

  static class Microsoft.EntityFrameworkCore.SqlServerQueryableExtensions
- static IQueryable<VectorSearchResult<T>> SqlServerQueryableExtensions.VectorSearch<T, TVector>(this DbSet<T> source, Expression<Func<T, TVector>> vectorPropertySelector, TVector similarTo, string metric, int topN);
+ static IQueryable<VectorSearchResult<T>> SqlServerQueryableExtensions.VectorSearch<T, TVector>(this DbSet<T> source, Expression<Func<T, TVector>> vectorPropertySelector, TVector similarTo, string metric);

API review baseline changes for src/EFCore/EFCore.baseline.json

The diff below was generated by ApiChief between the base and selected PR versions.

  class Microsoft.EntityFrameworkCore.Query.LiftableConstantProcessor : System.Linq.Expressions.ExpressionVisitor, Microsoft.EntityFrameworkCore.Query.ILiftableConstantProcessor
- override Expression LiftableConstantProcessor.VisitMember(MemberExpression memberExpression);

  class Microsoft.EntityFrameworkCore.Storage.Json.JsonReaderData
- JsonReaderData.JsonReaderData(byte[] buffer);
+ JsonReaderData.JsonReaderData(ReadOnlyMemory<byte> buffer);