about summary refs log tree commit diff
path: root/tests/default.nix
Commit message (Collapse)AuthorAgeFilesLines
* tests/profpatsch/programs/nman: add nixos test for nmansternenseemann2021-02-251-0/+1
| | | | | | | | | | | We can't really do normal unit tests, since they'd be integration tests requiring nix. Recursive nix is also a bad idea in normal derivations, so we add a NixOS test for nman. Here we are also somewhat limited since we already need to have all store paths used by nman in /nix/store otherwise we'd need to access the network which would fail. However we can verify that nman only builds specific store paths before finding the desired man page this way.
* profiles/workstation: Add Flameshotaszlig2021-02-131-0/+1
| | | | | | | | | | | So far I've almost exclusively used scrot for screenshots, but most of the time I used an image manipulation program to pixelate stuff, add descriptions or draw arrows. Flameshot combines this in a single application, so I expect that from now on I can spam-post screenshots in even a higher rate than before ;-) Signed-off-by: aszlig <aszlig@nix.build>
* pkgs/psi: Fix Qt5 application wrappingaszlig2019-09-231-0/+1
| | | | | | | | | | | | | Qt applications are no longer implicitly wrapped since a while[1] and so we new have to use wrapQtAppsHook instead, which also makes the wrapping for Psi obsolete. To make sure we don't run into startup errors again, I added a small VM test, which checks whether the application starts up properly. [1]: https://github.com/NixOS/nixpkgs/commit/f79fd2e826dd95b3b64839d3e0bec8ae1dfab17e Signed-off-by: aszlig <aszlig@nix.build>
* machines/dnyarri: Enable bcache kernel moduleaszlig2018-12-241-0/+1
| | | | | | | | | | | | | | | Since I got a new SSD for the machine (thanks @cvdnext), I also had the opportunity to re-create my LUKS containers to LUKS2 with Argon2 key derivation alongside creating bcache backing devices. The change in order to support bcache is just a matter of adding "bcache" to availableKernelModules and we're done. However, as the storage configuration is not a very common one, I decided to add a test specific to that to make sure future NixOS updates won't prevent the machine from booting. Signed-off-by: aszlig <aszlig@nix.build>
* tests: Pass in nixpkgs source from release.nixaszlig2018-04-031-2/+5
| | | | | | | | | Another point where we rely on nixpkgs-path.nix from within release.nix, where we already have the correct path to nixpkgs passed as an argument. So let's simply pass that argument along to the actual test. Signed-off-by: aszlig <aszlig@nix.build>
* tests/games/sandbox: Rename to tests/sandboxaszlig2017-11-211-1/+1
| | | | | | | | | | | We have excluded all tests within the games directory from being built by Hydra, rightfully so because they're proprietary. However our sandbox is *not* proprietary so we want to have it tested. Besides, we might want to use that sandbox for other things rather than just games in the future, which saves us that rename later ;-) Signed-off-by: aszlig <aszlig@nix.build>
* tests: Add simple test for buildSandboxaszlig2017-11-211-0/+1
| | | | | | | | This is only a very rudimentary test of the sandbox implementation, but it already serves as a series of regression test for a few problems I ran into so far. Signed-off-by: aszlig <aszlig@nix.build>
* Remove service and tests for multipath-vpnaszlig2017-07-061-4/+0
| | | | | | | | | | The service and test has been broken for a long time now and nobody really has any interest in using it or even fixing it, so I'm removing it to decrease the amount of crap we have in there. If somebody still wants to use this someday we can still bring it back. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* modules: Move BFQ stuff into its dedicated moduleaszlig2017-07-061-0/+3
| | | | | | | | | Not everybody likes to have the latest release canidate kernel, so we now have an option called vuizvui.system.kernel.bfq.enable, which *only* enables the BFQ scheduler per default. Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @devhell
* tests: Remove reference to aszlig.i3aszlig2016-05-281-3/+0
| | | | | | Forgot to do that in ea85dd3eaf0cbd19ddf22f41391d092a21147063. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* modules: Rename gpg-agent to gnupgaszlig2016-04-041-1/+1
| | | | | | | | | We do things such as placing gnupg into environment.systemPackages, so calling this just "programs.gpg-agent" doesn't fit that. Especially if we really want to have a way to specify configuration values in case I'm getting masochistic someday ;-) Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* Add a new module and test for gpg-agentaszlig2016-04-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since NixOS/nixpkgs@5391882 there no longer is the option to start the agent during X session startup, which prompted me to write this module. I was unhappy how GnuPG is handled in NixOS since a long time and wanted to OCD all the configuration files directly into the module. Unfortunately, this is something I eventually gave up because GnuPG's design makes it very hard to preseed configuration. My first attempt was to provide default configuration files in /etc/gnupg, but that wasn't properly picked up by GnuPG. Another way would have been to change the default configuration files, but that would have the downside that we could only override those configurations using command line options for each individual GnuPG component. The approach I tried to go for was to patch GnuPG so that all the defaults are directly set in the source code using a giant sed expression. It turned out that this approach doesn't work very well, because every component has implemented its own ways how to handle commandline arguments versus (default) configuration files. In the end I gave up trying to OCD anything related to GnuPG configuration and concentrated just on the agent. And that's another beast, which unfortunately doesn't work very well with systemd. While searching the net for existing patches I stumbled upon one done by @shlevy: https://lists.gnupg.org/pipermail/gnupg-devel/2014-November/029092.html Unfortunately, the upstream author seems to be quite anti-systemd and didn't want to accept that into the upstream project. Because of this I went for using LD_PRELOAD to pick up the file descriptors provided by the systemd sockets, because in the end I don't want to constantly catch up with upstream and rebase the patch on every new release. Apart from just wrapping the agent to be socket activated, we also wrap the pinentry program, so that we can inject a _CLIENT_PID environment variable from the LD_PRELOAD wrapper that is picked up by the pinentry wrapper to determine the TTY and/or display of the client communicating with the agent. The wrapper uses the proc filesystem to get all the relevant information and passes it to the real pinentry. The advantage of this is that we don't need to do things such as "gpg-connect-agent updatestartuptty /bye" or any other workarounds and even if we connect via SSH the agent should be able to correctly pick up the TTY and/or display. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* modules: Add new Starbound service and testaszlig2016-03-151-0/+3
| | | | | | | | | | | | | | | | | | | | | Very preliminary and doesn't have all the option descriptions right, nor does it have convenience features such as setting allowAdminCommands based on whether any users are defined with admin privileges. Of course the latter needs to undergo the decision on how to handle RCON connections, because the latter *might* need that option. But apart from that single option, there are a lot more options we need to flesh out. Also, the test currently is very limited and only spins up a client, connects to the server and does a movement (just walk to the right). Needless to say, it's even quite fragile and relies on OCR to properly detect the custom pixel fonts from Starbound. Which unfortunately fails most of the time. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* Remove all references to "heinrich"aszlig2016-03-051-3/+0
| | | | | | | | | This was a very old effort to NixOSify "heinrich" which unfortunately didn't happen and I'm not sure whether "heinrich" even exists anymore. The tests were broken anyway, so I doubt anyone would grief over it. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* tests: Disable multipath-vpn test.aszlig2015-11-161-1/+2
| | | | | | | The test is broken since it was introduced for the first time in 080933b2f158e7a3f0dfc4e7f499c0e3752cd3fc. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* tests/richi235: Add VM test for multipath VPN.aszlig2015-03-181-0/+3
| | | | | | | | This is where I previously left off and I'm currently not enough "in zone" to remember the details. But even though the tests are failing, I'm adding it here for reference and for picking it up later. Signed-off-by: aszlig <aszlig@redmoonstudios.org>
* tests: Refactor to something similar as machines/.aszlig2015-03-181-0/+15
Similar to callMachine, we now have callTest. The latter uses make-test.nix, so we don't need to import the file explicitly anymore and can just write our VM test by using either an attrset or a lambda function which also gets our own packages in a vuizvui namespace. Signed-off-by: aszlig <aszlig@redmoonstudios.org>