This was debated as for SLE this would add some repetition when not
going to match a SLE origin anyway, but it is necessary to stabilize
maintenance origins.
When an :Update project is first created all sources are inherited which
means all the revisions from the top project's source container are
considered. Once an update is provided via a maintenance incident the
inherited sources are no longer presented and instead the only revision
seen is the maintenance update and future updates.
When a new version of Leap is created and all source containers are copied
from the previous version the origin will first be considered :Update of
the previous Leap version, but once a maintenance update is created it
will drop the the non-:Update prior version since the matching revision is
missing. If the update is submitted the origin will flip back to :Update.
In order to avoid this mess always utilize include_project_link=True
which will effective consider the maintenance update as the newest
revision while continuing to consider the inherited revisions.
For SLE, were all projects are stacked this means there will almost always
be 10 revisions to review after the first could releases.
Realistically this is yet another failing of the OBS source control model since
the original source revision available (via inheritance) in the :Update project is
lost after the first update.
Given the broken design of multi-action requests which continually wreaks
havoc on code attempting to handle them properly a series of methods for
searching for requests are provided to simplify the process. The core
principal is that both a request and action are returned since the
specific action that matched the search query is important.
Further poorly designed maintenance data structure is also abstracted to
provide a consistent interface for querying source changes regardless of
their state in the workflow.
A rather small reviewbot just made for one thing: check maintenance
release requests. They are much easier to handle: they are only created
on locked projects, so there is no waiting required. Just checking
and if it's broken, the request can be declined.
Extract the writing of the susetags content into a new script that
also creates a yaml file which package comes from what directory.
This information is used in repochecks.py to run findfileconflicts
and installcheck as repo_checker.pl used to
Right after commit of a package into a staging project, it can happen
that OBS replies to GET with 'service in progress' and then we don't
get a file list. As we ignored that exception, we did not create the
other spec files.
Now enhance retried_GET to look for this condition and retry this as
well, so we get reliable package list.
Makes sense always return string from source_file_load(), this
preventing potentially TypeError on python3. Also changed product file
loading, now source_file_load() used.
