-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
postgresql: improve passthru.tests #352966
postgresql: improve passthru.tests #352966
Conversation
9a6ebf0
to
6e3bf9c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the change, thanks!
Just one question: what's the recommended way of running tests for all versions now?
Something like Hm.. The thing about I wonder whether we can somehow have an attribute somewhere, which would make it easy to do both at the same time? |
And while we're considering test coverage: We currently have an option Is there a specific reason for |
I mean we have all information available for that. The easiest approach would be to add this to the respective files (i.e. I don't know. I think I could also live with this approach though. |
And that would still only allow to test e.g. |
Yes. |
I don't find myself in the scenario "only a subset of tests" often, I think. But of course, when working on the test itself.. you'd want to run that with all versions. So I think we should add back all the versions to each What I do find myself in often is: Run everything for a specific PG version (e.g. when adding a new major version) or run everything for all pg versions (when changing generic.nix etc.). And both includes all the extensions as well. Both is currently annoying to do. I wonder whether we'd actually need a |
Hmm, it just occurred to me: are Given that we want a Then we can do I think Nextcloud does it that way already if you'd like to see it in the wild. Does that sound reasonable? Are you interested in doing that? Otherwise, I'd be willing to take over soonish (at least not today). |
That sounds good, yes.
Yeah, I'll do that. The one thing that will still not be possible with that is to build all non-broken extensions for one (or all) postgresql version at once, possibly even including their tests (which might not always be in |
I mean, it was the case already that you could only build extensions selectively or all, right?
So if we have a |
Yes. But doing
Hm, is it? Not sure about that. I would
Hm, yeah it seems like you want But I think the versioned attributes would still be one level below that. I don't understand the part where you want to add a Anyway, I think I have an idea for the |
I fully agree here, I just don't have a really good idea right now.
That'd be my suggestion, yes. May I ask what downsides you see with this?
No: my suggestion is to add
Would be fine by me.
Yeah sure. I think the fact that the correct postgresql is tested in |
6e3bf9c
to
c8986fe
Compare
So, in theory this should work quite well now:
The same works for each extension individually:
But - there are two problems right now:
|
Ah, scratch that. It just doesn't work for PG 17. Misread the output. |
The failure for the anonymizer test will be solved once #345260 is solved. This will make |
So I guess this is just about evaluating a lot of VMs for all the tests. This seems to take time and I doubt we can make it much faster right now. If nix (lix) was only evaluating in parallel... |
You may want to use Thanks a lot! |
Even more? It already used something like ~50GB right now... :D Will have a look. |
Merge conflicts resolved and fixed everything that |
6ec6813
to
dadff44
Compare
Fixed a debugging left-over in the postgis test which caused it to fail in the latest rebase. The postgis test is currently broken on master, merging this should fix that, thus: ZHF: #352882 |
I'm afraid we have another merge conflict 🙈 |
This seems to have broken years ago, because "CREATE EXTENSION pgcrypto;" etc. were added to the upstream file about 6 years ago.
Allows building all PostgreSQL versions at once with: nix-build -A postgresqlVersions Also makes it possible for nixosTests to target all PostgreSQL versions without importing the postgresql folder across the whole repo.
Manually importing postgresql packages from the /pkgs/ folder or manually importing the test from /nixos/tests/ in generic.nix is not only ugly, but also forbidden should we ever move to pkgs/by-name. We can achieve almost the same with a slightly different setup. We allow overriding the postgresql package for the test via passthru.override, to make sure that each postgresql_xx.tests.postgresql-wal-receiver is properly teted with the right version.
Same reasoning as commit before.
Same reasoning as commit before.
Restructuring the nixosTests.postgresql test a little bit to allow calling it with the specific versioned package from generic.nix.
Same reasoning as commit before.
…etches into package There is no need to fire up a whole VM just to run a two line test of creating the extension. We can use postgresqlTestExtension for that. This has the advantage that it runs with postgresqlTestHook, so without a VM, making it more portable.
Same reasoning as commit before.
Same reasoning as commit before.
…package Same reasoning as commit before.
Same reasoning as commit before.
… package Same reasoning as commit before.
…package Same reasoning as commit before.
…e folder This makes it possible to run all those tests at once by building nixosTests.postgresql and allow a simple entry to ci/OWNERS for all tests.
Avoiding "with", using the same names and basic structure in each test. Consistency is key!
Because with as many changes as in here anybody working on those test files will have merge conflicts anyway.
dadff44
to
45cef36
Compare
Resolved! |
While reviewing NixOS#352966 I noticed that the pg_anonymizer test fails for postgresql 17. The reason for that is that `pkgs.postgresql` is v16 and using its psql to connect against a v17 database doesn't work. I decided that we'll just use the latest available package in here. I don't want to introduce another attribute (`postgresql_latest`), if there are too many instances of that we're blocked on adding new postgresql majors directly to master again which is the current status quo. With the test rework in NixOS#352966 it's also way easier to catch this.
postgresql
andpostgresqlPackages
's tests currently have the following problems:postgresql_12_jit.pkgs.postgis.tests
actually tests the extension compiled againpostgresql_16
.This PR fixes that - and more. The general approach is to provide a
passthru.override
function from each of the postgresql related nixosTests - and then use that to override thepostgresqlPackage
from the derivation/extension.Furthermore, some tests (postgis and apache_datasketches) were simple enough to easily migrate them to
postgresqlTestExtension
- which doesn't need any VM, but just runs the tests viapostgresqlTestHook
. This is much more portable, as it should also work for darwin (do nixosTests work there, normally?) or could also work forpkgsMusl.postgresql...
(didn't test, though).Most importantly.. it would have allowed to run all those tests against the new PostgreSQL version, when we added that in #351253. Instead, they were all still running against the default version in that PR.
Things done
nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Add a 👍 reaction to pull requests you find important.