|
Currently Run.keepLog(boolean) asks for Run.UPDATE permission to toggle whether or not to keep a given build. It may make sense to distinguish between passing true, which is a relatively harmless act that anyone testing a build might need, and false, which will eventually lead to the build being deleted and which administrators might therefore want to restrict. Perhaps passing false should require DELETE instead of (or in addition to) UPDATE. Then an administrator can be assured that important builds, e.g. corresponding to product releases, will not be deleted casually.
To implement this without changing the semantics of the current “keep” badge that some users may rely on or find more convenient, it would be useful to add an extension point to Run.getWhyKeepLog allowing plugins to inject other reasons to keep a build. Then a plugin could offer a keep badge following the semantics described above, without affecting the logic of the standard badge.
Other possibilities could be implemented as well, such as a marker which can be removed only by submitting an annotated request going into an administrative queue; or an automated keep for a build whose artifact is known to have been deployed to a Maven release repository (according to hash lookup).
The existing overrides—for downstream projects, matrix builds, and Maven module sets—could probably be factored out into extensions too.
|
