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.
This allows for multiple project_only runs with a different main-repo set.
It is very unlikely this feature will be used, but will handle it properly
to be consistent with pseudometa file name.
This becomes necessary for multi-action requests like those seen in
maintenance where there may be multiple repositories reviewed for a single
request. The result is multiple comments made on the staging project which
would override each other. This treats them separately just as devel
project comments do with target project.
Drop in #1644, but as suspected it is needed. The reason the side-effect
was not notice right away is the package description cache for a package
making use of the requirement must be rebuilt. This means the package
must be updated since the last time cache was built.
After completely a force rebuild of entire cache the behavior is correct
by only adding this back. Unlike the case below these binaries are not
published to the end-user so this is more a quirk of the data present in
OBS for staging projects.
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 owner logic surrounding a package removed from Factory does not appear
to make sense as the current behavior of OBS never returns another owner
pair for such packages. As such the existing devel project lookup makes
more sense and is more straight forward.
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
Half the bots already utilize the Cache since it is used by StagingAPI
which they call, but really no reason for all of them not to use it by
default. With planned repo_checker changes the StagingAPI is not always
utilized, but it is desirable for the cache to always be used.
No sense calling Cache.init() in ReviewBot constructor as useless extra
calls when bots embed each other.
