Expect the caller to provide a pygit2.Commit object instead of a commit
hash string. We're moving to this as a standard, and in addition this
will allow the implementation to more directly examine the commit which
will be needed for tag hash stability.
For testing purposes we will need to specify particular committer,
author and tagger signatures in test commits and tags, so add support
for this to repo_builder.
We'd like to be able to specify the tagger precisely to enable hash
stability for tags. This adds the tagger parameter to create_tag() to
permit this to happen.
It is easiest to switch to the pygit2 create_tag() implementation
instead of calling the git CLI, so this relatively trivial conversion is
done at the same time. The existing tests should be sufficient to ensure
that this doesn't break anything, but a unit test is also added.
Note that the behaviour is slightly changed: before, the tagger used was
not defined, and in practice was using the name and email from git's
configuration together with the current time as inferred by git. Now
we're using a standard name and email address by default, and looking up
the current time ourselves (timezone-aware and based on the
system-configured timezone).
This moves the implementation of the conversion from datetime.datetime
into parameters suitable for the pygit2.Signature constructor into its
own function for future reuse. This also allows for better unit testing.
Importer notes are generic notes about the import that, by being stored
as a git note, won't affect the resulting commit hashes. This allows
them to be a relatively free form place where we can store information
about the import that happened. For now, we'll put the timestamp of the
import itself and the git-ubuntu version used in the importer note.
Using importer notes allows us to move this information away from tags
so that tags can then be adjusted to be hash-stable.
There is no need for implementation in "git ubuntu clone" as these notes
are for diagnostic purposes only so need not be fetched by users by
default.
The specification requires that we consider Debian and Ubuntu
publications in Launchpad simultaneously, ordering by date_created
across them both. This implements this requirement with
interleave_launchpad_versions_published_after() to wrap multiple calls
of launchpad_versions_published_after() and interleaving the results as
they are returned. The caller is adjusted to use this instead of
iterating over the two distributions separately.