RFR: Britney - autopkgtest integration

[Raphael Hertzog]

Hello Paul,

On Sun, 01 Apr 2018, Paul Gevers wrote:
> (including nthykier) to prepare the integration of britney with
> autopkgtest results. We believe the work has reached a state where full
> deployment can be considered. Let me describe how it is designed to work
> and what I request from you.

Huge thanks for this work! I'm looking forward to it and I plan to deploy
it for use by Kali too.

Hence I would like to know a bit more how it all ties together with debci.
I have looked quickly at the code and I saw references to the AMQP
messaging queue, to a REST API on the debci side, and also to swift.
Can you quickly describe the workflow between all those components and
britney?

How does debci implement the "test package foo/unstable in testing"?
I'm asking the question because I wonder how it copes with packages
having gained a dependency on a version of another package that has not
yet migrated either.

Your documentation has this somewhat related paragraph:
+There are cases where it is required to have multiple packages migrate together
+to have the test cases pass, e.g. when there was a bug in a regressing test
+case of a reverse dependency and that got fixed. In that case the test cases
+need to be triggered with both packages from the source suite in the target
+suite (again, how this is done depends on the setup).

Can you let us know how this will be done for the official Debian setup?

Another thing that I wonder is whether the autopkgtest policy check will
be cleared for a given version as soon as it has run or whether it might
have to run multiple times if some of its dependencies migrate in testing
before it migrated? (i.e. the test environment evolved during the aging
period)

> Shadow britney
> ==============
> I have started a shadow cron job of britney on respighi to see how
> everything is behaving. I'll start filing bugs on regressions such that
> the current code already has value, but the drawback of a shadow run is
> that the information is very poorly discover-able for interested
> parties. Also, I expect people to start noticing that ci.d.n is
> generating more results, I think it would be great if we can explain
> this in one go after britney has the autopkgtest code deployed.

Looking for such results on ci.debian.net, I found this:
https://ci.debian.net/packages/g/gnome-photos/testing/amd64/

Which gives some hints to my former question. It looks like
autopkgtest is receiving some supplementary option like this
one:
    --add-apt-release=unstable --pin-packages=unstable=src:gnome-photos
(seen in https://ci.debian.net/data/autopkgtest/testing/amd64/g/gnome-photos/98854/log.gz)

For persons interested in seeing excuses data generated by
this shadow britney, it seems to be in
respighi.debian.org:/home/elbrus/data-b2/output/

BTW, the excuses.yaml does contain weird lines with "null":

(in appstream entry)
    autopkgtest:
      appstream:
        amd64:
        - RUNNING
        - https://ci.debian.net/status/pending
        - https://ci.debian.net/packages/a/appstream/testing/amd64
        - null
        - null

Also I see the age-requirement bumped to 15 but it would be nice to
also have somewhere the details of why we got 15 instead of the usual
value.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/