Regression introduced by 032f0ffdd03fa4d836825bcbb7e89f1abcf7e57f.
The change doesn't look obvious at the first sight why it may cause
problems with lib.makePerlPath, but it introduces a Perl package called
"lib".
And using "with perlPackages;" uses the Perl library "lib" instead of
the lib attribute set from pkgs.
So let's use pkgs.lib.makePerlPath directly in hope that there won't be
a Perl package anytime soon which is called "pkgs".
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Only include the English language for the VM tests, because we most
likely won't need other languages. At least for now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
By default this is now enabled, and it has to be explicitely enabled
using "enableOCR = true". If it is set to false, any usage of
getScreenText or waitForText will fail with an error suggesting to pass
enableOCR.
This should get rid of the rather large dependency on tesseract which
we don't need for most tests.
Note, that I'm using system("type -P") here to check whether tesseract
is in PATH. I know it's a bashism but we already have other bashisms
within the test scripts and we also run it with bash, so IMHO it's not a
problem here.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Basically, this creates a screenshot and throws tesseract at it to
recognize the characters from the screenshot. In order to produce a
result that is well enough, we're using lanczos scaling and scale the
image up to 400% of its original size.
This provides the base functionality for a new Machine method which will
be called waitForText. I originally had that idea long ago when writing
the VM tests for VirtualBox and Chromium, but thought it would be
disproportionate to the case.
The downside however is that VM tests now depend on tesseract, but given
the average runtime of our tests it really shouldn't have a too big
impact and it's only a runtime dependency after all.
Another issue is that the OCR process takes quite some time to finish,
but IMHO it's better (as in more deterministic) than to rely on sleep().
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The current way test reports get jquery,
src="//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"
only works when getting reports over http:// or https://, not file://.
Change it so that it works for all protocols by using a local copy of
jquery.
This fixes the issue where locally created and browsed test reports
cannot be navigated properly; clicking the '+' symbol to expand
sub-sections doesn't work.
Now you can just say:
$ nix-build '<nixos/tests/login.nix>'
You can still get the driver script for interactive testing:
$ nix-build '<nixos/tests/login.nix>' -A driver
$ ./result/bin/nixos-test-driver
You can now run a test in the nixos/tests directory directly using
nix-build, e.g.
$ nix-build '<nixos/tests/login.nix>' -A test
This gets rid of having to add the test to nixos/tests/default.nix.
(Of course, you still need to add it to nixos/release.nix if you want
Hydra to run the test.)
It requires a writable /nix/store to store the build result. Also,
wait until we've reached multi-user.target before doing the build, and
do a sync at the end to ensure all data to $out is properly written.
http://hydra.nixos.org/build/6496716
