<ScottHDev>
Hello, I'm trying to use nixos to automate the code coverage CI step. I especially would like to use nixpkgs' test driver to run the app with a few normal usage user actions. But it seems like this isn't possible outside of nixpkgs. Do you if it's possible to use it in my CI or if I should use other tools ?
<domenkozar[m]>
ScottHDev what do you mean by outside of nixpkgs?
contrapumpkin is now known as copumpkin
<abathur>
nix#4690 (3 word diff!) could use a look from someone with a handle on sudo security policy. It basically rewrites a few uses of `sudo HOME=ROOT_HOME command` -> `sudo env HOME=ROOT_HOME command` in the installer to support `doas` as a sudo replacement. I'm wondering if `env` is more likely to be blocked than changing HOME already would be?
<ScottHDev>
When you wan't to make a test driver, you normally create a new file in NixPkgs/nixos/tests and you add a line close to my-test = handleTest ./my-test.nix {}; in all-tests.nix. This infrastructure is not portable; you can't make add test as easily as you add overlays or derivations to your nur repo for example.
<ScottHDev>
domenkozar[m]
<ScottHDev>
*you can't add
<ScottHDev>
*a test
<sterni>
you can just use nixos/tests/make-test-python.nix regardless
<ScottHDev>
Is it that easy? I tried to add it to my repo and after importing more and more nix files from nixpkgs I gave up because it seemed like I would need to copy the entire nixpkgs/nixos/lib folder into my repo
<sterni>
I'd just do let nixpkgs = fetchTarball { … }; in import "${nixpkgs}/nixos/lib/make-test-python.nix" ({ ... }: … )
evanjs has quit [Remote host closed the connection]
evanjs has joined #nixos-dev
AkechiShiro has joined #nixos-dev
tomberek has quit [Quit: Connection closed]
<ScottHDev>
Hello again, I've made some good progress with my test driver but as said above, this needs to output the lcov coverage data at the end. So the file is successfully generated but I don't know how I could make the test driver to transmit it to the host.
<ScottHDev>
Maybe that the out env var could be used in this case
justanotheruser has joined #nixos-dev
jonringer has quit [Ping timeout: 258 seconds]
<ScottHDev>
copy_from_vm is there for that
orivej has quit [Ping timeout: 265 seconds]
srk has quit [Ping timeout: 260 seconds]
<gchristensen>
I wonder how much time it'd take to rewrite switch-to-configuration in rust
<gchristensen>
I'd really like to see an option to get structured output
<samueldr>
should it be a generic~ish binary that consumes structured data?
<samueldr>
(I guess)
<gchristensen>
maybe so, yeah
__monty__ has quit [Quit: leaving]
<gchristensen>
but I'd like to be able to process the output of dry-activate easily, and then also process the output of test/switch as it happens
<samueldr>
it would be odd to compile a full bespoke rust program per generation
<ekleog>
I guess something could be done by splitting activation scripts between “compiled activation scripts” (that shouldn't change too often) and “configuration for activation scripts”? but given that out-of-tree modules may be relying on the fact that it's possible to add arbitrary logic to activation scripts I don't think removing that possibility altogether would be a good idea
<ekleog>
(iow, I don't think we could avoid the fact that “compiled activation scripts” must be configurable, in which case it'd mean requiring a rebuild)
<ekleog>
fwiw, even though I love rust, I'd think a structured interpreted language like racket or the like might be a better pick here, while still making it possible to get structured data — in exchange, it'd increase the closure size
<ekleog>
(uhhhhh it looks like racket-minimal is 500M… well, some _other_ structured interpreted language then I guess)
<gchristensen>
rust is perfectly capable of emitting structured logs
<gchristensen>
or a summary datastructure
<samueldr>
ekleog: don't forget that it needs to have an initial build closure that is not too big, and easy to cross-compile :)
<ekleog>
gchristensen: hmm yes? I was mostly thinking around “we can't take off the turing-completeness of activation scripts” in my answer
<gchristensen>
meh, since they're a script executed by switch-to-configuration and can stay that way
<samueldr>
I think I might have made the same mistake as ekleog did (assuming)
<ekleog>
ooooh you mean we could have each activation script be perl, and only switch-to-configurtion would become rust?
<samueldr>
and thought more about activation scripts than switch-to-configuration
<ekleog>
^
<gchristensen>
no, I mean switch-to-configuration and its dry-activate / switch / etc. output
<samueldr>
I didn't end up saying it, but it really already is doing a basic minimum with structured data
<samueldr>
I conflated that in my mind
<gchristensen>
maybe its perl could be persuaded to be machine parsable :)
<gchristensen>
activation scripts could fairly easily become structured with careful fd handling
cjb has joined #nixos-dev
supersandro2000 is now known as Guest68734
Guest68734 has quit [Killed (hitchcock.freenode.net (Nickname regained by services))]