-
-
Notifications
You must be signed in to change notification settings - Fork 14.8k
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
nixos/tests: follow-up to the closure reduction PR #101598
Conversation
Can you change nixos-build-vms to use the |
1a4350f
to
adc0964
Compare
so does / should this resolve the eval error currently present on |
@andir yes, but do you think that |
Can you linke me that error or quote it? Not sure what that error is.
…On Sun, 25 Oct 2020, 08:07 xaverdh, ***@***.***> wrote:
so does / should this resolve the eval error currently present on
unstable-small ?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#101598 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAE365D3PZGXLMFJTPJ2GZLSMPFCHANCNFSM4S52PVRQ>
.
|
(from https://hydra.nixos.org/jobset/nixos/unstable-small#tabs-errors) |
Not sure if that is indeed what is preventing eval though. There is also the mysterious
at the tail of that log.. |
I belive the fromer could be fixed (will verify) the latter is (hopefully) unrelated as master has been stuck for a while now. Funnily enough my hydra instance was able to eval the release jobset of this PR just fine. I'll also let it build the small release set to see if that also succeeds. |
You might have a good point there. So would it be clearer if we switched the |
Oh yeah indeed. The small jobset is failing with the same eval error here:
I managed to reproduce it locally with this command: I'll have a look why this test is complaining while others are just fine. |
I think it is due to #101246 actually.. |
Yeah, I just started fixing that. The problem is because the |
Once that lands I'll rebase this PR ontop of it and give it another spin. |
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.
LGTM.
As @rnhmjoj stated, nixos-build-vms
should use driverInteractive
now rather than my workaround btw.
Previously you would be able to override only the QEMU package to be used in the test runner. Frankly that doesn't help a lot if you are trying to get a graphical session. The graphical session requires the option in the NixOS module system to bet set to the correct QEMU package. In this commit I moved most of the test node configuration and transformations into the `mkDriver` function (previously called `driver`). The motivation was to be able to create a `driver` instance with a given QEMU package that will be used consistently througout the test expression.
In a previous commit I broke this as there is no longer one testDriver but only a function to generate one based on some QEMU inputs.
In 5500dc8 we introduced the --keep-vm-state flag and defaulted to that flag not being set. This lead to the `runInMachine` tests not longer working and that going unnoticed for quite some time now.
This reverts commit aab534b & uses the driverInteractive attribute for the test driver instead. This has the same effect but removes the extra module in the nixos-build-vms code.
adc0964
to
d4fb7da
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.
Looks good to me. Thank you for change I mentioned.
Motivation for this change
This is a follow-up on #49403 where I made a big oversight regarding the QEMU executable that is being described within the NixOS module system. That package actually drives the VMs that are being started. I previously only changed the QEMU package that was used within the test driver script.
I've tried to detail the changes in the commits. Please let me know if there are any open questions and/or remarks.
While working on this I noticed that in 5500dc8 we introduced the --keep-vm-state flag and defaulted to that flag not being set. This lead to the
runInMachine
tests not longerworking and that going unnoticed for quite some time now.
cc @Ma27 @rnhmjoj #101473