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.

          [JENKINS-16417] Extensibility for Run.whyKeepLog

          Daniel Beck added a comment -

          Daniel Beck added a comment - https://github.com/jenkinsci/jenkins/pull/1093

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          changelog.html
          core/src/main/java/hudson/model/Run.java
          http://jenkins-ci.org/commit/jenkins/22f2238b23312a54e8e07d6100446d30bfc67d0a
          Log:
          JENKINS-16417

          My recommended fix in response to https://github.com/jenkinsci/jenkins/pull/1093. This does not eliminate nor exclude the need for more generic pluggability, but it would at least address the security concern.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/src/main/java/hudson/model/Run.java http://jenkins-ci.org/commit/jenkins/22f2238b23312a54e8e07d6100446d30bfc67d0a Log: JENKINS-16417 My recommended fix in response to https://github.com/jenkinsci/jenkins/pull/1093 . This does not eliminate nor exclude the need for more generic pluggability, but it would at least address the security concern.

          Since there already is an extension point to attach arbitrary badge to arbitrary build, one possible approach is to allow badge to also keep the build.

          Another approach is to define an extension point to force LogRotator.shouldKeepRun() to return false without modifying the state of a build, like TransientActionFactory does.

          Kohsuke Kawaguchi added a comment - Since there already is an extension point to attach arbitrary badge to arbitrary build, one possible approach is to allow badge to also keep the build. Another approach is to define an extension point to force LogRotator.shouldKeepRun() to return false without modifying the state of a build, like TransientActionFactory does.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3172
          JENKINS-16417 (Revision 22f2238b23312a54e8e07d6100446d30bfc67d0a)

          Result = SUCCESS
          kohsuke : 22f2238b23312a54e8e07d6100446d30bfc67d0a
          Files :

          • core/src/main/java/hudson/model/Run.java
          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #3172 JENKINS-16417 (Revision 22f2238b23312a54e8e07d6100446d30bfc67d0a) Result = SUCCESS kohsuke : 22f2238b23312a54e8e07d6100446d30bfc67d0a Files : core/src/main/java/hudson/model/Run.java changelog.html

          Code changed in jenkins
          User: Kohsuke Kawaguchi
          Path:
          core/src/main/resources/hudson/model/Run/logKeep.jelly
          http://jenkins-ci.org/commit/jenkins/02ab7484f8dbf861ccdfc5d2da37ac0ede2f263b
          Log:
          JENKINS-16417

          Follow up fix as pointed out by Daniel Beck.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/resources/hudson/model/Run/logKeep.jelly http://jenkins-ci.org/commit/jenkins/02ab7484f8dbf861ccdfc5d2da37ac0ede2f263b Log: JENKINS-16417 Follow up fix as pointed out by Daniel Beck.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3176
          JENKINS-16417 (Revision 02ab7484f8dbf861ccdfc5d2da37ac0ede2f263b)

          Result = SUCCESS
          kohsuke : 02ab7484f8dbf861ccdfc5d2da37ac0ede2f263b
          Files :

          • core/src/main/resources/hudson/model/Run/logKeep.jelly

          dogfood added a comment - Integrated in jenkins_main_trunk #3176 JENKINS-16417 (Revision 02ab7484f8dbf861ccdfc5d2da37ac0ede2f263b) Result = SUCCESS kohsuke : 02ab7484f8dbf861ccdfc5d2da37ac0ede2f263b Files : core/src/main/resources/hudson/model/Run/logKeep.jelly

          Daniel Beck added a comment -

          Can probably be considered fixed despite there not being extensibility.

          Daniel Beck added a comment - Can probably be considered fixed despite there not being extensibility.

            Unassigned Unassigned
            jglick Jesse Glick
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: