Synchronize to latest EF
We're going to sync the EF Core PostgreSQL provider (EFCore.PG) in this repo to reference the latest daily build of EF Core, and make any necessary adjustment. Try your best to arrive at a fully 100% passing build after syncing, but even if you're unable to do so, submit a PR with whatever you did manage to do, as a basis for further manual work.
1. Find out and depend on the latest EF Core daily build of the current preview release
- First, check what version the
main branch represents, by looking at the <VersionPrefix> in Directory.Build.props.
- Then, find the latest EF Core daily build version for that preview version; we do not want to sync to a daily build that's for the next preview version. For example, if
main has a <VersionPrefix> of 11.0.0-preview.2, we want to update to the latest daily build for preview.2, and not to preview.3 even if packages already exist for that.
- Note that after preview.7, the naming switches to rc.1 and rc.2.
- Once you've found the latest daily build package we're syncing to, update the EF Core version in Directory.Packages.props to use it. The EF Core daily build nuget feed is https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet11/nuget/v3/index.json (note that you may need to update dotnet11 to dotnet12 depending on the major/minor version we're looking for).
- There's no need to switch to the latest daily build of the dotnet SDK though - only of EF; please just always use the latest released preview version of the dotnet SDK (not daily build), unless there's a specific issue requiring the very latest SDK (very rare/unlikely). Use the dotnet-install.sh script to install dotnet SDK.
- If the filesystem is readonly (may be the case in CI), install the dotnet SDK to a temporarily location in /tmp and execute it from there.
2. Build
Build EFCore.PG and resolve any errors that are reported.
The EF Core source code can be found in https://github.com/dotnet/efcore - you can explore that repo to understand what changes happened there from the last version the EFCore.PG used to the version we're upgrading towards. Focus especially on changes that occurred before the current daily build referenced by EFCore.PG (before your change), since everything is still working correctly with it.
Generally try to align EFCore.PG to whatever practices and patterns are in use within EF Core itself.
3. Run Tests
Once everything builds, run all the tests under test - both unit and functional tests - and make sure they all pass. You should have a PostgreSQL database available for running the functional tests - run them all, always, as a final validation for your changes - even if this takes a long time.
- If you get failures from Check_all_tests_overridden, that means that new tests have been added - or possibly that existing ones have been renamed. Find out if a rename occurred by finding missing overridden tests that resemble the new test, and explore the EF code base (including its git history) as needed.
- When adding new test overrides, add them in the appropriate place in the source file, following their placement in the base class. Do not simply add them at the end of the file.
- Also, always add AssertSql(), following the pattern for other tests in the class.
- If you get failures from test NpgsqlComplianceTest.All_test_bases_must_be_implemented, that means that new test base classes have been added - or possibly that existing ones have been renamed. Find out if a rename occurred by finding missing base classes that resemble the new base class, and explore the EF code base (including its git history) as needed. Do not simply add the missing test suite to IgnoredTestBases.
4. Commit and submit PR
- Commit all changes in a single commit (no need for separate commits), calling it simply "Sync to EF 11.0.0-preview.1.26104.118" (substituting the actual version). No need for a commit body message.
- Create a PR in https://github.com/npgsql/efcore.pg with all the changes.
- Include a section in the PR body with a list of all PRs on the EF side that caused changes that required updates in EFCore.PG. You can find these by looking at the git history in the EF repo and finding all commits that occurred between the last version we were synced to and the new version we're syncing to, and then finding the PR associated with each commit (commits generally reference the PR in their title).
- Once again, even if you've failed to arrive at a 100% passing build, submit whatever work you did do as a basis for further manual work.
1---2name: sync-to-latest-ef3description: Synchronizes EFCore.PG to use the latest EF daily build for the current preview being targeted. Bumps the dependency and ensures the provider builds and all tests pass.4---56# Synchronize to latest EF78We're going to sync the EF Core PostgreSQL provider (EFCore.PG) in this repo to reference the latest daily build of EF Core, and make any necessary adjustment. Try your best to arrive at a fully 100% passing build after syncing, but even if you're unable to do so, submit a PR with whatever you did manage to do, as a basis for further manual work.910## 1. Find out and depend on the latest EF Core daily build of the current preview release11121. First, check what version the `main` branch represents, by looking at the `<VersionPrefix>` in `Directory.Build.props`.132. Then, find the latest EF Core daily build version **for that preview version**; we do not want to sync to a daily build that's for the next preview version. For example, if `main` has a `<VersionPrefix>` of `11.0.0-preview.2`, we want to update to the latest daily build for preview.2, and not to preview.3 even if packages already exist for that.143. Note that after preview.7, the naming switches to rc.1 and rc.2.154. Once you've found the latest daily build package we're syncing to, update the EF Core version in Directory.Packages.props to use it. The EF Core daily build nuget feed is https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet11/nuget/v3/index.json (note that you may need to update dotnet11 to dotnet12 depending on the major/minor version we're looking for).165. There's no need to switch to the latest daily build of the dotnet SDK though - only of EF; please just always use the latest released preview version of the dotnet SDK (not daily build), unless there's a specific issue requiring the very latest SDK (very rare/unlikely). Use the dotnet-install.sh script to install dotnet SDK.17 * If the filesystem is readonly (may be the case in CI), install the dotnet SDK to a temporarily location in /tmp and execute it from there.1819## 2. Build2021Build EFCore.PG and resolve any errors that are reported.2223The EF Core source code can be found in https://github.com/dotnet/efcore - you can explore that repo to understand what changes happened there from the last version the EFCore.PG used to the version we're upgrading towards. Focus especially on changes that occurred before the current daily build referenced by EFCore.PG (before your change), since everything is still working correctly with it.2425Generally try to align EFCore.PG to whatever practices and patterns are in use within EF Core itself.2627## 3. Run Tests2829Once everything builds, run all the tests under test - both unit and functional tests - and make sure they all pass. You should have a PostgreSQL database available for running the functional tests - run them all, always, as a final validation for your changes - even if this takes a long time.3031* If you get failures from Check_all_tests_overridden, that means that new tests have been added - or possibly that existing ones have been renamed. Find out if a rename occurred by finding missing overridden tests that resemble the new test, and explore the EF code base (including its git history) as needed.32 * When adding new test overrides, add them in the appropriate place in the source file, following their placement in the base class. Do not simply add them at the end of the file.33 * Also, always add AssertSql(), following the pattern for other tests in the class.34* If you get failures from test NpgsqlComplianceTest.All_test_bases_must_be_implemented, that means that new test base classes have been added - or possibly that existing ones have been renamed. Find out if a rename occurred by finding missing base classes that resemble the new base class, and explore the EF code base (including its git history) as needed. Do not simply add the missing test suite to IgnoredTestBases.3536## 4. Commit and submit PR3738* Commit all changes in a single commit (no need for separate commits), calling it simply "Sync to EF 11.0.0-preview.1.26104.118" (substituting the actual version). No need for a commit body message.39* Create a PR in https://github.com/npgsql/efcore.pg with all the changes.40* Include a section in the PR body with a list of all PRs on the EF side that caused changes that required updates in EFCore.PG. You can find these by looking at the git history in the EF repo and finding all commits that occurred between the last version we were synced to and the new version we're syncing to, and then finding the PR associated with each commit (commits generally reference the PR in their title).41* Once again, even if you've failed to arrive at a 100% passing build, submit whatever work you did do as a basis for further manual work.
npgsql