Redesigning the autopkgtest controller/workers CI system for Ubuntu and Debian
Le 13/03/2014 17:16, Martin Pitt a ?crit :
> Martin Pitt [2014-03-13 11:51 +0100]:
>> * A dynamic set of worker nodes which do the test execution. They
>> read from the autopkgtest_* queue which they are capable of
>> processing, run the test, and store the results in swift. This
>> should have a predictable directory hierarchy, like
>> /autopkgtest/trusty/armhf/foopkg/1.2.3-4/, so that we can avoid
>> having to send back a result pointer.
> 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
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.
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?
- 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.
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)
> with the log files and a "package-version" file, plus a
> file which has the most recent timestamp in it? (I think you can also
> fake symlinks in swift, which would make this even more elegant) Then
> britney would read the latter, then the former, and check if
> package-version is what it wants to test.
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.