···1# Testers {#chap-testers}
02This chapter describes several testing builders which are available in the `testers` namespace.
34## `hasPkgConfigModules` {#tester-hasPkgConfigModules}
···6<!-- Old anchor name so links still work -->
7[]{#tester-hasPkgConfigModule}
8Checks whether a package exposes a given list of `pkg-config` modules.
9-If the `moduleNames` argument is omitted, `hasPkgConfigModules` will
10-use `meta.pkgConfigModules`.
01112-Example:
1314```nix
15passthru.tests.pkg-config = testers.hasPkgConfigModules {
16 package = finalAttrs.finalPackage;
17- moduleNames = [ "libfoo" ];
18};
0019```
2021-If the package in question has `meta.pkgConfigModules` set, it is even simpler:
00002223```nix
24passthru.tests.pkg-config = testers.hasPkgConfigModules {
25 package = finalAttrs.finalPackage;
026};
02728-meta.pkgConfigModules = [ "libfoo" ];
29-```
3031## `testVersion` {#tester-testVersion}
32···83 - Move `$out` to `$out/result`, if it exists (assuming `out` is the default output)
84 - Save the build log to `$out/testBuildFailure.log` (same)
8586-Example:
000000000008788```nix
89runCommand "example" {
···100'';
101```
102103-While `testBuildFailure` is designed to keep changes to the original builder's
104-environment to a minimum, some small changes are inevitable.
105-106- - The file `$TMPDIR/testBuildFailure.log` is present. It should not be deleted.
107- - `stdout` and `stderr` are a pipe instead of a tty. This could be improved.
108- - One or two extra processes are present in the sandbox during the original
109- builder's execution.
110- - The derivation and output hashes are different, but not unusual.
111- - The derivation includes a dependency on `buildPackages.bash` and
112- `expect-failure.sh`, which is built to include a transitive dependency on
113- `buildPackages.coreutils` and possibly more. These are not added to `PATH`
114- or any other environment variable, so they should be hard to observe.
115116## `testEqualContents` {#tester-equalContents}
117118Check that two paths have the same contents.
119120-Example:
00121122```nix
123testers.testEqualContents {
···137}
138```
13900140## `testEqualDerivation` {#tester-testEqualDerivation}
141142Checks that two packages produce the exact same build instructions.
143144-This can be used to make sure that a certain difference of configuration,
145-such as the presence of an overlay does not cause a cache miss.
146147When the derivations are equal, the return value is an empty file.
148Otherwise, the build log explains the difference via `nix-diff`.
149150-Example:
00151152```nix
153testers.testEqualDerivation
···156 (hello.overrideAttrs(o: { doCheck = true; }))
157```
15800159## `invalidateFetcherByDrvHash` {#tester-invalidateFetcherByDrvHash}
160161Use the derivation hash to invalidate the output via name, for testing.
162163Type: `(a@{ name, ... } -> Derivation) -> a -> Derivation`
164165-Normally, fixed output derivations can and should be cached by their output
166-hash only, but for testing we want to re-fetch everytime the fetcher changes.
00167168-Changes to the fetcher become apparent in the drvPath, which is a hash of
169-how to fetch, rather than a fixed store path.
170-By inserting this hash into the name, we can make sure to re-run the fetcher
171-every time the fetcher changes.
172173-This relies on the assumption that Nix isn't clever enough to reuse its
174-database of local store contents to optimize fetching.
0175176-You might notice that the "salted" name derives from the normal invocation,
177-not the final derivation. `invalidateFetcherByDrvHash` has to invoke the fetcher
178-function twice: once to get a derivation hash, and again to produce the final
179-fixed output derivation.
180181-Example:
182183```nix
184tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
···189};
190```
19100192## `runNixOSTest` {#tester-runNixOSTest}
193194A helper function that behaves exactly like the NixOS `runTest`, except it also assigns this Nixpkgs package set as the `pkgs` of the test and makes the `nixpkgs.*` options read-only.
195196If your test is part of the Nixpkgs repository, or if you need a more general entrypoint, see ["Calling a test" in the NixOS manual](https://nixos.org/manual/nixos/stable/index.html#sec-calling-nixos-tests).
197198-Example:
00199200```nix
201pkgs.testers.runNixOSTest ({ lib, ... }: {
···209})
210```
21100212## `nixosTest` {#tester-nixosTest}
213214Run a NixOS VM network test using this evaluation of Nixpkgs.
215216NOTE: This function is primarily for external use. NixOS itself uses `make-test-python.nix` directly. Packages defined in Nixpkgs [reuse NixOS tests via `nixosTests`, plural](#ssec-nixos-tests-linking).
217218-It is mostly equivalent to the function `import ./make-test-python.nix` from the
219-[NixOS manual](https://nixos.org/nixos/manual/index.html#sec-nixos-tests),
220-except that the current application of Nixpkgs (`pkgs`) will be used, instead of
221-letting NixOS invoke Nixpkgs anew.
222223-If a test machine needs to set NixOS options under `nixpkgs`, it must set only the
224-`nixpkgs.pkgs` option.
225226### Parameter {#tester-nixosTest-parameter}
227
···1# Testers {#chap-testers}
2+3This chapter describes several testing builders which are available in the `testers` namespace.
45## `hasPkgConfigModules` {#tester-hasPkgConfigModules}
···7<!-- Old anchor name so links still work -->
8[]{#tester-hasPkgConfigModule}
9Checks whether a package exposes a given list of `pkg-config` modules.
10+If the `moduleNames` argument is omitted, `hasPkgConfigModules` will use `meta.pkgConfigModules`.
11+12+:::{.example #ex-haspkgconfigmodules-defaultvalues}
1314+# Check that `pkg-config` modules are exposed using default values
1516```nix
17passthru.tests.pkg-config = testers.hasPkgConfigModules {
18 package = finalAttrs.finalPackage;
019};
20+21+meta.pkgConfigModules = [ "libfoo" ];
22```
2324+:::
25+26+:::{.example #ex-haspkgconfigmodules-explicitmodules}
27+28+# Check that `pkg-config` modules are exposed using explicit module names
2930```nix
31passthru.tests.pkg-config = testers.hasPkgConfigModules {
32 package = finalAttrs.finalPackage;
33+ moduleNames = [ "libfoo" ];
34};
35+```
3637+:::
03839## `testVersion` {#tester-testVersion}
40···91 - Move `$out` to `$out/result`, if it exists (assuming `out` is the default output)
92 - Save the build log to `$out/testBuildFailure.log` (same)
9394+While `testBuildFailure` is designed to keep changes to the original builder's environment to a minimum, some small changes are inevitable:
95+96+ - The file `$TMPDIR/testBuildFailure.log` is present. It should not be deleted.
97+ - `stdout` and `stderr` are a pipe instead of a tty. This could be improved.
98+ - One or two extra processes are present in the sandbox during the original builder's execution.
99+ - The derivation and output hashes are different, but not unusual.
100+ - The derivation includes a dependency on `buildPackages.bash` and `expect-failure.sh`, which is built to include a transitive dependency on `buildPackages.coreutils` and possibly more.
101+ These are not added to `PATH` or any other environment variable, so they should be hard to observe.
102+103+:::{.example #ex-testBuildFailure-showingenvironmentchanges}
104+105+# Check that a build fails, and verify the changes made during build
106107```nix
108runCommand "example" {
···119'';
120```
121122+:::
00000000000123124## `testEqualContents` {#tester-equalContents}
125126Check that two paths have the same contents.
127128+:::{.example #ex-testEqualContents-toyexample}
129+130+# Check that two paths have the same contents
131132```nix
133testers.testEqualContents {
···147}
148```
149150+:::
151+152## `testEqualDerivation` {#tester-testEqualDerivation}
153154Checks that two packages produce the exact same build instructions.
155156+This can be used to make sure that a certain difference of configuration, such as the presence of an overlay does not cause a cache miss.
0157158When the derivations are equal, the return value is an empty file.
159Otherwise, the build log explains the difference via `nix-diff`.
160161+:::{.example #ex-testEqualDerivation-hello}
162+163+# Check that two packages produce the same derivation
164165```nix
166testers.testEqualDerivation
···169 (hello.overrideAttrs(o: { doCheck = true; }))
170```
171172+:::
173+174## `invalidateFetcherByDrvHash` {#tester-invalidateFetcherByDrvHash}
175176Use the derivation hash to invalidate the output via name, for testing.
177178Type: `(a@{ name, ... } -> Derivation) -> a -> Derivation`
179180+Normally, fixed output derivations can and should be cached by their output hash only, but for testing we want to re-fetch everytime the fetcher changes.
181+182+Changes to the fetcher become apparent in the drvPath, which is a hash of how to fetch, rather than a fixed store path.
183+By inserting this hash into the name, we can make sure to re-run the fetcher every time the fetcher changes.
184185+This relies on the assumption that Nix isn't clever enough to reuse its database of local store contents to optimize fetching.
000186187+You might notice that the "salted" name derives from the normal invocation, not the final derivation.
188+`invalidateFetcherByDrvHash` has to invoke the fetcher function twice:
189+once to get a derivation hash, and again to produce the final fixed output derivation.
190191+:::{.example #ex-invalidateFetcherByDrvHash-nix}
000192193+# Prevent nix from reusing the output of a fetcher
194195```nix
196tests.fetchgit = testers.invalidateFetcherByDrvHash fetchgit {
···201};
202```
203204+:::
205+206## `runNixOSTest` {#tester-runNixOSTest}
207208A helper function that behaves exactly like the NixOS `runTest`, except it also assigns this Nixpkgs package set as the `pkgs` of the test and makes the `nixpkgs.*` options read-only.
209210If your test is part of the Nixpkgs repository, or if you need a more general entrypoint, see ["Calling a test" in the NixOS manual](https://nixos.org/manual/nixos/stable/index.html#sec-calling-nixos-tests).
211212+:::{.example #ex-runNixOSTest-hello}
213+214+# Run a NixOS test using `runNixOSTest`
215216```nix
217pkgs.testers.runNixOSTest ({ lib, ... }: {
···225})
226```
227228+:::
229+230## `nixosTest` {#tester-nixosTest}
231232Run a NixOS VM network test using this evaluation of Nixpkgs.
233234NOTE: This function is primarily for external use. NixOS itself uses `make-test-python.nix` directly. Packages defined in Nixpkgs [reuse NixOS tests via `nixosTests`, plural](#ssec-nixos-tests-linking).
235236+It is mostly equivalent to the function `import ./make-test-python.nix` from the [NixOS manual](https://nixos.org/nixos/manual/index.html#sec-nixos-tests), except that the current application of Nixpkgs (`pkgs`) will be used, instead of letting NixOS invoke Nixpkgs anew.
000237238+If a test machine needs to set NixOS options under `nixpkgs`, it must set only the `nixpkgs.pkgs` option.
0239240### Parameter {#tester-nixosTest-parameter}
241
+2
nixos/doc/manual/release-notes/rl-2405.section.md
···4142- `k9s` was updated to v0.29. There have been breaking changes in the config file format, check out the [changelog](https://github.com/derailed/k9s/releases/tag/v0.29.0) for details.
430044- Invidious has changed its default database username from `kemal` to `invidious`. Setups involving an externally provisioned database (i.e. `services.invidious.database.createLocally == false`) should adjust their configuration accordingly. The old `kemal` user will not be removed automatically even when the database is provisioned automatically.(https://github.com/NixOS/nixpkgs/pull/265857)
4546- `mkosi` was updated to v19. Parts of the user interface have changed. Consult the
···4142- `k9s` was updated to v0.29. There have been breaking changes in the config file format, check out the [changelog](https://github.com/derailed/k9s/releases/tag/v0.29.0) for details.
4344+- `nitter` requires a `guest_accounts.jsonl` to be provided as a path or loaded into the default location at `/var/lib/nitter/guest_accounts.jsonl`. See [Guest Account Branch Deployment](https://github.com/zedeus/nitter/wiki/Guest-Account-Branch-Deployment) for details.
45+46- Invidious has changed its default database username from `kemal` to `invidious`. Setups involving an externally provisioned database (i.e. `services.invidious.database.createLocally == false`) should adjust their configuration accordingly. The old `kemal` user will not be removed automatically even when the database is provisioned automatically.(https://github.com/NixOS/nixpkgs/pull/265857)
4748- `mkosi` was updated to v19. Parts of the user interface have changed. Consult the
···304 '';
305 };
30600000000000000000307 redisCreateLocally = mkOption {
308 type = types.bool;
309 default = true;
···333 after = [ "network-online.target" ];
334 serviceConfig = {
335 DynamicUser = true;
0336 StateDirectory = "nitter";
337- Environment = [ "NITTER_CONF_FILE=/var/lib/nitter/nitter.conf" ];
000338 # Some parts of Nitter expect `public` folder in working directory,
339 # see https://github.com/zedeus/nitter/issues/414
340 WorkingDirectory = "${cfg.package}/share/nitter";
···304 '';
305 };
306307+ guestAccounts = mkOption {
308+ type = types.path;
309+ default = "/var/lib/nitter/guest_accounts.jsonl";
310+ description = lib.mdDoc ''
311+ Path to the guest accounts file.
312+313+ This file contains a list of guest accounts that can be used to
314+ access the instance without logging in. The file is in JSONL format,
315+ where each line is a JSON object with the following fields:
316+317+ {"oauth_token":"some_token","oauth_token_secret":"some_secret_key"}
318+319+ See https://github.com/zedeus/nitter/wiki/Guest-Account-Branch-Deployment
320+ for more information on guest accounts and how to generate them.
321+ '';
322+ };
323+324 redisCreateLocally = mkOption {
325 type = types.bool;
326 default = true;
···350 after = [ "network-online.target" ];
351 serviceConfig = {
352 DynamicUser = true;
353+ LoadCredential="guestAccountsFile:${cfg.guestAccounts}";
354 StateDirectory = "nitter";
355+ Environment = [
356+ "NITTER_CONF_FILE=/var/lib/nitter/nitter.conf"
357+ "NITTER_ACCOUNTS_FILE=%d/guestAccountsFile"
358+ ];
359 # Some parts of Nitter expect `public` folder in working directory,
360 # see https://github.com/zedeus/nitter/issues/414
361 WorkingDirectory = "${cfg.package}/share/nitter";
···1import ./make-test-python.nix ({ pkgs, ... }:
23+let
4+ # In a real deployment this should naturally not common from the nix store
5+ # and be seeded via agenix or as a non-nix managed file.
6+ #
7+ # These credentials are from the nitter wiki and are expired. We must provide
8+ # credentials in the correct format, otherwise nitter fails to start. They
9+ # must not be valid, as unauthorized errors are handled gracefully.
10+ guestAccountFile = pkgs.writeText "guest_accounts.jsonl" ''
11+ {"oauth_token":"1719213587296620928-BsXY2RIJEw7fjxoNwbBemgjJhueK0m","oauth_token_secret":"N0WB0xhL4ng6WTN44aZO82SUJjz7ssI3hHez2CUhTiYqy"}
12+ '';
13+in
14{
15 name = "nitter";
16 meta.maintainers = with pkgs.lib.maintainers; [ erdnaxe ];
1718 nodes.machine = {
19+ services.nitter = {
20+ enable = true;
21+ # Test CAP_NET_BIND_SERVICE
22+ server.port = 80;
23+ # Provide dummy guest accounts
24+ guestAccounts = guestAccountFile;
25+ };
26 };
2728 testScript = ''