similar to: [PATCH v7 00/10] tests: Introduce test harness for running tests.

This converts more of the tests (basically everything under tests/) to use the test harness, revealing some problems which have subsequently been fixed. Rich.

For v6: This is mainly just a rebase, but I have also added tests in the ocaml/ language bindings directory, and for all the OCaml-written virt tools. Rich.

I should probably start by saying this patch series isn't ready for review yet. This patch series adds a test harness to libguestfs. It allows us to run the tests outside the ordinary 'make check' path in the build tree. In particular, you can use this to run tests when libguestfs has been installed. 'make check' and the other 'make check-*' rules still work. The

Since v4: - More tests have been converted. - Testing local guests fixed. - Drop no-exec-stack test.

This is a more complete patch to add the test harness. The only parts missing now are the language bindings (except OCaml). The language bindings need a bit more thought. At the moment most language binding tests are done through some sort of shell script like perl/run-perl-tests which either runs each test itself or uses some language-specific machinary to run each test. The problem with that

Since v2: - Add perl tests. - Reworked and fixed the tests for virt-builder. - Some further minor bug fixes.

Since v3: - A large number of fixes, especially for running the tests on installed libguestfs. - Fixed EXTRA_DIST rules throughout. - Extra patch 17/17 which is a tidy-up of the generated XML listing guests. Rich.

This has got to the stage where it actually works, both for running the tests in-tree and installed. The 'test-harness' script has become rather over-complex in the process however. Rich.

On Sunday 05 October 2014 14:08:35 Richard W.M. Jones wrote: > +# Install the test harness. > +localtestsdir = $(alltestsdir) > +localtests_SCRIPTS = ../test-harness Shouldn't it rather go to libexec? > +../test-harness: > + rm -f $@ $@-t > + echo 'echo Warning: Install OCaml compiler in order to rebuild the test-harness.' > $@-t > + chmod +x

These are my thoughts on adding a test harness to run tests instead of using automake. The aim of this exercise is to allow us to run the full test suite on an installed copy of libguestfs. Another aim is to allow us to work around all the limitations and problems of automake. The first patch makes an observation that since the ./run script sets up $PATH to contain all the directories

- Add $(srcdir), $(builddir) to Makefiles where required - Post-process ocamldep output - generate ocaml/.depends --- builder/Makefile.am | 7 ++++--- common/mlgettext/Makefile.am | 2 +- common/mlpcre/Makefile.am | 2 +- common/mlprogress/Makefile.am | 2 +- common/mlstdutils/Makefile.am | 2 +- common/mltools/Makefile.am | 2 +- common/mlutils/Makefile.am | 2 +-

We would like to have a more flexible way to run tests, including running them on an installed copy of libguestfs, running them in parallel, and being able to express dependencies and ordering between tests and data files properly. Therefore introduce a test harness (test-harness) program which can run tests either from the locally built copy, or from an installed copy of the tests (in

We would like to have a more flexible way to run tests, including running them on an installed copy of libguestfs, running them in parallel, and being able to express dependencies and ordering between tests and data files properly. Therefore introduce a test harness (test-harness) program which can run tests either from the locally built copy, or from an installed copy of the tests (in

We would like to have a more flexible way to run tests, including running them on an installed copy of libguestfs, running them in parallel, and being able to express dependencies and ordering between tests and data files properly. Therefore introduce a test harness (test-harness) program which can run tests either from the locally built copy, or from an installed copy of the tests (in

Just like the similar series that already went in for libguestfs [1], do similar fixes also for virt-v2v, with additional fixes for the builddir!=srcdir case. This will also need the fix to subdir-rules.mk. [1] https://www.redhat.com/archives/libguestfs/2019-December/msg00062.html Pino Toscano (7): Update common to latest build: stop shipping files generated by configure build: use the

Previously posted here: https://www.redhat.com/archives/libguestfs/2015-June/msg00266.html Rich.

Currently we are unable to properly run guestfsd (the daemon) under valgrind. Attempts to run valgrind inside the appliance have not been successful (see patch 1/7). However we desperately need better valgrind coverage of the daemon, particularly because it is doing a lot of complex parsing of program output. This has been a problem for a long time. A better way to attack this problem is to

*** BLURB HERE? *** Pino Toscano (6): build: stop shipping files generated by configure docs: fix out-of-source documentation build generator: do not generate mlv2v files when not needed perl: fix path to Build.PL rust: fix path to lib.rs rust: fix list of generator-built files daemon/Makefile.am | 8 ++++++-- docs/Makefile.am | 4 ++-- generator/main.ml | 11

There's a lot of common code in the tests, eg: if [ "$(guestfish get-backend)" = "uml" ]; then echo "$0: test skipped because UML backend does not support network" exit 77 fi These commits (work in progress) create a common set of test functions for skipping tests etc. Rich.

In v2: - Kernel command line parsing now moved to the appliance. - In the captive daemon test, the daemon cleanly shuts down on exit. - Add another btrfs test. Rich.