Michael Prokop [2014-01-23 15:51 +0100]: > I see, thanks for sharing. When do you schedule those runs? Like > before a package enters the archive or after it has already entered > the archive? Out of any pipeline? (I'm running autopkgtest test runs > as part of the normal binary package builds, also in Jenkins but > fully VCS-only driven.) What happens is roughly as follows: - package gets uploaded to devel-proposed (roughly comparable to Debian unstable) - britney waits until the package gets built on the architectures that we run autopkgtest on (i386 and amd64 ATM, soon to be armhf) - once those binaries become installable (this check doesn't work ATM, but it's intended to) it requests autopkgtest runs for that package and all of its reverse dependencies - Jenkins picks up that request and runs tests for the requested packages - results get aggregated back to the machine that runs britney - once builds are completed on *all* arches, packages stay/become installable (as usual with britney), and all requested autopkgtests succeeded, the package gets propagated to devel (roughly comparable to Debian testing) otherwise, if anything fails there, the package gets held back in -proposed, which can be seen at [1] (search for FAIL to see the cases where autopkgtest holds back a new version) No human user is running devel-proposed, as this is by definition the pocket where stuff is broken. Human users run devel (i. e. the testing equivalent). autopkgtests are run with -proposed enabled, of course, so that you can do fixes/updates/transitions of several packages in lockstep. In Ubuntu we don't use an additional waiting time (like Debian's 10/5/2 days) for the -proposed → devel migration. Martin [1] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
Attachment:
signature.asc
Description: Digital signature