Without this, the relative rarer types of requests seen in projects with
staging and handled by list command will be included in staging proposal.
However, since they are not stageable the select operation will fail. This
change ensures that a filter is always present when stageable is True to
exclude non-stableable requests. The list command sets stageable to false
in order to list out the non-stageable requests of interest.
This was not observed in openSUSE since the main non-stageable request was
change_devel and that was exluded in StrategyNone. That filter could be
replaced with the stageable filter, but having an always on filter seems to
make more sense since generally operating in one of two modes.
We can't generally assume ISOs can be fetched from backend (we can't
have this on IBS), so publish it - and disable the actual publishing
on the staging backend of OBS
Submitters complain more and more about the spam they're getting from
staging projects - and we rather leave that weapon for actual feedback.
One especially annoying case is if a package is added to one staging project
and then later moved to another, the submitter will receive notifications
of all kind of bots and actions for both staging projects.
The _result view checks way more things than we need, so just iterate
through the architectures of a repository and check the binaryversions
per arch. And combine the sha1sums to one sha1 per repository
For whatever reason the state hash only includes the overall publish states
and not the binaries within the repository. As such, rebuilding state
before a rebuild and after may be the same.
Distinct copyrights were left as I do not wish to track down commit
history to ensure it properly documents the copyright holders. Also left
non-GPLv2 licenses and left bs_copy untouched as a mirror from OBS.
Already have a mix of with and without headers and even OBS does not place
on majority of files. If SUSE lawyers have an issue it will come up in
legal review for Factory.
Since the tool has been expanded to work on any repository, there are more
repositories that would want direct comments than devel. Set the value
to be devel for the openSUSE products which are the places where that is
desirable.
The rework includes a variety of changes:
- multiple actions per request supported
- automatically detecting "main" repo (useful for devel/home projects)
- full layered repository path state and published taken into account
- arbitrary repository name (ie. not just standard) supported
- intermediate results (used for staging) no longer accept (even if no
problems detected) until all layers are published
- no longer tied to staging process, but still supports staging workflow
- robust handling of repository state changes during review cycle
- multiple repositories supported for project_only output (ie. file name)
- project_only run supports any OBS project instead of only products
- maintenance_release requests supported with alternate staging approach
These methods provide for a generic place to store meta data related to
a project. For the time being, keep the original :Staging/dashboard
location for openSUSE products.
Given the slow migration of everything to the shared project config in
tools that change project contexts multiple times a consistent way of
accessing the config without forcing remote calls is needed.
