Hi Stef,
On 02/24/2016 04:52 PM, Stef Walter wrote:
The first thing to note is that you're running the Cockpit unit
tests.
These barely interact with systemd.
The integration tests are where the actual testing of cockpit features,
such as the systemd interaction happens.
Running the integration tests are documented here:
https://github.com/cockpit-project/cockpit/blob/master/test/README
To try this out, install the stuff documented at the top of the file.
And then you would do something like this. Run as non-root:
$ cd test
$ sudo ./vm-prep # only necessary the first time
$ ./check-verify # runs the entire test suite
But since you want a custom systemd, and not the entire test suite, you
would probably end up moving towards something like this:
$ TEST_OS=fedora-23
$ ./vm-reset
$ ./vm-download $TEST_OS
$ ./vm-install --quick
$ ./vm-customize -i systemd*.rpm # Or similar source of binaries
$ ./verify/check-system-info # Just one of the tests
You'll note that this is downloading an image (or in the former case) a
few images. Jan Scotka has been running this these tests with custom
images ... certainly possible. Update the link it the test/images directory.
Hmm, but the machines I'm running this one are more or less stateless,
and the scripts literally download gigabytes of images, which also takes
a long time. This would need more thinking if we would want to use that
as systemd test.
Anyway ... you'll find that running these tests is a bit more
complex
and involved. But this is where the real continuous integration stuff
happens.
Could you elaborate on why it has to be that complex? I would have
thought about installing Cockpit onto the test machine and then run some
scripts that remote-control the local web interface via tools such as
Cucumber or RTest. Wouldn't something like that suffice and make the
test setup a whole lot easier to use?
Thanks,
Daniel