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.
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
Previously, the additional layers supported added by coolo treated them
like staging projects which meant that everything except the bottom
override the bottom. Obviously, for SLE service packs this is not correct.
This rewrorks the underlying perl script to support a stack of directories
where the second directory is assumed the be the target project for the
purposes of the toignore (-f) argument and the top layer is the only
one for which problems are reported.
For Factory, Leap and SLE15 it doesn't matter as they are self contained.
But for Service Packs we use layering, so we need to mirror and check them
too
The break on openQA failures is a left over from 93ee829260a6abf094cbbc31e26eb21bf45e8f15
where we stopped the loop over subprojects. We don't want to break out of
the review loop on openQA failures
So far, repo-checker only validated that a delete request won't cause build
dependency failures, but there was no check that removal of a package won't
break other runtime dependencies.
Fixes issue #277
For SLE where devel projects are not utilized post on the target packages
directly. Posting on the devel projects might make sense, but would pose
the risk of exposing IBS information on OBS prematurely.
