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.
If the package was linked to Ring1 from Ring1, staging list command
should display it as Ring0 package ie. it's only be able to puts in
ring0 staging project. This is work out
https://progress.opensuse.org/issues/8266
If release-notes-sles is existed then it is not openSUSE Factory but
SLE, hence do not check totest and openSUSE-release.rpm on it.
And add try/except protection in get_binary_version otherwise it will
crashes in case the package is not existed.
It's workaound for https://progress.opensuse.org/issues/9646, suppose it
is adi staging in case current project doesn't have ":DVD" subproject,
and the package is exist in current project.
Do not superseding requests with list command, but if had the permission
of staging, can executing with --supersede argument, or even against
specific requests.
