Since 83b27f60ce, the tests were moved
into all-tests.nix and some of the tooling has changed so that
subattributes of test expressions are now recursively evaluated until a
derivation with a .test attribute has been found.
Unfortunately this isn't the case for all of the tests and the
runInMachine doesn't use the makeTest function other tests are using but
instead uses runInMachine, which doesn't generate a .test attribute.
Whener a .test attribute wasn't found by the new handleTest function, it
recurses down again until there is no value left that is an attribute
set and subsequently returns its unchanged value. This however has the
drawback that instead of getting different attributes for each
architecture we only get the last architecture in the supportedSystems
list.
In the case of the release.nix, the last architecture in
supportedSystems is "aarch64-linux", so the runInMachine test is always
built on that architecture.
In order to work around this, I changed runInMachine to emit a .test
attribute so that it looks to handleTest like it was a test created via
makeTest.
Signed-off-by: aszlig <aszlig@nix.build>
Docker images used to be, essentially, a linked list of layers. Each
layer would have a tarball and a json document pointing to its parent,
and the image pointed to the top layer:
imageA ----> layerA
|
v
layerB
|
v
layerC
The current image spec changed this format to where the Image defined
the order and set of layers:
imageA ---> layerA
|--> layerB
`--> layerC
For backwards compatibility, docker produces images which follow both
specs: layers point to parents, and images also point to the entire
list:
imageA ---> layerA
| |
| v
|--> layerB
| |
| v
`--> layerC
This is nice for tooling which supported the older version and never
updated to support the newer format.
Our `buildImage` code only supported the old version, so in order for
`buildImage` to properly generate an image based on another image
with `fromImage`, the parent image's layers must fully support the old
mechanism.
This is not a problem in general, but is a problem with
`buildLayeredImage`.
`buildLayeredImage` creates images with newer image spec, because
individual store paths don't have a guaranteed parent layer. Including
a specific parent ID in the layer's json makes the output less likely
to cache hit when published or pulled.
This means until now, `buildLayeredImage` could not be the input to
`buildImage`.
The changes in this PR change `buildImage` to only use the layer's
manifest when locating parent IDs. This does break buildImage on
extremely old Docker images, though I do wonder how many of these
exist.
This work has been sponsored by Target.
GitLab 11.5.1 dropped the dependency to posix_spawn, which is broken on
32bit. (See https://gitlab.com/gitlab-org/gitlab-ce/issues/53525)
The only part missing is decreasing virtualisation.memorySize to
something that a 32 bit qemu still executes.
The maximum seems to be 2047, and tests passed with that value for me.
This also includes a full end-to-end CockroachDB clustering test to
ensure everything basically works. However, this test is not currently
enabled by default, though it can be run manually. See the included
comments in the test for more information.
Closes #51306. Closes #38665.
Co-authored-by: Austin Seipp <aseipp@pobox.com>
Signed-off-by: Austin Seipp <aseipp@pobox.com>
When reworking the rspamd workers I disallowed `proxy` as a type and
instead used `rspamd_proxy` which is the correct name for that worker
type. That change breaks peoples existing config and so I have made this
commit which allows `proxy` as a worker type again but makes it behave
as `rspamd_proxy` and prints a warning if you use it.
This commit adds an assertion that checks that either `configFile` or
`configuration` is configured for alertmanager. The alertmanager config
can not be an empty attributeset. The check executed with `amtool` fails
before the service even has the chance to start. We should probably not
allow a broken alertmanager configuration anyway.
This also introduces a test for alertmanager configuration that piggy
backs on the existing prometheus tests.
The nixos test is a bit misleading, as the given nginx configuration
would always cause gitlab to redirect to localhost, which is clearly not
what you want in a production setup.
Instead we now enable services.nginx.recommendedProxySettings,
curl against http://gitlab, and assure we get redirected to that same
hostname, too.
previously one of the tests would fail with
boot-after-install: starting vm
Path length (109) is longer than maximum supported length (108) and will be truncated at /nix/store/0ingn8cwwnl84i374hcl6nafsm2c5m2p-perl-5.28.0/lib/perl5/5.28.0/x86_64-linux-thread-multi/Socket.pm line 872, <__ANONIO__> line 268.
boot-after-install# qemu-system-x86_64: -monitor unix:./monitor: Failed to connect socket ./monitor: No such file or directory
error: QEMU died prematurely
QEMU died prematurely
vde_switch: EOF on stdin, cleaning up and exiting
cleaning up
builder for '/nix/store/zbpxwwxwy7f6z5z3kg4nf5mjqsywzjvx-vm-test-run-installer-filesystemEncryptedWithKeyfile.drv' failed with exit code 4
Shortening the test name fixes the issue.
This will make the list much easier to re-use, eg. for `nixosTests`
The drawback is that this approaches makes the
```
nix-build release.nix -A tests.opensmtpd.x86_64-linux
```
command about twice as slow (3s to 6s): it now has to evaluate `nixpkgs`
once for each architecture, instead of just having the hardcoded list of
tests that allowed to say “ok just evaluate for x86_64-linux”.
On the other hand, complete evaluation of `release.nix` should be much
faster because we no longer import `nixpkgs` for each test: testing with
the following command went from 30s to 18s, and that's just for a few
tests.
```
time nix-instantiate --eval --strict nixos/release.nix -A tests.nat
```
I initially wanted to test on the whole `release.nix`, but there are too
many broken tests and it takes too long to eval them all, especially
compared to the fact that the current implementation breaks some setup.
Given developers can just `nix-build nixos/tests/my-test.nix`, it sounds
like an overall win.
The `rmilter` module has options for configuring `postfix` to use it but
since that module is deprecated because rspamd now has a builtin worker
that supports the milter protocol this commit adds similar `postfix`
integration options directly to the `rspamd` module.
The lines stored in `extraConfig` and `worker.<name?>.extraConfig`
should take precedent over values from included files but in order to do
this in rspamd UCL they need to be stored in a file that then gets
included with a high priority. This commit uses the overrides option to
store the value of the two `extraConfig` options in `extra-config.inc`
and `worker-<name?>.inc` respectively.
When the workers option for rspamd was originally implemented it was
based on a flawed understanding of how workers are configured in rspamd.
This meant that while rspamd supports configuring multiple workers of
the same type, so that different controller workers could have different
passwords, the NixOS module did not support this because it would write
an invalid configuration file if you tried.
Specifically a configuration like the one below:
```
workers.controller = {};
workers.controller2 = {
type = "controller";
};
```
Would result in a rspamd configuration of:
```
worker {
type = "controller";
count = 1;
.include "$CONFDIR/worker-controller.inc"
}
worker "controller2" {
type = "controller";
count = 1;
}
```
While to get multiple controller workers it should instead be:
```
worker "controller" {
type = "controller";
count = 1;
.include "$CONFDIR/worker-controller.inc"
}
worker "controller" {
type = "controller";
count = 1;
}
```
When implementing #49620 I included an enable option for both the
locals and overrides options but the code writing the files didn't
actually look at enable and so would write the file regardless of its
value. I also set the type to loaOf which should have been attrsOf
since the code was not written to handle the options being lists.
This fixes both of those issues.
This module permits to preload Docker image in a VM in order to reduce
OIs on file copies. This module has to be only used in testing
environments, when the test requires several Docker images such as in
Kubernetes tests. In this case,
`virtualisation.dockerPreloader.images` can replace the
`services.kubernetes.kubelet.seedDockerImages` options.
The idea is to populate the /var/lib/docker directory by mounting qcow
files (we uses qcow file to avoid permission issues) that contain images.
For each image specified in
config.virtualisation.dockerPreloader.images:
1. The image is loaded by Docker in a VM
2. The resulting /var/lib/docker is written to a QCOW file
This set of QCOW files can then be used to populate the
/var/lib/docker:
1. Each QCOW is mounted in the VM
2. Symlink are created from these mount points to /var/lib/docker
3. A /var/lib/docker/image/overlay2/repositories.json file is generated
4. The docker daemon is started.
As reported by @andir, the regular expressions that match the sandbox
output are no longer matching in the recent Chromium bump as of
bb03fbc2c8.
Instead of a boolean field that determines whether namespace sandboxes
are on, the namespace sandbox is now an enum within "Layer 1 Sandbox".
I've modified the regular expressions accordingly and also ran the test
for the stable branch, which now succeeds.
Signed-off-by: aszlig <aszlig@nix.build>
Issue: https://github.com/NixOS/nixpkgs/issues/49442
Cc: @bendlas, @andir
By default rspamd will look for multiple files in /etc/rspamd/local.d
and /etc/rspamd/override.d to be included in subsections of the merged
final config for rspamd. Most of the config snippets in the official
rspamd documentation are made to these files and so it makes sense for
NixOS to support them and this is what this commit does.
As part of rspamd 1.8.1 support was added for having custom Lua
rules stored in $LOCAL_CONFDIR/rspamd.local.lua which means that it is
now possible for NixOS to support such rules and so this commit also
adds support for this to the rspamd module.
Rationale
---------
Currently, tests are hard to discover. For instance, someone updating
`dovecot` might not notice that the interaction of `dovecot` with
`opensmtpd` is handled in the `opensmtpd.nix` test.
And even for someone updating `opensmtpd`, it requires manual work to go
check in `nixos/tests` whether there is actually a test, especially
given not so many packages in `nixpkgs` have tests and this is thus most
of the time useless.
Finally, for the reviewer, it is much easier to check that the “Tested
via one or more NixOS test(s)” has been checked if the file modified
already includes the list of relevant tests.
Implementation
--------------
Currently, this commit only adds the metadata in the package. Each
element of the `meta.tests` attribute is a derivation that, when it
builds successfully, means the test has passed (ie. following the same
convention as NixOS tests).
Future Work
-----------
In the future, the tools could be made aware of this `meta.tests`
attribute, and for instance a `--with-tests` could be added to
`nix-build` so that it also builds all the tests. Or a `--without-tests`
to build without all the tests. @Profpatsch described in his NixCon talk
such systems.
Another thing that would help in the future would be the possibility to
reasonably easily have cross-derivation nix tests without the whole
NixOS VM stack. @7c6f434c already proposed such a system.
This RFC currently handles none of these concerns. Only the addition of
`meta.tests` as metadata to be used by maintainers to remember to run
relevant tests.
* journald: forward message to syslog by default if a syslog implementation is installed
* added a test to ensure rsyslog is receiving messages when expected
* added rsyslogd tests to release.nix
- added package option to specify which version of redmine
- added themes option back in to allow specifying redmine themes
- added plugins option back in to allow specifying redmine plugins
- added database.socket option to allow mysql unix socket authentication
- added port option to allow specifying the port rails runs on
- cleaned up Gemfile so it is much less hacky
- switched to ruby version 2.4 by default as suggested by documentation http://www.redmine.org/projects/redmine/wiki/redmineinstall#Installing-Redmine
- fixed an annoyance (bug) in the service causing recursive symlinks
- fixed ownership bug on log files generated by redmine
- updates reflecting renames in nixos options
- added a nixos test
From commit b63f65aea0dea11c20e9299210af1d2ee4299b58:
I used tmpfiles.d instead of activation snippets to create the logs.
It's good enough for upstream and other distros; it's probably good
enough for us.
The "reboot-wtmp" subtest fails because it it assumes that there is a
reboot record even on the initial boot. This is only the case if wtmp is
created within the activation script, but the implementation now uses
tmpfiles.d, so the creation of the file is done at a much later stage.
Apart from that, if you think about the state after the installation as
"first boot", using the term "reboot" wouldn't probably make sense
either.
So in our subtest, we now reboot the machine and check the wtmp record
afterwards as we did before.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @edolstra, @jameysharp, @Mic92
The socket activation I added to the rspamd module doesn't actually work
and can't be made to work without changes to rspamd.
See: #47421
See: rspamd/rspamd#2035
The test failed on Hydra in one instance because a request to the
server was sent before indexing was finished.
Retry the request until it succeeds (or times out).
The test failed in one run on Hydra, logs look like
dhcpcd changed ipv6 routing at just the wrong time.
Disable dhcpcd. It's not needed, the test uses static IPs anyway.
Test didn't run because it tried to create a VM with 4096M RAM
but qemu-system-i386 has a hard 2047M memory limit.
- reduce memory to 2047M on i686.
- increase timeout 300s -> 1800s because the tests are much slower
on i686 and timed out.
The `pkgs.yabar` package is relatively old (2016-04) and contains
several issues fixed on master. `yabar-unstable` containsa recent master
build with several fixes and a lot of new features (I use
`yabar-unstable` for some time now and had no issues with it).
In the upstream bugtracker some bugs could be fixed on ArchLinux by
simply installing `yabar-git` (an AUR package which builds a recent
master).
To stabilize the module, the option `programs.yabar.package` now
defaults to `pkgs.yabar-unstable` and yields a warning with several
linked issues that are known on `pkgs.yabar`.
The test has been refactored as well to ensure that `yabar` actually
starts (and avoid non-deterministic random success) and takes a
screenshot of a very minimalistic configuration on IceWM.
Fixes #46899
This attempts to improve stability of the test by using existing
services for miniupnpd and transmission.
It also uses explicit addresses for the network interfaces so that the
external IP addresses are valid internet addresses (thus fixing
validation problems from upnpc).
Also disable eth0 from being used to transfer torrents over without that
being the intention.
A sporadic failure occured on Hydra because a request was sent
to smtpd after the systemd unit was started, but before the daemon
was actually listening. Fix by checking for open ports first.
A sporadic failure occured on Hydra because a request was sent
to the daemon after the systemd unit was started, but before the
daemon was actually listening. Fix by checking for open port first.
Generated reverse path filtering rules for the macvlan interface
seem to be incorrect, causing the test to fail - sometimes or always,
depending on the dhcpcd version used.
- Disable reverse path checking temporarily to avoid blocking the channel
- Print more diagnostic information for debugging
The switch to lightdm as default display manager in #30890
broke eval of the flatpak test. Since the test uses the
auto display manager (lightdm), gdm must now be explicitly disabled.
Since 1b11fdd0df the test VM
depends on some extra packages to build the system to be installed.
This broke the installer test as it tried to download/build these
packages in a sandbox.
Switch from slim to lightdm as the display-manager.
If plasma5 is used as desktop-manager use sdddm.
If gnome3 is used as desktop-manager use gdm.
Based on #12516
The wallpaper used is *structurally compatible* with the other one,
meaning that the logo is at the same location, and not bigger.
It has one drawback: the logo is brighter, which clashes with the grub
usage. This is to be fixed with new options in grub.
The test sporadically failed on hydra when a request was made
before the service was actually listening on its port.
Explicitly wait for the port to open.
Since matrix-synapse 0.33.0 underscores in server names are rejected
by server name validation, causing the test to fail:
valueError: Server name 'server_sqlite' contains invalid characters
Relevant upstream change:
546bc9e28b
- wait for node to listen before starting munin-cron
- increase timeout for munin-cron startup
- disable a failing plugin to remove irrelevant error message
This bumps Hydra to the latest revision available. As Hydra doesn't have
a release model (and therefore no tags) ATM, the derivation will pin
against the actual git revision and the date of the commit in the
derivation name.
Additionally the following changes have been made:
* Dropped `postUnpack` phase. It is useful when working with the Hydra
source (and no dirty changes shall be used in `release.nix`, but is has
no use in `nixpkgs`).
* Added myself as maintainer to have more folks available in case of
future breakage.
* Implemented support for Nix 2.0 and `unstable` (currently 2.1):
Since 1672bcd230447f1ce0c3291950bdd9a662cee974 in NixOS/nix the
evaluator differentiates between `settings` and `evalSettings`.
Previously `restrictEval` in `hydra-eval-jobs.cc` has been set in
`settings`, this doesn't work anymore in Nix 2.1 and is therefore
incompatible to Nix 2.0 on an API level.
To resolve this, the flag `isGreaterNix20` parses the version string
of `pkgs.nix` and applies a patch if nix.version<=2.0.
Furthermore the Hydra build with Nix 2.1 requires `boost` as build input
which is not needed for Nix 2.0. To avoid unnecessary increase in the
closure size this library will only used as build input for
nix.version>2.0.
* Fixed the NixOS test for `hydra`:
disabled binary cache to allow sandbox builds (otherwise it would
query `cache.nixos.org` during the Hydra build inside the test).
Additionally the trivial.nix jobset required simplification (as done
in NixOS/hydra, e.g. tests/api-test.nix) as bash is not available in
the build sandbox as builder (even when adding pkgs.bash to
systemPackages).
The easiest workaround to confirm a the functionality of a jobset
without importing nixpkgs is to use the default shell /bin/sh which
is mounted from `pkgs.busybox` into the build env
(https://github.com/NixOS/nixpkgs/pull/44841#discussion_r209751972) in the
VM and a named pipe to create $out.
Closes #44044
Since a9d69a74d6, the passphrase prompt
now no longer starts with "Enter passphrase for" but now it's just
"Passphrase for", which causes the luksroot installer test to fail.
I've tested this on a x86_64-linux machine and the test now succeeds.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @oxij, @samueldr
Issue: #29441
The web_access.patch would no longer apply.
It disabled a check that required the static files
for the web UI to be owned by the user the daemon runs as
(not root, so it doesn't work well with nix).
Besides updating netdata, this commit removes that patch,
changes the netdata service config to set the "web files owner/group"
option to "root" and adds a test that checks that the web UI is being served.
This allows the web files to be owned by root without patching.
- based on module originally written by @srhb
- complies with available options in cfssl v1.3.2
- uid and gid 299 reserved in ids.nix
- added simple nixos test case
Fixes #30891
* Upgrade `graphite-web`, `carbon` and `whisper` from 1.0.2 -> 1.1.3.
* Replaced the deprecated `pythonPackages.graphite_influxdb` with
`pythonPackages.influxgraph.`
* Renamed `pythonPackages.graphite_web` to `pythonPackages.graphite-web`
to be consistent with the Python package name.
* Replaced the unmaintained `pythonPackages.graphite_pager` with
`pythonPackages.graphitepager`
* Moved all new packages from `python-packages.nix` to
`pkgs/development/python-modules`
Since 4f6df27aee, nix.useSandbox defaults
to true which causes the Nix build within the containers-imperative test
to fail while trying to hardlink files into the chroot:
link("/nix/store/foo", "/nix/store/bar.drv.chroot/nix/store/foo")
= -1 EPERM (Operation not permitted)
The reason this happens is that the hosts store is mounted using 9p and
an overlayfs is mounted on top, so even if we would disable the tmpfs
for the upper directory the hardlink would still cross filesystem
boundaries, which then fails with the above error code.
I haven't yet seen any other test which fails in a similar way, which
might be because building within VM tests is not very common and the
installer tests build in a separate store, so they're not affected.
Signed-off-by: aszlig <aszlig@nix.build>
Issue: https://github.com/NixOS/nix/issues/2324
Cc: @aristidb, @edolstra, @chaoflow, @kampfschlaefer
* The ELK stack is upgraded to 6.3.2.
* `elasticsearch6`, `logstash6` and `kibana6` now come with X-Pack which is
a suite of additional features. These are however licensed under the unfree
"Elastic License".
* Fortunately they also provide OSS versions which are now packaged
under: `elasticsearch6-oss`, `logstash6-oss` and `kibana6-oss`.
Note that the naming of the attributes is consistent with upstream.
* The test `nix-build nixos/tests/elk.nix -A ELK-6` will test the OSS
version by default. You can also run the test on the unfree ELK using:
`NIXPKGS_ALLOW_UNFREE=1 nix-build nixos/tests/elk.nix -A ELK-6 --arg enableUnfree true`
This reverts commit 095fe5b43d.
Pointless renames considered harmful. All they do is force people to
spend extra work updating their configs for no benefit, and hindering
the ability to switch between unstable and stable versions of NixOS.
Like, what was the value of having the "nixos." there? I mean, by
definition anything in a NixOS module has something to do with NixOS...
This makes the command ‘nix-env -qa -f. --arg config '{skipAliases =
true;}'’ work in Nixpkgs.
Misc...
- qtikz: use libsForQt5.callPackage
This ensures we get the right poppler.
- rewrites:
docbook5_xsl -> docbook_xsl_ns
docbook_xml_xslt -> docbook_xsl
diffpdf: fixup
In 0c7c1660f7 I have set allowSubstitutes
to false, which avoided the substitution of the certificates.
Unfortunately substitution may still happen later when the certificate
is merged with the CA bundle. So the merged CA bundle might be
substituted from a binary cache but the certificate itself is built
locally, which could result in a different certificate in the bundle.
So instead of adding just yet another workaround, I've now hardcoded all
the certificates and keys in a separate file. This also moves
letsencrypt.nix into its own directory so we don't mess up
nixos/tests/common too much.
This was long overdue and should finally make the dependency graph for
the ACME test more deterministic.
Signed-off-by: aszlig <aszlig@nix.build>
Since e95f17e272, Go packages no longer
contain the source tree, however Boulder seems to need that as it
generates a few files during build.
Ideally we would only pick the files that are needed and put it into a
separate output, but I currently don't have time for this so I'm marking
this with XXX to get back to it later.
Signed-off-by: aszlig <aszlig@nix.build>
Since IP address options were changed for 18.03, eval has failed with:
"The option `networking.interfaces.eth1.subnetMask' is used but not defined."
although this option is not used at all in nixos anymore.
The misleading error message seems to be generated from evaluating warnings
for `mkRemovedOptionModule ["subnetMask"]` which apparently broke here
when this test inherited network.interfaces from one VM config to another.
Cc: @aszlig
If one of the certificates of the chain gets substituted from a binary
cache and the rest is generated locally it might turn out that we get
invalid certificates, which in turn cause tests using this module to
fail.
So let's set allowSubstitutes to false for all derivations that are
involved with certificate/key generation.
Signed-off-by: aszlig <aszlig@nix.build>
For now check that the default client config boots.
Ideas for the future:
- Expand on control via netcat
- Configure a circuit of nodes exercise various configs (e.g., check
that a client node can access a hidden www service). Needs setting up
authoritative directory servers &c.
This change adds NixOS tests for the MPD (Music Player Daemon) module.
Tests include:
- Playing audio locally using ALSA directly.
- Playing audio locally using PulseAudio (backed by ALSA).
- Playing audio from an external client.
- Rejecting an external client when it's not explicitly allowed (default configuration).
refs #41772
A script is used to create a project, and configure a jobset. This
jobset fetches a local file containing a trivial Nix expression. The
test script makes sure this derivation has been successfully built by
Hydra.
While building the container there are a few occasions where stdenvNoCC
is used underneath. During the last staging merge, some change now tries
to build texinfo during the test while building stdenvNoCC.
With this change, I'm adding stdenvNoCC to the closure to make sure that
even when we have future stdenv changes, it doesn't break (well, except
if we do have another variation like stdenvNoCC that overrides stdenv).
I haven't bisected the exact change, but I'd suspect that it could be
one of the commits in #39457.
This fixes the test and it no longer fails with the following error:
error: unable to download 'http://ftpmirror.gnu.org/texinfo/texinfo-6.5.tar.xz': Couldn't resolve host name (6)
builder for '/nix/store/r7sf1wjbnimwgnv276jh59nfnzw40x30-texinfo-6.5.tar.xz.drv' failed with exit code 1
cannot build derivation '/nix/store/5w1pv788ayi1wahyy76i90yqv96ai4h5-texinfo-6.5.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/cnsfkf0j5xmm14zzm5a3a66pz66gbc82-stdenv-linux.drv': 1 dependencies couldn't be built
cannot build derivation '/nix/store/11kkhk57ic8kfd7g197sqwgd0pzqfjhl-nixos-system-foo-0-18.09pre-git.drv': 1 dependencies couldn't be built
error: build of '/nix/store/11kkhk57ic8kfd7g197sqwgd0pzqfjhl-nixos-system-foo-0-18.09pre-git.drv' failed
/run/current-system/sw/bin/nixos-container: failed to build initial container configuration
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @aristidb, @edolstra, @chaoflow, @kampfschlaefer
BIND doesn't allow the options section (or any section I'd guess) to be
defined more than once, so whenever you want to set an additional option
you're stuck using weird hacks like this:
services.bind.forwarders = lib.mkForce [ "}; empty-zones-enable no; #" ];
This basically exploits the fact that values coming from the module
options aren't escaped and thus works in a similar vain to how SQL
injection works.
Another option would be to just set configFile to a file that includes
all the options, including zones. That obviously makes the configuration
way less extensible and more awkward to use with the module system.
To make sure this change does work correctly I added a small test just
for that. The test could use some improvements, but better to have a
test rather than none at all. For a future improvement the test could be
merged with the NSD test, because both use the same zone file format.
This change has been reviewed in #40053 and after not getting any
opposition, I'm hereby adding this to master.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @peti, @edolstra
Closes: #40053
VMs were starving, many of the daemons were unable to complete their
tasks resulting in tests failures.
Turned off verbose output from k8s components as it consumes even more resources, and useful error messages actually drown in debug-clutter
1) Change start-type to ```notify``` when running MariaDB so that we don't have to busy-wait for the
socket to appear.
2) Do not manually create the directory under /run as we can get systemd to do
that for us. This opens up the possibility later for not having to launch as root.
`xsslock` (which was originally packaged in 6cb1d1aaaf)
is a simple screensaver which connects a given screen locker (e.g.
`i3lock`) with `logind`. Whenever `loginctl lock-sessions` is invoked
the locker will be used to lock the screen. This works with its power
management features (e.g. `lid switch`) as well, so the PC can be locked
automatically when the lid is closed.
The module can be used like this:
```
{
services.xserver.enable = true;
programs.xss-lock.enable = true;
programs.xss-lock.lockerCommand = "i3lock";
}
```
`statsd` is a daemon written in `node` to gather statistics over UDP.
The current test ensures that a port is open, but the basic
functionality isn't sufficiently tested.
This patch contains the following changes:
* Simplified port scanning (`waitForOpenPort` rather than `netcat` magic).
* Issue a TCP command to check the health of the `statsd` server.
* Simple script to check if `statsd` receives data over UDP and confirms
the basic functionality of the TCP interface on `8126` for admin
purposes.
In commit 17dd7bcd89 the systemd unit
generator now uses lndir instead of "ln -s", so we need to have lndir
available in the Nix store for the installer tests to be able to build
the units and thus the whole system.
This should fix the installer tests, although I have only tested it with
the "simple" subtest.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @jtojnar, @xeji, @edolstra
The original `nexus` derivation required `/run/sonatype-work/nexus3`
which explicitly depended on the NixOS path structure.
This would break `nexus` for everyone using `nixpkgs` on a non-NixOS
system, additionally the module never created `/run/sonatype-work`, so
the systemd unit created in `services.nexus` fails as well. The issue
wasn't actively known as the `nixos/nexus` test wasn't registered in
Hydra (see #40257).
This patch contains the following changes:
* Adds `tests.nexus` to `release.nix` to run the test on Hydra.
* Makes JVM parameters configurable: by default all JVM options were located
in `result/bin/nexus.vmoptions` which made it quite hard to patch
these parameters. Now it's possible to override all parameters by
running `VM_OPTS_FILE=custom-nexus.vmoptions ./result/bin/nexus run`
(after patching the `nexus` shell script), additionally it's possible
to override these parameters with `services.nexus.vmoptions`.
* Bumped Nexus from 3.5.1 to 3.11.0
* Run the `nexus` test on Hydra with `callTest` in `nixos/release.nix`,
furthermore the test checks if the UI is available on the specified
port.
* Added myself as maintainer for the NixOS test and the package to have
some more people in case of further breakage.
* Added sufficient disk space to the `nexus` test, otherwise the service
fails with the following errors:
```
com.orientechnologies.orient.core.exception.ODatabaseException: Cannot create database 'accesslog'
com.orientechnologies.orient.core.exception.OLowDiskSpaceException: Error occurred while executing
a write operation to database 'accesslog' due to limited free space on the disk (242 MB). The database
is now working in read-only mode. Please close the database (or stop OrientDB), make room on your hard
drive and then reopen the database. The minimal required space is 256 MB. Required space is now set to
256MB (you can change it by setting parameter storage.diskCache.diskFreeSpaceLimit) .
```
/cc @ironpinguin @xeji