Use @patch decorator instead of ExitStack context manager. This is more
consistent with the rest of the testsuite we have in britney.
Use some more idiomatic assertions, e.g.
unittest.mock.assert_not_called().
It works like this. We wait until all tests have finished running. and
then grab their results. If there are any regressions, we mail each bug
with a link to pending-sru.html. There's a state file which records the
mails we've sent out, so that we don't mail the same bug multiple times.
The apt version comparison sorts 'blacklisted' greater than most version
numbers, which means that we accidentally apply force hints for version
'blacklisted' to all uploads. Since this is the only case of a hacked
version number, let's special case it so that 'blacklisted' hints only
match packages with 'blacklisted' version.
We were just seeing an interesting crash in britney. It was trying to
look up the gpg_keys of ~python-modules-team, which is a suspended
account - in LP API terms that's a HTTP error 410.
https://api.launchpad.net/devel/~python-modules-team/gpg_keys
The direct error was fixed in commit 272f41c, but we actually should
*not* have been trying to look up this team's email address in the first
place. This upload was an auto-sync and so should not cause email to be
sent. The problem is that it was synced into universe and then promoted
into main. We were looking at the SPPH for after the promotion, which
has different values in the various signer/creator/sponsor/... fields,
and that made us think that it was a regular upload to email about.
Fix this by always looking at the oldest SPPH which should correspond to
the initial upload and not whatever happened to it afterwards.
In the previous iteration, if we were ever down/frozen/disabled long enough
to miss sending two mails in a row, we would see unintended "catch-up"
behavior where each subsequent run of britney would send a mail until the
right total number of mails had been sent. Don't do this; instead, catch us
up in one go to the most recent mail that should have been sent, avoiding
bunching of notifications.
This changes one of the tests also to match.
I want to fix two bugs in interactions between other parts of britney
and the email policy. It's not currently easy to do so because we just
run the policy itself manually by creating some fake excuses.
Steal part of the machinery from the autopkgtest tests, and run a few
tests through britney completely. Use a fake SMTP server to record which
emails we sent.
(The port is hardcoded - that might not be so smart.)
Currently we re-trigger all reverse binary dependencies of a package,
including binary packages built from the same source. We already
explicity trigger the source's own tests if they still exist in unstable
- don't also consider the source when looking at reverse dependencies.
Add new autopkgtest policy: it determines the autopkgtests for a
source package (its own, direct reverse binary dependencies, and
Testsuite-Triggers), requests tests via AMQP, fetches results from swift, and
keeps track of pending tests between run. This also caches the downloaded
results from swift, as re-dowloading them all is very expensive.
This introduces two new hints:
* force-badtest pkg/ver[/arch]: Failing results for that package will be
ignored. This is useful to deal with broken tests that get imported from
Debian or are from under-maintained packages, or broke due to some
infrastructure changes. These are long-lived usually.
* force-skiptest pkg/ver: Test results *triggered by* that package (i. e.
reverse dependencies) will be ignored. This is mostly useful for landing
packages that trigger a huge amount of tests (glibc, perl) where some tests
are just too flaky to get them all passing, and one just wants to land it
after the remaining failures have been checked. This should be used rarely
and the hints should be removed immediately again.
Add integration tests that call britney in various scenarios on constructed
fake archives, with mocked AMQP and Swift results.
