Looks to be successful - thanks Drew.
Now generating the tests as part of the configuration process. At that
point I know what the location of the target executable/wrapper will be
and can use that to repopulate the test/control with a list of
"Test-Command" based on an input list of test tutorials.
Modified the target wrapper to include a '-test-tutorial' flag to handle
the tests via the installed backend.
Cheers,
/mark
On 2020-04-20 05:20, Drew Parsons wrote:
On 2020-04-20 05:43, Mark Olesen wrote:
Hi Drew,
That is actually fairly easy!
When running the tests, is there a standard way to obtain information
about what is being tested, or to pass in such information?
To explain, suppose that I define a simple runner script called
'AutoTest' that would be part of the "-tutorials" subpackage, since
those are the best ones for testing if the installation is successful.
This means that in my source tree I would have something like this,
/some/build/path/debian/tests/control
/some/build/path/tutorials/AutoTest
but also
/installed/path/tutorials/AutoTest
Do I hard-code the /installed/path/tutorials into the tests/control ?
or should these be the ones local to the build directory (ie,
/some/build/path/tutorials/AutoTest) ?
I checked the env, but the only seeming relevant entry was
AUTOPKGTEST_ARTIFACTS, which seems to be an empty directory.
Superficially it runs from the top level source dir. Not the build dir,
never the build dir. But "build" in your path here is a parent dir I
think, so your toplevel is /some/build/path/. Then you can use relative
paths from there to reference the files in the source tree.
But under the hood, the source dir actually gets copied to a tmp dir (so
any files generated by tests will not end up in your original source dir).
You get a clean tmp dir $AUTOPKGTEST_TMP that you can manipulate in your
debian/tests scripts.
Since the point of the exercise is to check that the installed package
works, not the source that it was made from as such, it's not a bad idea
to use installed files rather than files in the source tree. So your
debian/tests script can run your installed
/installed/path/tutorials/AutoTest, or copy it to $AUTOPKGTEST_TMP and
then run it.
When specifying the tests/control, I need them to depend both on the
first binary package being built as well as the tutorials. So a syntax
like this is what I want:
Depends: @, @-tutorials
Since debci uses a minimal clean chroot, so all needed packages will
need to be specified. The @ is just short hand for lazy people (useful
if a large collection of packages needs to be specified).
Drew
On 2020-04-18 04:43, Drew Parsons wrote:
debci tests are run in a chroot.
But for testing locally (i.e. simply running the tests), you can invoke
autopkgtest -B -- null
--
Dr Mark OLESEN
Principal Engineer, ESI-OpenCFD
Engineering System International GmbH | Einsteinring 24 | 85609 Munich
Mob. +49 171 9710 149
www.openfoam.com | www.esi-group.com | [email protected]
