Tests fail in a Nix derivation

[colemickens]

I'm adding this to my nixpkgs to dogfood.

Is there a scenario supported by run-tests.sh, and requiring an environment variable, versus just looking for the password-store in that location by default?

Also, am I understanding that it's then going to run against my actual password-store by default when running cargo test? That makes me very uncomfortable.

[cole-h]

Good point about cargo test operating on your store by default. I've added a little "helper" that overrides the PASSWORD_STORE_DIR env var to point where it should in 614df96.

Could you maybe reword what you mean in your second paragraph? I'm having trouble parsing. nix-shell --pure --run "cargo test --test util" works fine for me, if that's what you were talking about.

[cole-h]

OK, I see what you're saying now. My tests (specifically, decrypt_file_into_bytes and decrypt_file_into_strings) fail when using rustPlatform.buildRustPackage due to No data (gpg error 58). I'll look into it.

[cole-h]

I've found the issue! Unfortunately, I don't think there's anything I can do here. The tests require the presence of my test key located at tests/passrs@testuser.secret.asc -- it's on my system, since I created it, but it won't be in the sandbox. The following derivation should work:

{ rustPlatform
, fetchFromGitHub
, libgpgerror
, gpgme
, libgit2
, gnupg
}:

rustPlatform.buildRustPackage {
  pname = "passrs";
  version = "0.1.0";

  # src = fetchFromGitHub { ... };

  cargoSha256 = "09vqz51hg3zw48zygp4ask8d7sdml7qw6d33pcabq9advxvg9bwr";

  nativeBuildInputs = [
    gpgme # `gpgme-config` required by crate gpgme
    libgpgerror # `gpg-error-config` required by crate libgpg-error-sys
  ];

  buildInputs = [
    gpgme
    libgit2
    libgpgerror
  ];

  checkInputs = [
    gnupg
  ];

  # Some tests require the presence of a test key.
  preCheck = ''
    export GNUPGHOME=$(mktemp -d)
    gpg --import tests/passrs@testuser.secret.asc
    echo "4B0D9BBAC5C8329C035B125CF6EF0D39C5F84192:6:" | gpg --import-ownertrust
  '';
}

[cole-h]

Sorry, I closed this by accident. I still need to find a solution to being able to run tests without the above workaround. gpgme might be able to import and set the trust level of a key.

[cole-h]

As of 6f01544, this should be solved. Please let me know if that's not the case.

It doesn't look like gpgme has a way to manipulate ownertrust (though it can import keys), so I took the path of least resistance and spawn two gpg processes -- one to import the secret key itself, and one to import the ownertrust.

[cole-h]

As of ce690f6, I've checked in the contents of a dummy GNUPGHOME, which will allow the tests to run without running gpg.

Thanks for bringing this to my attention!