Repository navigation
10.x CI: run the EF Core suites on the newest EF Core / Npgsql 10 patch and the daily servicing builds, not only the floor #297
Description
Problem
The EF Core suites only ever run on the floor. src/CodoMetis.ValueRanges.EFCore.PostgreSQL references Npgsql.EntityFrameworkCore.PostgreSQL 10.0.0, which resolves EF Core 10.0.0, and .github/dependabot.yml ignores Microsoft.EntityFrameworkCore* and Npgsql* in test/*. A consumer resolves the newest patch. #288 came in through that gap: dotnet/efcore#39114 merged into release/10.0 on 2026-10-02, changes how every RangeSet.Contains query is preprocessed, and no run of this repository's CI will ever execute it.
Change
- A leg in
dotnet.ymlthat runs the EF translation projects and the integration projects (PostgreSQL 16 and 18, as CI matrix for two lines: .NET 10 and 11 SDKs, PostgreSQL floor and 18 legs per line #152 sets up) withMicrosoft.EntityFrameworkCore*andNpgsql.EntityFrameworkCore.PostgreSQLfloated to the newest published 10.0 patch, set from the command line (aDirectory.Buildoverride or-p:property), never by raising the shipping floor. A scheduled run (weekly is enough) of the same leg against the EF Core daily servicing builds forMoved to 10.x CI: run the EF suites weekly against EF Core's staged 10.0 servicing build (darc-pub feed), scheduled from main #312 (2026-10-19): therelease/10.0(the dncengdotnet10feed; the URL needs checking, it did not answer from a localcurlon 2026-10-19), so an upstream servicing change fails here before it is published.dotnet10feed holds only 10.0.0 prereleases, the servicing builds are on per-builddarc-pub-dotnet-dotnet-<sha>feeds, andschedulefires only frommain; see the comment below.- The floor legs stay the required check; the newest-patch leg is required too; the daily-build leg reports but does not block a PR (an upstream regression is not this repository's to fix, but it must be an issue the day it appears).
- On
main, the same leg floats the EF Core 11 previews and RCs (part of CI matrix for two lines: .NET 10 and 11 SDKs, PostgreSQL floor and 18 legs per line #152's matrix).
Done when
release/10.x CI runs the EF suites on the floor and on the newest published 10.0 patch (EF Core 10.0.13 / Npgsql EF 10.0.3 as of 2026-10-19; the leg reads the versions from one place so a new patch is a one-line bump), the scheduled daily-build run exists or this issue records why the feed is unreachable, and reverting the #302 fix fails the newest-patch leg while the floor leg stays green — the exact check that found #302. The floor leg and the newest-patch leg are both required.
Not a gate: when EF Core 10.0.15 is published, the #288 seed (reverting the RangeSetContains rewrite) is run against it on this leg and the result recorded on #288.
Activity
CaffeinatedCoder commentedon Oct 19, 2026
A one-off version of this leg ran on 2026-10-19 against
release/10.x(d47d9a3) and found #302 on its first run, so the mechanism works and is worth keeping:test/Directory.Build.targets(the repository has no rootDirectory.Build.targets, so nothing is shadowed) with oneItemGroupunderCondition="'$(EfFloat)' != '' and $(MSBuildProjectName.Contains('EFCore'))"thatIncludesMicrosoft.EntityFrameworkCore,Microsoft.EntityFrameworkCore.Relational,Npgsql.EntityFrameworkCore.PostgreSQLandNpgsql.EntityFrameworkCore.PostgreSQL.NodaTimeat$(EfFloat)/$(NpgsqlEfFloat)andUpdatesMicrosoft.EntityFrameworkCore.Designto$(EfFloat). Nearest-wins resolution gives the test hosts the newer assemblies whilesrc/keeps compiling against the 10.0.0 floor — which is a consumer's situation: their application resolves the newest patch, the package was built against 10.0.0.dotnet test <project> -p:EfFloat=10.0.13 -p:NpgsqlEfFloat=10.0.3; the properties reach restore too.Any/Countover an empty captured list of ranges or value sets fails with42883: operator does not exist: text && int4rangeon EF Core 10.0.2 and later (dotnet/efcore#37216) #302's four), integration 275/280 (10.x:Any/Countover an empty captured list of ranges or value sets fails with42883: operator does not exist: text && int4rangeon EF Core 10.0.2 and later (dotnet/efcore#37216) #302's five), NodaTime translation 83/83, InfinityDisabled 4/4. WithMicrosoft.EntityFrameworkCore.Issue37216set totruein aruntimeconfig.template.json(as the InfinityDisabled project sets its switch) everything passes, so a "floor behaviour on the newest patch" variant is one file.Two facts for the matrix:
Microsoft.EntityFrameworkCore [10.0.4, 11.0.0), so a leg that floats only Npgsql already floats EF Core past the floor; set EF Core explicitly anyway, Design included, so the leg is reproducible.{24:00:00}parses as{00:00:00}andT24:00:00as the next day #300 (and is cheap):dotnet-install.sh --channel 11.0 --quality preview --runtime dotnetinto a folder, then run thenet10.0test assemblies withDOTNET_ROLL_FORWARD=Major.TemporalLiteralGrammarTests.Time_Rejects("24:00:00")fails there today.CaffeinatedCoder commentedon Oct 19, 2026
Measured while porting #300 (PR #308), for the .NET 11 runtime roll-forward leg:
dotnet testwithDOTNET_ROOTpointed at a runtime-only .NET 11 install andDOTNET_ROLL_FORWARD=Majordoes not move the test host. VSTest launches testhost from the muxer that runsvstest.console, so the run stays on .NET 10 and passes, silently. What does run thenet10.0assembly on .NET 11:DOTNET_ROOT=<dotnet11> DOTNET_ROLL_FORWARD=Major <dotnet11>/dotnet exec --roll-forward Major <sdk>/vstest.console.dll <test dll>(both variables needed, or testhost finds no 10.0 runtime and prints no summary);--Diag:<file>writes alog.host.*withRuntime location:as the proof. The leg should assert that line, or it can pass by running on the wrong runtime. Before #308, that run failsTemporalLiteralGrammarTests.Time_Rejects("24:00:00")on 11.0.0-rc.2; the whole core project (1397) passes there with it.fix: keep RangeSet.Contains out of EF Core's rewrite of Contains on a…
CaffeinatedCoder commentedon Oct 19, 2026
The newest-patch leg is in PR #311. The scheduled run against the servicing builds is not, for two reasons. Both were measured on 2026-10-19; it moves to #312.
What was tried for the feed:
https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet10/nuget/v3/index.jsonanswers (HTTP 200 in 0.4 s; the earlier failedcurldoesn't reproduce). Its flat container lists 858Microsoft.EntityFrameworkCoreversions, all 10.0.0 prereleases: 122 alpha, 462 preview, 249 rc, 25 rtm, newest10.0.0-rtm.25513.102. It has no 10.0.x servicing build, and.Relationaland.Designlook the same.release/10.0'sNuGet.configlists these other public feeds.dotnet10-transportanddotnet-toolsdon't carry EF Core (404).dotnet-engholds one unrelated version.dotnet-publicmirrors nuget.org (10.0.2–10.0.13).darc-pub-dotnet-dotnet-d7437ff1, the isolated feed for the VMR build that Maestro's backflow last wrote into thatNuGet.config(eng/Version.Details.xml: dotnet/dotnetd7437ff1, BAR 336650). It holds EF Core,.Relationaland.Design10.0.14, one patch ahead of nuget.org;release/10.0'sVersions.propssays 10.0.14 servicing. The feed name changed six times between 2026-10-05 and 2026-10-15.-p:EfFloat=10.0.14 -p:NpgsqlEfFloat=10.0.3 -p:RestoreAdditionalProjectSources=<feed>, privateNUGET_PACKAGES,src/on the floor), all pass on PostgreSQL 16: 295/295, 91/91, 280/280, 4/4.Why it can't sit on
release/10.xanyway: GitHub firesscheduleonly from the default branch, so a weekly trigger inrelease/10.x'sdotnet.ymlwould never run. #312 puts the scheduler onmain, dispatching a leg onrelease/10.xthat reads the currentdarc-pubfeed.Measured for the newest-patch leg (PR #311, local, PostgreSQL 16), with the #302 rewriter reverted to
d883b12^:*_OverAnEmptyCapturedList_ReadsNoRows), integration 275/280 (10.x:Any/Countover an empty captured list of ranges or value sets fails with42883: operator does not exist: text && int4rangeon EF Core 10.0.2 and later (dotnet/efcore#37216) #302's five,42883: operator does not exist: text && text[]), NodaTime 91/91, InfinityDisabled 4/4.With the fix in place, all four pass on the newest patch. The leg also fails if a test host's
deps.jsondoesn't name the floated versions, so it can't silently re-test the floor.test: run the EF suites on the newest EF Core / Npgsql EF 10 patch as…
CaffeinatedCoder commentedon Oct 19, 2026
Done on
release/10.xby PR #311 (merge commit b9d7fa2, 2026-10-19): the EF suites run on the floor and on the newest published 10.0 patch (EF Core 10.0.13 / Npgsql EF 10.0.3) on PostgreSQL 16 and 18, required through the integration gate; the PR body holds the red run with the #302 fix reverted. The weekly servicing-build run is #312. Closed by hand:Closesacts only onmain.