On Mon, Jan 16, 2023 at 10:47:27AM +0700, Arnaud Rebillout wrote: > Dear CI team, > > Quoting debci/docs/MAINTAINERS.md first: > > The test suite for a source package will be executed: > * when any package in the dependency chain of its binary packages changes; > * when the package itself changes; > * when 1 month is passed since the test suite was run for the last time. This used to be true when debci itself was in charge of scheduling tests. This is no longer the case, as all tests are now scheduled by britney, the release team testing migration software. Unfortunately, this section of the documentation is outdated. > In Kali Linux, I have a package named kali-tweaks, it provides an UI to > configure different components of the system. For example, it allows > configuring the SSH client. It does NOT depend on openssh-client, however I > would like to trigger autopkgtest when the package openssh-client changes. > How can I achieve that? > > What I'm after is something like: > > * a field "DebCI-Trigger:" or similar, that I could add to kali-tweaks > debian/control, and where I could list extra-packages that should trigger > autopkgtests > * alternatively, a way to run autopkgtests more often (say every day) for > the package kali-tweaks > * any other idea? On Mon, Jan 16, 2023 at 10:16:09AM +0000, Simon McVittie wrote: > On Mon, 16 Jan 2023 at 10:47:27 +0700, Arnaud Rebillout wrote: > > In Kali Linux, I have a package named kali-tweaks, it provides an UI to > > configure different components of the system. For example, it allows > > configuring the SSH client. It does NOT depend on openssh-client, however I > > would like to trigger autopkgtest when the package openssh-client changes. > > How can I achieve that? > > If one of the autopkgtest stanzas in debian/control has > Depends: openssh-client, then that's treated as a dependency for debci's > purposes. I assume you will need to install openssh-client in order > to test this reconfiguration, even if it isn't a dependency of > kali-tweaks.deb? > > The implementation is that dpkg-source reads the test dependencies out of > debian/tests/control and copies them into the Testsuite-Triggers field, > which ends up in the Sources index. For example, take a look at src:dbus, > which does not (build-)depend on apparmor, gnome-desktop-testing or xvfb, > but does list them in its Testsuite-Triggers as a result of them being > mentioned in debian/tests/control; so the dbus test suite will be re-run > whenever apparmor changes. > > Or, if the dependency is indirect or you are doing something unexpected, > you can add a stanza like this to debian/tests/control, as documented for > the "hint-testsuite-triggers" restriction in > https://salsa.debian.org/ci-team/autopkgtest/blob/master/doc/README.package-tests.rst: > > Tests: hint-testsuite-triggers > Depends: hello, init, openssh-client > Restrictions: hint-testsuite-triggers > > and that will get your test re-run every time hello, init or openssh-client > is changed, but without actually installing those packages. > > The name of the test script hint-testsuite-triggers is arbitrary, and > I don't think it actually needs to exist. It will never be run, because > of the Restriction. However, its dependencies will still be copied into > the Testsuite-Triggers as though it *was* going to be run. For example, > look at src:apparmor, which has a hint-testsuite-triggers stanza to get > its tests re-run every time there's a new kernel available. That is all correct, but for the Debian infrastructure. I don't know how the Kali infrastructure does it. The debci bits that used to to do this have been removed 1 year ago, but if they are still using an old version, that did not take the Testsuite-Triggers field into account.
Attachment:
signature.asc
Description: PGP signature