nixpkgs/tests/subversion.nix

139 lines
4.9 KiB
Nix
Raw Normal View History

{ nixos ? ./..
, nixpkgs ? ../../nixpkgs
, services ? ../../services
, system ? builtins.currentSystem
}:
2009-09-02 02:42:43 -06:00
with import ../lib/build-vms.nix { inherit nixos nixpkgs services system; };
* Stuff for automatic and manual testing of NixOS VMs. lib/build-vms.nix contains a function `buildVirtualNetwork' that takes a specification of a network of machines (as an attribute set of NixOS machine configurations) and builds a script that starts each configuration in a separate QEMU/KVM VM and connects them together in a virtual network. This script can be run manually to test the VMs interactively. There is also a function `runTests' that starts and runs the virtual network in a derivation, and then executes a test specification that tells the VMs to do certain things (i.e., letting one VM send an HTTP request to a webserver on another VM). The tests are written in Perl (for now). tests/subversion.nix shows a simple example, namely a network of two machines: a webserver that runs the Subversion subservice, and a client. Apache, Subversion and a few other packages are built with coverage analysis instrumentation. For instance, $ nix-build tests/subversion.nix -A vms $ ./result/bin/run-vms starts two QEMU/KVM instances. When they have finished booting, the webserver can be accessed from the host through http://localhost:8081/. It also has a small test suite: $ nix-build tests/subversion.nix -A report This runs the VMs in a derivation, runs the tests, and then produces a distributed code coverage analysis report (i.e. it shows the combined coverage on both machines). The Perl test driver program is in lib/test-driver. It executes commands on the guest machines by connecting to a root shell running on port 514 (provided by modules/testing/test-instrumentation.nix). The VMs are connected together in a virtual network using QEMU's multicast feature. This isn't very secure. At the very least, other processes on the same machine can listen to or send packets on the virtual network. On the plus side, we don't need to be root to set up a multicast virtual network, so we can do it from a derivation. Maybe we can use VDE instead. (Moved from the vario repository.) svn path=/nixos/trunk/; revision=16899
2009-08-31 08:25:12 -06:00
let
# Build some packages with coverage instrumentation.
overrides = pkgs:
let
do = pkg: pkg.override (args: {
stdenv = pkgs.addCoverageInstrumentation args.stdenv;
});
in
rec {
apr = do pkgs.apr;
aprutil = do pkgs.aprutil;
apacheHttpd = do pkgs.apacheHttpd;
mod_python = do pkgs.mod_python;
subversion = do pkgs.subversion;
# To build the kernel with coverage instrumentation, we need a
# special patch to make coverage data available under /proc.
kernel_2_6_28 = pkgs.kernel_2_6_28.override (orig: {
2009-09-02 00:45:50 -06:00
stdenv = pkgs.cleanupBuildTree (pkgs.keepBuildTree orig.stdenv);
kernelPatches = orig.kernelPatches ++ pkgs.lib.singleton
{ name = "gcov";
patch = pkgs.fetchurl {
url = http://buildfarm.st.ewi.tudelft.nl/~eelco/dist/linux-2.6.28-gcov.patch;
sha256 = "0ck9misa3pgh3vzyb7714ibf7ix7piyg5dvfa9r42v15scjqiyny";
};
extraConfig =
''
CONFIG_GCOV_PROFILE=y
CONFIG_GCOV_ALL=y
CONFIG_GCOV_PROC=m
CONFIG_GCOV_HAMMER=n
'';
};
});
* Stuff for automatic and manual testing of NixOS VMs. lib/build-vms.nix contains a function `buildVirtualNetwork' that takes a specification of a network of machines (as an attribute set of NixOS machine configurations) and builds a script that starts each configuration in a separate QEMU/KVM VM and connects them together in a virtual network. This script can be run manually to test the VMs interactively. There is also a function `runTests' that starts and runs the virtual network in a derivation, and then executes a test specification that tells the VMs to do certain things (i.e., letting one VM send an HTTP request to a webserver on another VM). The tests are written in Perl (for now). tests/subversion.nix shows a simple example, namely a network of two machines: a webserver that runs the Subversion subservice, and a client. Apache, Subversion and a few other packages are built with coverage analysis instrumentation. For instance, $ nix-build tests/subversion.nix -A vms $ ./result/bin/run-vms starts two QEMU/KVM instances. When they have finished booting, the webserver can be accessed from the host through http://localhost:8081/. It also has a small test suite: $ nix-build tests/subversion.nix -A report This runs the VMs in a derivation, runs the tests, and then produces a distributed code coverage analysis report (i.e. it shows the combined coverage on both machines). The Perl test driver program is in lib/test-driver. It executes commands on the guest machines by connecting to a root shell running on port 514 (provided by modules/testing/test-instrumentation.nix). The VMs are connected together in a virtual network using QEMU's multicast feature. This isn't very secure. At the very least, other processes on the same machine can listen to or send packets on the virtual network. On the plus side, we don't need to be root to set up a multicast virtual network, so we can do it from a derivation. Maybe we can use VDE instead. (Moved from the vario repository.) svn path=/nixos/trunk/; revision=16899
2009-08-31 08:25:12 -06:00
};
in
rec {
nodes =
{ webserver =
{ config, pkgs, ... }:
{
services.httpd.enable = true;
services.httpd.adminAddr = "e.dolstra@tudelft.nl";
services.httpd.extraSubservices =
[ { serviceType = "subversion";
urlPrefix = "";
dataDir = "/data/subversion";
userCreationDomain = "192.168.0.0/16";
* Stuff for automatic and manual testing of NixOS VMs. lib/build-vms.nix contains a function `buildVirtualNetwork' that takes a specification of a network of machines (as an attribute set of NixOS machine configurations) and builds a script that starts each configuration in a separate QEMU/KVM VM and connects them together in a virtual network. This script can be run manually to test the VMs interactively. There is also a function `runTests' that starts and runs the virtual network in a derivation, and then executes a test specification that tells the VMs to do certain things (i.e., letting one VM send an HTTP request to a webserver on another VM). The tests are written in Perl (for now). tests/subversion.nix shows a simple example, namely a network of two machines: a webserver that runs the Subversion subservice, and a client. Apache, Subversion and a few other packages are built with coverage analysis instrumentation. For instance, $ nix-build tests/subversion.nix -A vms $ ./result/bin/run-vms starts two QEMU/KVM instances. When they have finished booting, the webserver can be accessed from the host through http://localhost:8081/. It also has a small test suite: $ nix-build tests/subversion.nix -A report This runs the VMs in a derivation, runs the tests, and then produces a distributed code coverage analysis report (i.e. it shows the combined coverage on both machines). The Perl test driver program is in lib/test-driver. It executes commands on the guest machines by connecting to a root shell running on port 514 (provided by modules/testing/test-instrumentation.nix). The VMs are connected together in a virtual network using QEMU's multicast feature. This isn't very secure. At the very least, other processes on the same machine can listen to or send packets on the virtual network. On the plus side, we don't need to be root to set up a multicast virtual network, so we can do it from a derivation. Maybe we can use VDE instead. (Moved from the vario repository.) svn path=/nixos/trunk/; revision=16899
2009-08-31 08:25:12 -06:00
}
];
nixpkgs.config.packageOverrides = overrides;
};
client =
{ config, pkgs, ... }:
{
environment.systemPackages = [ pkgs.subversion ];
nixpkgs.config.packageOverrides = overrides;
};
};
vms = buildVirtualNetwork { inherit nodes; };
test = runTests vms
''
startAll;
$webserver->waitForOpenPort(80);
my $out = $client->mustSucceed("svn --version");
print STDERR "GOT: $out";
my $out = $client->mustSucceed("curl --fail http://webserver/");
print STDERR "GOT: $out";
# Create a new user through the web interface.
$client->mustSucceed("curl --fail -F username=alice -F fullname='Alice Lastname' -F address=alice\@example.org -F password=foobar -F password_again=foobar http://webserver/repoman/adduser");
# Let Alice create a new repository.
$client->mustSucceed("curl --fail -u alice:foobar --form repo=xyzzy --form description=Xyzzy http://webserver/repoman/create");
$client->mustSucceed("curl --fail http://webserver/") =~ /alice/ or die;
# Let Alice do a checkout.
my $svnFlags = "--non-interactive --username alice --password foobar";
$client->mustSucceed("svn co $svnFlags http://webserver/repos/xyzzy wc");
$client->mustSucceed("echo hello > wc/world");
$client->mustSucceed("svn add wc/world");
$client->mustSucceed("svn ci $svnFlags -m 'Added world.' wc/world");
# Create a new user on the server through the create-user.pl script.
$webserver->execute("svn-server-create-user.pl bob bob\@example.org Bob");
$webserver->mustSucceed("svn-server-resetpw.pl bob fnord");
$client->mustSucceed("curl --fail http://webserver/") =~ /bob/ or die;
# Bob should not have access to the repo.
my $svnFlagsBob = "--non-interactive --username bob --password fnord";
$client->mustFail("svn co $svnFlagsBob http://webserver/repos/xyzzy wc2");
# Bob should not be able change the ACLs of the repo.
# !!! Repoman should really return a 403 here.
$client->execute("curl --fail -u bob:fnord -F description=Xyzzy -F readers=alice,bob -F writers=alice -F watchers= -F tardirs= http://webserver/repoman/update/xyzzy")
=~ /not authorised/ or die;
# Give Bob access.
$client->mustSucceed("curl --fail -u alice:foobar -F description=Xyzzy -F readers=alice,bob -F writers=alice -F watchers= -F tardirs= http://webserver/repoman/update/xyzzy");
# So now his checkout should succeed.
$client->mustSucceed("svn co $svnFlagsBob http://webserver/repos/xyzzy wc2");
# Test ViewVC and WebSVN
$client->mustSucceed("curl --fail -u alice:foobar http://webserver/viewvc/xyzzy");
$client->mustSucceed("curl --fail -u alice:foobar http://webserver/websvn/xyzzy");
$client->mustSucceed("curl --fail -u alice:foobar http://webserver/repos-xml/xyzzy");
# Stop Apache to gather all the coverage data.
$webserver->stopJob("httpd");
$webserver->execute("sleep 10"); # !!!
* Stuff for automatic and manual testing of NixOS VMs. lib/build-vms.nix contains a function `buildVirtualNetwork' that takes a specification of a network of machines (as an attribute set of NixOS machine configurations) and builds a script that starts each configuration in a separate QEMU/KVM VM and connects them together in a virtual network. This script can be run manually to test the VMs interactively. There is also a function `runTests' that starts and runs the virtual network in a derivation, and then executes a test specification that tells the VMs to do certain things (i.e., letting one VM send an HTTP request to a webserver on another VM). The tests are written in Perl (for now). tests/subversion.nix shows a simple example, namely a network of two machines: a webserver that runs the Subversion subservice, and a client. Apache, Subversion and a few other packages are built with coverage analysis instrumentation. For instance, $ nix-build tests/subversion.nix -A vms $ ./result/bin/run-vms starts two QEMU/KVM instances. When they have finished booting, the webserver can be accessed from the host through http://localhost:8081/. It also has a small test suite: $ nix-build tests/subversion.nix -A report This runs the VMs in a derivation, runs the tests, and then produces a distributed code coverage analysis report (i.e. it shows the combined coverage on both machines). The Perl test driver program is in lib/test-driver. It executes commands on the guest machines by connecting to a root shell running on port 514 (provided by modules/testing/test-instrumentation.nix). The VMs are connected together in a virtual network using QEMU's multicast feature. This isn't very secure. At the very least, other processes on the same machine can listen to or send packets on the virtual network. On the plus side, we don't need to be root to set up a multicast virtual network, so we can do it from a derivation. Maybe we can use VDE instead. (Moved from the vario repository.) svn path=/nixos/trunk/; revision=16899
2009-08-31 08:25:12 -06:00
'';
report = makeReport test;
}