The check for bcntsynctag can be very misleading - just because we align
the build counters between 2 packages doesn't make them invalid submission
targets. Better rely on the link check which is already implemented as
fallback
And set a verbose decline reason for this case
* Simplify the 'accept' code
openSUSE:Factory/snapshot is newly setup as a Download on Demand repository
and we can thus safe ourselves the hassle of having to take extra care of
handling delete requests. They no longer bleed directly into the /snapshot
area and can now be accepted like any other request
* Drop vdelreq plugin
Since we no longer do a virtual accept of delete requests, we also don't
have to monitor their state anymore. Drop the plugin that served only
this usecase
* Drop the acheck command
As a consequence, the command 'staging acheck' serves no purpose anymore:
/totest was just there to ensure we have something to copy to /snapshot.
This entire repo will vanish, and it is thus no longer needed to verify
if it is in sync before accepting new data.
To improve robustness and handle invalid/corrupt data in the annotation
just return None if it is anything other than a dict after parsing. The
most likely occurrence is someone accepts the origin-manager review with
a plain-text message.
This excludes reviews that were added and never reviewed possibly because
the request was rejected before the review could be accepted. In such
cases the comment specified when adding the review will be loaded as the
annotation which is not desirable.
For example, SLE-15-SP2 has openSUSE.org:openSUSE:Factory as an origin.
The events for that project are not included on the IBS message bus and
thus package updates to that project will be missed. When origins contain
a remote prefix another listener needs to be started pointing at the
remote OBS instance message bus. The resulting messages need to be
prefixed before being considered by the primary listener.
Without this, python 3 execution will fail with:
TypeError: Unicode-objects must be encoded before hashing
The requests strategy is the only strategy to utilize kwargs besides
custom so this code is not executed often which is why this has not been
encountered. In fact it was executed mistakenly and reported.
Python 3 makes map() a lazy call and since the result is not needed it
makes sense to just switch to explicit loop. Without this the "loop" (via
map) is never executed. As such, --try-strategies effective does nothing
and instead the staging-bot always falls back to none strategy.
