When running as a systemd daemon, it is useless to wait for user input
to possible trigger an earlier re-run. Interaction is not possible.
Additionally, there is no stdin assigned to the process when running as
a systemd daemon, which results in raw_input() failing with EOFError
- re-implement list and adi commands using RequestSplitter
- numerous small cleanups and clarity improvements
- notably, adi now prints similar output to select when adding requests
- lxml is needed to provide more fully-featured xpath implementation
Compare packages from a project against factory for differences in
referenced issues and present changes to allow whitelisting before
creating bugzilla entries. A database is kept of previously handled
issues to avoid repeats and kept in sync via a git repository.
--factory option can be specified multiple times to check against
a list of projects. For example checking against Factory and Leap
for the Backports project.
Check will loop over each project and break as soon as a match is
found. Project search order matches order of --factory options (at least
in testing).
It is not uncommon for a request to be in a pending state which requires
action beyond the scope of the staging workflow, but does not make sense
to deny the request. For lack of a "postponed" or "pending" state on OBS
a sudo-state of "ignore" is provided for the staging workflow. The ignore
state will remove a request from the "list" and "adi" commands so as not
to be accidentally staged. This avoids the need for keeping a context of
what requests should be ignored in one's memory.
It is expected that an ignored request will have comments reflecting what
is to be done or one should be added via the -m option of ignore command.
The two slowest staging API calls are for information that rarely changes.
By caching the result the commands typically execute over twice as fast.
Going further can see improvements of an order of magnitude or more by
caching almost all the GET requests.
In contrast to osclib/memoize.py this cache operates at the HTTP request
level. This has several advantages:
- Caches the expensive part (ie the HTTP request). There are a number of
functions in osc.core and elsewhere that make the same API request, but
process the result differently which would require multiple API calls
using memoize.
- Handles cases were a loader function uses class attributes as input and
output and thus no relevant method parameters or return. An important
example is StagingAPI._generate_ring_packages().
- Storage is project aware which allows caches to be deleted when a project
is known to have changed.
- Due to project awareness, can utilize OBS /statistics/latest_updated API
call to determine which projects need to be expired.
The cache file structure is as follows:
- hostname(apiurl)
- project
- sha1(url)
- sha1(url)
See Cache.PATTERNS for changing the time to live (ttl) or add patterns to
be cached.
