[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: "Debian CI/autopkgtest BoF" at Debconf18

Hi all,

Thanks Ian for chairing the BoF, I think it was useful to have it.

On 02-08-18 11:30, Martin Pitt wrote:
> Simon McVittie [2018-08-02  9:59 +0100]:
>> On Thu, 02 Aug 2018 at 06:49:33 +0100, Ian Jackson wrote:
>>> ## unsatisfiable test-dependencies should not be a test failure
>>> DON'T use apt in your script
>>> Use flaky restriction + it needs a fix in autopkgtest to properly support that
>>>   (as mentioned by Ralf Treinen, it doesn't work yet).
>> Sorry, I don't follow. Do you mean "don't use apt in your script, ever"
> I would also recommend to use apt-get, not literally "apt". The latter is nice
> for interactive command line usage, but too fancy/graphical for logged script
> output, and its CLI is not stable.
> But I suppose you really meant "apt-get" as well here. Why should that be
> flaky? Because of unstable mirrors or something?

Yes, I meant apt-get as well. The problem is that I think often it is to
work around issues. My take home message of the BoF was that people are
encountering issues we aren't aware of. Using apt is often an example of
that. Take gnugp2. I think it does it to add multi-arch. But the test
fails in our migration setup because it doesn't "fix" the pinning that
we have in place to get the right packages installed. As a global
reference I think we should say: package install goes via autopkgtest
except when it is really apt(-get) or something close to it you want to
test. But also, think about network hickups, retries etc. Therefor,
often these things turn out to be flaky. (True, with skippable that can
be fixed, but as a general recommendation I want to say, don't call
apt-get yourself, but file a bug about the use case you want supported.

>> (Some useful test cases can't really avoid using apt, in particular the
>> ones for debootstrap and nss-mdns.)

Sure, exceptions.

> Yeah, that. I also encountered or even wrote tests where it was inevitable to
> do some pre-setup or a particular order or something else which you can't
> express through a declarative Depends:. Or you want to test an apt related
> package :)

But be prepared for breakage. Basically you would need to "copy" some of
the code autopkgtest has to make this "robust". There is currently my MR
29 [1], that is about optionally disabling the apt fallback in
autopkgtest, which I want to start using on ci.d.n once britney can
calculate sets of packages that need to come from unstable. I consider
this fallback a gross hack (I think pitti once acknowledged to me he
considers it a (maybe not gross) hack too). But is shows our setup is
"weird" and calling apt(-get) in that situation is somewhat fragile.


[1] https://salsa.debian.org/ci-team/autopkgtest/merge_requests/29

Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: