In case autopkgtest triggering is delayed because the required builds aren't
ready yet or the package is not installable, currently there is only the
message that autopktest delays the migration, but no hint why. This commit adds
these hints.
The initial idea was to do this to bootstrap the baseline, but it turns out
that this has the drawback it triggers runs for a package that has a new
autopkgtest where it didn't have it in the version in the target suite. It was
considered harmless (as it would just have a failing reference), but due to
autodep8, package can have a passing result in the target suite while the new
autopkgtest is actually broken. Such a package should not be blocked / getting
a penalty.
The alternative is to make the check here smarter, but as this is only for
bootstrapping, lets do that outside of britney proper.
When determining whether a policy applies to a given item, use the
suite class rather than the suite name.
Signed-off-by: Niels Thykier <niels@thykier.net>
1) the update didn't happen for all but the first
2) we don't want a package that fixes a regression in unstable to influence the
reference for another package until it actually migrates, so this updating
is flawed.
Given that only one value is defined ("reference"), it is a better
option to allow the config to be unset when one does not want to have
adt_baseline set to "reference".
Signed-off-by: Niels Thykier <niels@thykier.net>
Notable omissions are "pending_tests" and "tests_results". This is
omission is due to these (some times) being initialized from the
output of "json.load" (so we cannot assume defaultdict semantics
without manually imported the data into one).
Signed-off-by: Niels Thykier <niels@thykier.net>
The first case is to avoid a creating a list, which is then converted
to a set only to throw away the list again. Here we can just create
the set right away without a list inbetween.
The second case is "if x in [...]:" is better written as "if x in
{...}:" as sets provides faster "__contains__" (assuming you are on a
"recent enough python3", which britney is).
Signed-off-by: Niels Thykier <niels@thykier.net>
Arguable, this is not a problem in the code as the failure case
invokes sys.exit. However, this is more future proof as the sys.exit
may be replaced (or we may later catch another exception that is
"recoverable").
Signed-off-by: Niels Thykier <niels@thykier.net>
- revert most of commit adbe6d5 as checking the version in testing doesn't work
when other packages migrate and cause regressions
- Alternative way of determining if a package is regressing, by comparison to a
reference set. The reference set is to be created by a holy trigger that
doesn't take packages from the base suite, but instead tests in the testing
suite. This reference needs a retry when a package causing regression
migrates nevertheless, e.g. due to hints or to bounty/penalty policy.
This commit rewrites the make-shift "log" methods to use the logging
framework without requiring changes to the callers. This will be done
in a latter commit to keep things reviewable.
Signed-off-by: Niels Thykier <niels@thykier.net>
The other item includes bug numbers so this one is less useful.
Closes: https://bugs.debian.org/886509
Signed-off-by: Niels Thykier <niels@thykier.net>
The PiupartsPolicy does not use the report URL for testing, so we do
not need to store it in memory. Unfortunately, the logic was broken
and the discard did not happen.
Signed-off-by: Niels Thykier <niels@thykier.net>
If a package had:
Build-Depends: foo [i386], uninstallable-pkg
Then the excuses for amd64 would point to "foo [i386]" rather than
"uninstallable-pkg".
Signed-off-by: Niels Thykier <niels@thykier.net>
Add a new "BuildDependsPolicy" that will check the satisfiability of
the build-dependencies listed in the Build-Depends and
Build-Depends-Arch fields. This enables gating of packages based on
missing / broken build-dependencies.
There are some limitations:
* Build-Depends-Indep is ignored for now. Missing or broken packages
listed in Build-Depends-Indep will be continue to be silently
ignored.
* Being a policy check, it does not enforce "self-containedness" as
a package can still migrate before a build-dependency. However,
this can only happen if the build-dependency is ready to migrate
itself. If the build-dependency is not ready (e.g. new RC bugs),
then packages build-depending on it cannot migrate either (unless
the version in testing satisfies there requirements).
Signed-off-by: Niels Thykier <niels@thykier.net>
Add some "no cover" to some unrecoverable exceptions
(e.g. misconfiguration) or base-class methods that are not intended to
be invoked.
Signed-off-by: Niels Thykier <niels@thykier.net>
Niels Thykier
Paul Gevers
Paul Wise
Jonathan Wiltshire