On 2020-04-21 04:00, Mark Olesen wrote:
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, sincethose 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 thefirst binary package being built as well as the tutorials. So a syntaxlike this is what I want: Depends: @, @-tutorialsSince 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).DrewOn 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 invokeautopkgtest -B -- null