| Age | Commit message (Collapse) | Author |
|---|
|
This is a really old test case (which was originally written before the
proper Nix syntax). The tested deep comparison behavior was implemented
and reverted soon after due to performance problems, but it has been
restored in today's Nix again (thanks to the derivation comparison
optimization, presumably).
|
|
This exposes the Store::queryPathFromHashPart() interface in the CLI.
|
|
|
|
parseDrvName: remove doc/impl discrepancy, add test covering the gap
|
|
This commit adds a test covering the discrepancy between parseDrvName's
implementation and documentation (the discrepancy was eliminated in the previous
commit).
|
|
|
|
Add an installer test
|
|
|
|
|
|
Hopefully this is best!
|
|
I just had a colleague get confused by the previous phrase for good
reason. "valid" sounds like an *objective* criterion, e.g. and *invalid
signature* would be one that would be trusted by no one, e.g. because it
misformatted or something.
What is actually going is that there might be a signature which is
perfectly valid to *someone else*, but not to the user, because they
don't trust the corresponding public key. This is a *subjective*
criterion, because it depends on the arbitrary and personal choice of
which public keys to trust.
I therefore think "trustworthy" is a better adjective to use. Whether
something is worthy of trust is clearly subjective, and then "trust"
within that word nicely evokes `trusted-public-keys` and friends.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This runs the installer in a QEMU VM. Unlike the old installer test
that ran inside a declaratively built RedHat/Debian image, this uses
an image from Vagrant.
|
|
This reverts commit c530cda345377370c52a616d608de88b9d67cd40, reversing
changes made to 4adcdff5c1d5f9f135c4ec61d690890443c19e6a.
|
|
|
|
|
|
|
|
|
|
Add some tests for the CLI completion
|
|
We don't need it yet.
|
|
|
|
|
|
This makes it easier to identify what command failed. It looks like:
follow-paths.sh: test failed at:
main in follow-paths.sh:54
|
|
|
|
|
|
|
|
Note: these were previously not actually called.
|
|
|
|
|
|
|
|
|
|
|
|
Simplify the check for overrides on non-existent inputs
|
|
Cherry-picked from the lazy-trees branch, where we no longer write a
lock file if any of the inputs is dirty.
|
|
|
|
- Test another command than `build`
- Test with two input flakes
|
|
`--override-input` id snarky because it takes two arguments, so it
doesn't play well when completed in the middle of the CLI (since the
argument just after gets interpreted as its second argument). So use
`--update-input` instead
|
|
|
|
I recently got fairly confused why the following expression didn't have
any effect
{
description = "Foobar";
inputs.sops-nix = {
url = github:mic92/sops-nix;
inputs.nixpkgs_22_05.follows = "nixpkgs";
};
}
until I found out that the input was called `nixpkgs-22_05` (please note
the dash vs. underscore).
IMHO it's not a good idea to not throw an error in that case and
probably leave end-users rather confused, so I implemented a small check
for that which basically checks whether `follows`-declaration from
overrides actually have corresponding inputs in the transitive flake.
In fact this was done by accident already in our own test-suite where
the removal of a `follows` was apparently forgotten[1].
Since the key of the `std::map` that holds the `overrides` is a vector
and we have to find the last element of each vector (i.e. the override)
this has to be done with a for loop in O(n) complexity with `n` being
the total amount of overrides (which shouldn't be that large though).
Please note that this doesn't work with nested expressions, i.e.
inputs.fenix.inputs.nixpkgs.follows = "...";
which is a known problem[2].
For the expression demonstrated above, an error like this will be
thrown:
error: sops-nix has a `follows'-declaration for a non-existant input nixpkgs_22_05!
[1] 2664a216e57169ec57d7f51be1b8383c1be83fd5
[2] https://github.com/NixOS/nix/issues/5790
|
