Redesigning the autopkgtest controller/workers CI system for Ubuntu and Debian

[Martin Pitt]

Jean-Baptiste Lallement [2014-03-13 17:51 +0100]:
> >This needs some refinement as we can have many runs with the same
> >package version, and for failed runs we won't even have a package
> >version. So perhaps
> >
> >  trusty/armhf/foopkg/<timestamp>/
> >
> I need to think more about it but I can imagine situations where it
> might not be enough especially when several packages trigger a test
> for the same package.

Yes, exactly. What'd we ideally need is some kind of atomic global
counter in swift, or locking. Perhaps Andy or Evan have some idea
about that how that's possible (I didn't find something like that).

> For example: A (has a testsuite) depends on B and C
> B and C are uploaded to unstable in 2 different publication cycles.
> Britney will first request a test for A+B then A+C (and implicitly B
> since it is in unstable too)
> - What will happen if results for A+C arrive before A+B?

That should suffice then, as long as B's version in that run is
what britney wants to have covered?

> - What will happen if A+C fails quickly with an error (ie no version
> for A or C), results are processed by britney which will think they
> also match A+B (since it has no version to use as reference) then
> results for A+B are sent back and B will be blocked even if its
> tests passed.

The A+C run will have result "ERROR", and as you say won't have any
package versions, so britney should disregard it. A+B will then arrive
later, but as britney is still waiting for an A+C run either it or the
admin needs to retrigger the test after such an ERROR.

But indeed this isn't ideal. Of course britney could just look at all
the results (starting from the most recent one), and walk backwards
until it sees what it wants, but that sounds inefficient.

Perhaps to mitigate that only PASS or FAIL results would update
/latest, but not ERROR results? I think that ought to work.

But yes, this needs some consideration.

> With this convention there is also a very (very) small chance of
> collision if results for the same package are published
> simultaneously (the speed at which the nodes will run the tests is
> not guaranteed)

Right. That goes back to above "need file locking or atomic counters"
question.

> You'll need the version of the package that have been tested and the
> version of the dependencies during that test. Britney must match the
> version of the candidate and the version of the package that have
> been tested and depends on this candidate.

Ack. This needs to be done in autopkgtest itself, but seems rather
straightforward to add. debci does something similar (e. g.
http://ci.debian.net/data/unstable-amd64/packages/p/python-leveldb/2014-03-12.log)
I guess by parsing the output log or inspecting the state of the
schroot. But adt-run knows this, so let's put that into the
--output-dir as "version" and "dependencies"?

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/autopkgtest-devel/attachments/20140313/dcb9ad79/attachment.sig>