When no tarballs can be successfully found by any mechanism,
fetch_orig()'s loop will exit. Since no return statement was provided
in such a case, the function returns None. exportorig.py's main()
routine returns this None directly to the top level, where it is stored
in the variable tarball. This results in a traceback like:
File "/snap/git-ubuntu/477/usr/lib/python3/dist-packages/gitubuntu/exportorig.py", line 117, in cli_main
if len(tarballs) > 0:
TypeError: object of type 'NoneType' has no len()
We don't yet have test cases for build.py, but I added an assert in
fetch_orig() prior to its return to avoid papering over unrelated errors
in mechanisms.
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.
