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.
Since commit 295fcd we newly also require http_POST in order to
put a new file in place after accepting.
Also add quotes around the fakepkgname when injecting it into the kiwi file.
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
With --split argument, staging adi command can splits each package to
different adi staging project, the argument can work by 'osc staging adi
--split' or 'osc staging adi --move --split'. Note that, it will be
ignore --by-develproject argument too.
Update by_dp function in adi command, the old way is incompatible to
newer Leap development model, now we should try to check target package
in Factory as well, otherwise the submission from any other place than
Factory did not have 'devel' entry in _meta.
Workaround glibc.i686 package config, it had a topadd block in _link,
and looks like it causes the disturl won't consistently with glibc even
with the same srcmd5. And the lastsuccess state will be outdated if the
revision is used the same srcmd5.
Note: the proper workaround, to instead of
5daf2bb6509abaf966268c9d6b13aa4e330a8af3
Workaround glibc.i686 package config, it had a topadd block in _link,
and looks like it causes the disturl won't consistently with glibc even
with the same srcmd5. And the lastsuccess state will be outdated if the
revision is used the same srcmd5.
