nixosTests/cosmic: move core logic into a dedicated script#519448
nixosTests/cosmic: move core logic into a dedicated script#519448thefossguy wants to merge 3 commits into
Conversation
|
At the moment, the test fails because I added a new test for handling polkit degradation in the second commit. But, once I apply |
|
Part of #508829 |
|
Maybe create a |
|
I'm up for whatever we decide. Do we have any official guidelines on this? |
|
Additionally, I'd like to wait at least today before merging to see if upstream tags a new release. That way, we can get the cosmic-osd fix in, and can confidently verify that none of the tests fail. |
|
I created #519587 for the tagged release that should have the cosmic-osd fix. Is there a way I could run the new test? |
I would guess its OK to just do it. |
11f2f8e to
4c4b064
Compare
4c4b064 to
be7d86b
Compare
|
|
For some reason, the tests now fail on aarch64-linux. Digging into it. |
449fde1 to
26087cf
Compare
|
Aha, the tests were failing on aarch64 because software rending was too slow for |
|
|
26087cf to
7b412cc
Compare
|
|
I'd appreciate a review from you both, if possible, @alyssais @nyabinary. |
|
Maybe you could move the Nix file in a separate earlier commit, so git can recognize the rename? |
|
This is a |
|
Yeah, that's what I meant. git mv doesn't do anything special.
|
7b412cc to
7398dd7
Compare
|
Pushed the changes :) |
alyssais
left a comment
There was a problem hiding this comment.
This is still really difficult to review. Not adding a new test in the same commit as porting the old ones might help, but even without all the polkit stuff I still have to wonder if this is really worth the explosion in length…
I haven't tried, so maybe it doesn't make sense, but would it be possible to avoid the long timeout by running a separate instance of a Python program for each application we want to test?
Sorry about that, I'll split it further.
The primary reason behind this migration of test logic from
So yes, it isn't worth it right now given we haven't changed much, but I'd rather refactor now than later. The test for polkit was added as a matter of urgency since it is very much a core component that every user expects to work properly.
Do you mean some sort of multi-threading/parallelism with like a thread per app? We can't do this without also increasing our |
ed323aa to
a6e422d
Compare
a6e422d to
010f24d
Compare
010f24d to
86fa08d
Compare
|
If there are no concerns, could someone please merge this? |
| emptyPDF = config.node.pkgs.stdenvNoCC.mkDerivation { | ||
| name = "empty-pdf"; | ||
| dontUnpack = true; | ||
| nativeBuildInputs = [ config.node.pkgs.imagemagick ]; | ||
| buildPhase = '' | ||
| magick xc:none -page Letter empty.pdf | ||
| ''; | ||
| installPhase = '' | ||
| mkdir $out | ||
| mv empty.pdf $out/empty.pdf | ||
| ''; | ||
| }; |
There was a problem hiding this comment.
How about:
| emptyPDF = config.node.pkgs.stdenvNoCC.mkDerivation { | |
| name = "empty-pdf"; | |
| dontUnpack = true; | |
| nativeBuildInputs = [ config.node.pkgs.imagemagick ]; | |
| buildPhase = '' | |
| magick xc:none -page Letter empty.pdf | |
| ''; | |
| installPhase = '' | |
| mkdir $out | |
| mv empty.pdf $out/empty.pdf | |
| ''; | |
| }; | |
| emptyPDF = config.node.pkgs.stdenvNoCC.mkDerivation { | |
| name = "empty.pdf"; | |
| dontUnpack = true; | |
| dontConfigure = true; | |
| nativeBuildInputs = [ config.node.pkgs.imagemagick ]; | |
| buildPhase = '' | |
| runHook preBuild | |
| magick xc:none -page Letter empty.pdf | |
| runHook postBuild | |
| ''; | |
| installPhase = '' | |
| runHook preInstall | |
| cp empty.pdf $out | |
| runHook postInstall | |
| ''; | |
| }; |
There's also an argument to be made for adding this to by-name.
There was a problem hiding this comment.
Do we really need to do this for a derivation that simply creates an empty PDF? I'm fine either way, though.
There was a problem hiding this comment.
There's already precedent for helper/test derivations living in the main package set in the form of emptyFile and emptyDirectory.
| cosmicTestDesktop = config.node.pkgs.makeDesktopItem { | ||
| name = "cosmicTest"; | ||
| desktopName = "COSMIC NixOS VM test (${testName})"; | ||
| exec = "${cosmicTest}/bin/cosmicTest"; |
There was a problem hiding this comment.
| exec = "${cosmicTest}/bin/cosmicTest"; | |
| exec = lib.getExe' cosmicTest "cosmicTest"; |
That being said, this might even be better off as
| exec = "${cosmicTest}/bin/cosmicTest"; | |
| exec = "cosmicTest"; |
See #308324
| ydotool_daemon_socket_path = f"{xdg_runtime_dir}/.ydotool_socket" | ||
| ydotool_daemon_process = subprocess.Popen( | ||
| [ | ||
| f"{cli_args.ydotool_drv_store_path}/bin/ydotoold", |
There was a problem hiding this comment.
Any reason we're not relying on PATH here? It would simplify this script quite a bit.
There was a problem hiding this comment.
I'm pretty sure that there was a reason during my testing but it may have changed after the cleanup. Let me test this out and get back.
| notification_watcher_exists = False | ||
| while time.monotonic() < notification_watcher_wait_deadline: | ||
| busctl_process = subprocess.run( | ||
| ["busctl", "--user", "status", "com.system76.CosmicStatusNotifierWatcher"], |
There was a problem hiding this comment.
Why are we relying on the PATH here and not elsewhere?
| cosmicTest = config.node.pkgs.writeShellScriptBin "cosmicTest" '' | ||
| exec ${config.node.pkgs.python3Minimal}/bin/python3 ${./test-script.py} \ | ||
| --log-file-path ${logFilePath} \ | ||
| --cosmic-reader-pdf ${emptyPDF}/empty.pdf \ |
There was a problem hiding this comment.
Would be replaced with
| --cosmic-reader-pdf ${emptyPDF}/empty.pdf \ | |
| --cosmic-reader-pdf ${emptyPDF} \ |
or
| --cosmic-reader-pdf ${emptyPDF}/empty.pdf \ | |
| --cosmic-reader-pdf ${config.node.pkgs.emptyPDF} \ |
There was a problem hiding this comment.
The 1st suggestion doesn't apply here because the installPhase copies the PDF to $out/empty.pdf. We could simply copy it to $out, will test that.
As for the 2nd suggestion, that doesn't work since emptyPDF is part of the let-in block, not part of nixpkgs' packages. And I don't see a reason to add it to pkgs/by-name for a derivation that doesn't provide an executable binary. I'm not opposed. Just not sure if adding it to nixkpgs is the right call here.
There was a problem hiding this comment.
This is specifically if #519448 (comment) is applied
| # Use `writeShellScriptBin` instead of `writeShellScript` so that the | ||
| # process name in the journald log appears as 'cosmicTest[$pid]' | ||
| cosmicTest = config.node.pkgs.writeShellScriptBin "cosmicTest" '' | ||
| exec ${config.node.pkgs.python3Minimal}/bin/python3 ${./test-script.py} \ |
There was a problem hiding this comment.
| exec ${config.node.pkgs.python3Minimal}/bin/python3 ${./test-script.py} \ | |
| exec ${lib.getExe config.node.pkgs.python3Minimal} ${./test-script.py} \ |
|
Thanks for the review @Pandapip1! I'll update this PR soon-ish. |
|
Honestly given how much this PR has already been stalled, I'd probably prefer to see this merged first, then the improvements can be made in follow-up PRs. |
Things done
passthru.tests.nixpkgs-reviewon this PR. See nixpkgs-review usage../result/bin/.