You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
list --supersede is very useful to "cleanup" incoming requests with pending one, but it can also cause a "supersede" in a staging you were about to accept (everything is green) or didn't want to touch (very slow to rebuild).
Some --dry-run for the supersede would be useful, to analyze if supercede will be "safe" or not.
The text was updated successfully, but these errors were encountered:
This still won't guarantee the staging remains acceptable:
A user could do osc rq --supersede
the time gap between running osc staging list --dry-run vs finally running the execution is non-atomic, changes could happen in the mean time (a new submission incoming)
With those limitations understood, I'd say a --dry-run CAN be beneficial in some cases
The supersede code was rather fragile as I discovered when trying to make it actually output what changes were made. Adding a dry-run mode and propagating through the call stack will likely either be cumbersome or somewhat ugly to do. The ReviewBots have a --dry-run mode that provides a class variable that can be checked before making actual changes which could be mimicked in the StagingAPI class.
Alternatively, perhaps one could indicate the stagings on which to act (ie ones you are not about to accept). The supersede command I added already supports acting on specific packages and requests and should not be too hard to filter on staging.
list --supersede is very useful to "cleanup" incoming requests with pending one, but it can also cause a "supersede" in a staging you were about to accept (everything is green) or didn't want to touch (very slow to rebuild).
Some --dry-run for the supersede would be useful, to analyze if supercede will be "safe" or not.
The text was updated successfully, but these errors were encountered: