Closed skarmux closed 2 months ago
Hi @skarmux thanks for the report!
I think I had missed that part of the documentation when writing the original integration (I suppose I mistakenly assumed just because cargo supports options like cargo <here> build <etc>
, then nextest
would do...), so if that's the right way to make things work I'd definitely be happy to review a PR to get it fixed!
Okay, this will be my first ever PR. It's assigned to this issue. I've ran nix flake check
and everything went through. Also used the forked repo in my personal project as input and the barebones craneLib.cargoNextest
check passed there as well.
https://github.com/ipetkov/crane/blob/529c1a0b1f29f0d78fa3086b8f6a134c71ef3aaf/lib/cargoNextest.nix#L46-L51
As stated in the documentation of the cargo-nextest crate, any extra argument/option is to be set behind
$ cargo nextest run
. The nextest call appears to take mostly the same arguments as cargo does, which is why I got away with placing my cargo extra arguments (--feature <xyz>
) incargoNextestExtraArgs
without any issue.If any
cargoExtraArgs
(orllvm-cov
) is placed between$ cargo <here> nextest run
it results in an invalid command structure. I figure both can be removed fromcraneLib.cargoNextest
and the corresponding documentation without losing functionality.I'll gladly do the work if I haven't missed something.