- reworked internal representation of stagings to be more flexible
- new considerable staging state of mergeable based on set of conditions
- multiple proposal stages can be combined to create one proposal
- proposals may now fail to find every group a home without stopping
- splitter_info is stored when first request in an empty staging is staged
to allow for automated merging into that staging
- strategy concept introduced along with several strategies
- strategy_try() concept for applying multiple strategies and keeping
desirable groups which provides a solid basis for making smart decisions
- merge() introduced for merging new requests into existing stagings
- various internal cleanups along the way
functionality exposed via osc-staging:
- new options: --merge, --try-strategies, --strategy
- splitter info written when not merging
stagingapi: add set_splitter_info_in_prj_pseudometa().
More appropriate to place inside --interactive check since that is the
only time the invalidation check should be needed. Also better since the
user is presented with a more accurate picture of what is to be done.
With the source no longer being checked for devel project and the fact
that delete requests and such will not have source, but make sense to
have a devel project moving to target makes more sense.
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.
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.
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.
With multiple people working on staging projects, it's not always clear to everybody
when things happened and it's helpful to easily be able to gather the information
Allow to skip full validation of /totest being fully synced.
This can be helpful (and is only meant to be used) when you run two
consequtive staging accept LETTER commands in a row.
* The first one would see /totest fully sync, not dirty
* the second call sees /totest as dirty, as the scheduler would first have
to process all data
In order to not have to wait for this to happen, the factory-maintainer CAN
override this with osc staging accept --force
Do not superseding requests with list command, but if had the permission
of staging, can executing with --supersede argument, or even against
specific requests.
