[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: using package tests



Am Freitag, den 17.04.2020, 19:59 +0200 schrieb Mark Olesen:
> I started looking at package tests and some of tutorial information (eg,
> https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html 
> and https://ci.debian.net/doc/file.TUTORIAL.html).
> 
> As usual, there is lots of information, but not really sure what is the 
> most applicable.

I agree, it is poorly documented (and AFAIK even the current documentation is
not up-to-date). BTW: You can look for more examples on codesearch.debian.net.

>  These tests, for example,
> 
> https://salsa.debian.org/science-team/openfoam/-/tree/master/debian%2Ftests
> 
> 
> Which particular invocation of autopkgtest would be used for these?

For each test autopkgtest prepares the testbed by installing the built openfoam
package (Depends field). The tests listed in the Tests field are each scripts.
I just checked one of them (boundaryFoam). It copies a tutorial from the source
tree into a temporary directory, exports WM_PROJECT_DIR and then runs two
commands shipped with the openfoam package.

Or what do you mean by "incocation"?

> It looks like they are testing on the installed package, or is there a 
> chroot hidden somewhere and they actually run with the built 
> debian/prefix/package.. hierarchy?

autopkgtest runs the tests inside a chroot, container or machine (check out the
Restrictions field). It usually tests the installed package, but from the
source tree. However there is a restriction called 'build-needed' which I guess
is for cases where you rely on something inside the source. Depending on the
tests run it is possible that tests rely on files inside the source and not the
installed package (that's why e.g. the defaukt ruby tests move the lib/
dorectofry in the source away during the tests).

https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html 

> Since the included tests are very similar, I wanted to wrap them in a 
> simple "AutoTest" utility in the upstream. However, I'm not sure which 
> environment or other conditions are passed in there.

If you do this make sure to not rely on paths inside the source.

If you know what you want to try to achieve, please post your idea. IMHO it
might be simpler to get something like this to work then to explain every
possible use case of autopkgtest :)

Regards, Daniel

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: