On Tue, Jun 12, 2018 at 02:34:57PM +0200, Hans-Christoph Steiner wrote: > > I agree that there can't be a Restriction for every config under the > sun. I'm thinking more like Ian, where there can be some useful chunks > with a finer grain than "needs isolation". Allowing a test definition to cause any side effect to the host that is running the test opens the doors to a security nightmare. > I think that autopkgtest will never work well for a lot of packages with > such a inflexible system for specifying requirements. What if > autopkgtest took a more "user generated" approach like gitlab CI > runners? That means that anyone can create tags/labels for runners, and > jobs can specify any label that they require. Then it is up to the > people implementing the jobs/runners to make sure that they work. > > We can learn a lot from the various CI services out there (GitLab, > Travis, Circle, etc). They are all based on containers, and they > generally put few restrictions on what can be done in the containers. > Containers are really well suited for CI builds since they provide an > easy system for building up throwaway environments. note that no configuration option in gitlab ci, travis etc allows you to make changes to the *host* where the tests run. you can specify several aspects of the *testbed* (container) where the tests run, and autopkgtest already allows you to do whatever you need inside the testbeds. the problem here is that by definition, some types of testbed don't allow you to test some packages. in this specific case, there is just no way you can reliably test a feature that depends on a kernel feature in a container.
Attachment:
signature.asc
Description: PGP signature