SLE service packs are just too complex to check delete requests sanely,
so better disable it. For next SLE we would enable it though
Fixes#2221 and ##2282
If the package name as reported by OBS does not match the one
we're expecting, then loop through all repositories and check
if we find one there.
This is weakening the policy a little as this will open the
door for false negatives - e.g. that got the right package name
only for another repository. But as we do submission between
code streams all the time, I can't limit the package parsing
to repositories building against the target. So the opened
hole is to be closed by sanity check on review-team - as a
matter of fact the policy is not to catch people playing
macro games around Name, but for people that use completely
different names in source and target.
Fixes#2274
Currently if set_snapshot_number is true, it uses "Snapshot" as prefix.
In some cases it's necessary to use a different one. This can now be configured
using the "snapshot_number_prefix" option.
A common workflow is:
* pkg is being marked for deletion by repo-checker [botdel]
* User comes to the rescue and fixes the package, Submits the fix
* Commonly, the delreq is being declined (by factory-maintainer)
* factory-auto declines SR, as pkg now has a delreq and subreq pending
* factory-auto does not consider the 'declined' request as replacable
and complains that it should be revoked (or superseded). Since the
del req was created by repo-checker, 'nobody' has the credentials to
revoke the request. The user, not having a role in the old SR, has
no permission to supersede
So let's just accept a delete request in statet 'declined' as something
that can be replaced by a submit request for the same package.
As image names have a pattern in 15-SP2 (SLE*), change the script that
release to TEST to use this image name pattern instead of list all
images.This will avoid frequently updates in script cause by new image
package submissions.
It takes a long time to sync the repos but ISOs are very quick. This lead
to the problem that openQA already started syncing the build while the
repo was synced up. As the repository is set to unpublished in between
the calls, openQA has no chance to see that more is to come.
So if we release the slow products first, openqa has a better chance to
catch up.
