On 15/08/18 18:45, Simon McVittie wrote:
On Mon, 30 Jul 2018 at 07:57:35 +0100, Rebecca N. Palmer wrote:
#equivalent to Restrictions: trivial
Restrictions: skippable
Test-Command: do_the_test && exit 77
and later
- else:
+ elif 'trivial' not in t.restrictions:
any_passed = True
This is not precisely equivalent, although I think the second
implementation is more correct. Consider two packages:
* pango1.0 has a trivial test (build) and a non-trivial test (installed-tests)
* libinput has only a trivial test (build)
In the first implementation, successful testing of pango1.0 would exit 2,
because the build test was "skipped". In the second, successful testing
of pango1.0 would exit 0. I feel as though the second is more correct,
but I'm having a hard time justifying why: perhaps I can argue that we
ran every test that is available, so there is nothing we could have done
better in a more advanced testbed, and therefore exit status 2 would
be inappropriate?
Similarly, in the first implementation, both packages' "build" tests
would be diagnosed as "build SKIP", while in the second, they would be
diagnosed as "build PASS". I think the second is correct (I've actually
implemented it as "build PASS (trivial)", but I could be persuaded to
drop that).
I agree: this is part of why having trivial be a real Restriction is
more user-friendly than faking it with skippable.
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/34
Looks OK, though I haven't actually tried it.
