In order to use the new rich history supply facility, developers need to
push their rich history to Launchpad and then provide a reference to
that location using headers in the changes file.
This will run dpkg-buildpackage as normal, but first push the current
branch to the default location. The default location is configured as
"gitubuntu.lpuser" and should be set for git-ubuntu users already. The
generated changes file will contain headers to find the pushed branch
for later rich history adoption.
This is an experimental subcommand, and we'll need to finalise the
details before release of git-ubuntu 1.1. I'm deferring writing a
manpage until we've settled on the CLI, as I expect some iteration will
be needed to make this most convenient for developers' common workflows.
Allow uploaders to specify where rich history associated with an upload
can be found directly from the changes file. This allows rich history to
be provided by any uploader without concern for things like access
control for pushing upload tags.
This partly deprecates upload tags. The generally recommended approach
to supply rich history will be through the changes file. Upload tags
remain to preserve the rich history preservation mechanism on reimport.
After a transition to changes file based rich history is complete, we
might refactor the rich history preservation mechanism and then drop
support for upload tags altogether. However it might be useful to retain
upload tag support for testing purposes, as they are easier to arrange
than this new changes file mechanism.
For the retry logic, we add a dependency on tenacity. This module seems
to be the most widely used for this purpose, and is already in main in
Ubuntu Focal.
The underlying Launchpad source_package_publishing_history object may
contain a reference to a changes file associated with an upload. Add a
method to access this through the SourcePackageInformation object if it
exists.
In a following change we will need find_or_create_unapplied_commit() to
opportunitistically have access to the underlying
SourcePackageInformation object if there is one available, so that it
can find any provided rich history through that channel. So pass it
through when it exists.
Arrange for the caller to provide the warning messages instead of the
callee.
For this to work, we return the nature of the validation failure in an
exception instead of returning False to indicate a validation failure.
The exception itself provides the nature of the problem, so we can
reduce ourselves to printing a single warning.
The version parameter is no longer needed since it was only used to
generate the warning, which is now done by the callee.
This refactoring will allow the validate_upload_tag() function to become
generic to rich history validation in general, and no longer be specific
to upload tags.
