Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-39874

Abilty to disable pipeline-replay in Job Configuration.

      While the replay is good for debugging, it is also a huge security hole.

      Please allow users to disable this feature.

          [JENKINS-39874] Abilty to disable pipeline-replay in Job Configuration.

          Jesse Glick added a comment -

          https://plugins.jenkins.io/rebuild/ is an old plugin not needed by Pipeline users. In this context, Rebuild vs. Replay are indeed as in JENKINS-47339: Rebuild is simply Replay without the option to replace any Pipeline script, but otherwise implemented identically (including details such as parameters being copied, and checkout scm in a multibranch Pipeline using the same commit even if the branch head has since moved).

          Jesse Glick added a comment - https://plugins.jenkins.io/rebuild/ is an old plugin not needed by Pipeline users. In this context, Rebuild vs. Replay are indeed as in JENKINS-47339 : Rebuild is simply Replay without the option to replace any Pipeline script, but otherwise implemented identically (including details such as parameters being copied, and checkout scm in a multibranch Pipeline using the same commit even if the branch head has since moved).

          Matt Kucia added a comment -

          I am a bit confused. Doesn't the "new pipeline rerun" skip successful stages? I had a hard time communicating not to use "replay" button on Blue Ocean. If doing so the builds fail for me with missing resources. This isn't consistent and I do not know minimal replication steps for that problem. I have dynamic agents on k8s and workspaces are ephemeral.

          The perfect behaviour for my use cases (I do acknowledge that my configuration does not necessary consider others) would be that the Blue Ocean button behaviour is identical to rebuild plugin behaviour.

           

          btw We have 3 terms here: Rebuild, Rerun and Replay.

          I believe Rerun and Replay are the same and used interchangeably in Jenkins code.

          Rebuild is equivalent to "Build with parameters" with parameters picked from another, completed job run. There is a rebuild button in old UI added by the non-core plugin.

           

          Please consider my messages as user feedback, I am not trying to push anything here. I appreciate your effort to make Jenkins better.

          Matt Kucia added a comment - I am a bit confused. Doesn't the "new pipeline rerun" skip successful stages? I had a hard time communicating not to use "replay" button on Blue Ocean. If doing so the builds fail for me with missing resources. This isn't consistent and I do not know minimal replication steps for that problem. I have dynamic agents on k8s and workspaces are ephemeral. The perfect behaviour for my use cases (I do acknowledge that my configuration does not necessary consider others) would be that the Blue Ocean button behaviour is identical to rebuild plugin behaviour.   btw We have 3 terms here: Rebuild, Rerun and Replay. I believe Rerun and Replay are the same and used interchangeably in Jenkins code. Rebuild is equivalent to "Build with parameters" with parameters picked from another, completed job run. There is a rebuild button in old UI added by the non-core plugin.   Please consider my messages as user feedback, I am not trying to push anything here. I appreciate your effort to make Jenkins better.

          Jesse Glick added a comment -

          For Declarative Pipeline only, there is a distinct ability to restart a build from a specified stage. It is similar to Rebuild (i.e., Replay without permission to modify scripts) but sets a special flag interpreted by the Declarative system to skip earlier stages.

          Jesse Glick added a comment - For Declarative Pipeline only, there is a distinct ability to restart a build from a specified stage. It is similar to Rebuild (i.e., Replay without permission to modify scripts) but sets a special flag interpreted by the Declarative system to skip earlier stages.

          Jesse Glick added a comment -

          Oh and in case you were not confused enough today, CloudBees CI includes a checkpoint step which offers roughly analogous functionality to Scripted (but not Declarative) Pipelines.

          Jesse Glick added a comment - Oh and in case you were not confused enough today, CloudBees CI includes a checkpoint step which offers roughly analogous functionality to Scripted (but not Declarative) Pipelines.

          Reinhold Füreder added a comment - - edited

          *LOL* Thanks Jesse (especially for your humour): frankly, the confusion was certainly enough for me, so I waited till now before adding another (semi-important) comment

          => I trust you to find an acceptable solution – that is at least slightly better than the current confusing situation

          Reinhold Füreder added a comment - - edited *LOL* Thanks Jesse (especially for your humour): frankly, the confusion was certainly enough for me, so I waited till now before adding another (semi-important) comment => I trust you to find an acceptable solution – that is at least slightly better than the current confusing situation If "Rebuild" is supposed to stay, then your button renaming proposal according to https://issues.jenkins.io/browse/JENKINS-39874?focusedCommentId=405532&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-405532 is perfectly OK with me; I assume this applies to classic UI AND Blue Ocean UI...

          Jesse Glick added a comment -

          JENKINS-50855 pertains only to the “classic” UI. Blue Ocean is unrelated.

          Jesse Glick added a comment - JENKINS-50855 pertains only to the “classic” UI. Blue Ocean is unrelated.

          Dee Kryvenko added a comment - - edited

          I have another use case that might or might not be common, but it certainly makes me want to have an ability to disable this feature. Not just on the level of user access - just disable it period.

          I have a groovy lib that generates a pipeline dsl dynamically and then evaluates it. It is being generated in chunks that are evaluated separately. When my team (who unlike my users - are jenkins admins by design having full access to everything) click Replay - due to the dynamic dsl generation they see 10+ text boxes with parts of the dsl. Because at Replay this dsl getting called outside of the proper context - it just fails. Replay just doesn't work for me and creating more issues than it solves. Not all of my team understands the way groovy lib and CPS works in Jenkins - most of them just configure jobs and by coincidence have access to the Replay feature. I wish I could completely disable Replay for our prod Jenkins instance just because it is buggy for us in the library context.

          Dee Kryvenko added a comment - - edited I have another use case that might or might not be common, but it certainly makes me want to have an ability to disable this feature. Not just on the level of user access - just disable it period. I have a groovy lib that generates a pipeline dsl dynamically and then evaluates it. It is being generated in chunks that are evaluated separately. When my team (who unlike my users - are jenkins admins by design having full access to everything) click Replay - due to the dynamic dsl generation they see 10+ text boxes with parts of the dsl. Because at Replay this dsl getting called outside of the proper context - it just fails. Replay just doesn't work for me and creating more issues than it solves. Not all of my team understands the way groovy lib and CPS works in Jenkins - most of them just configure jobs and by coincidence have access to the Replay feature. I wish I could completely disable Replay for our prod Jenkins instance just because it is buggy for us in the library context.

          Yacine added a comment - - edited

          I just wanted to add that "replay" is not equal to "rebuild" form the usage os shared libraries point of view:

          • "replay build #XX" uses the same version of the shared library that was use during the first build of the build #XX
          • "rebuild build XX" loads the shared libraries again: so with rebuild we get the latest version of a shared library

          this behavior confuses our users for example in the following case:

          1. we release pipeline code in form a shared library release
          2. before the release of a shared library, the users were using version 1.0 ( tag stable) of the shared library
          3. After the release the tag stables points to a different version (2.0 for example )
          4. but a replay in this case is not loading version 2.0, and the users are still using the old version 1.0 ( sometimes with breaking changes )

          therefore it would be good for us if we could disable the "replay" button completely (it shouldn't be visible) for normal users who have the "build" permission and no "configure" permission

          Yacine added a comment - - edited I just wanted to add that "replay" is not equal to "rebuild" form the usage os shared libraries point of view: "replay build #XX" uses the same version of the shared library that was use during the first build of the build #XX "rebuild build XX" loads the shared libraries again: so with rebuild we get the latest version of a shared library this behavior confuses our users for example in the following case: we release pipeline code in form a shared library release before the release of a shared library, the users were using version 1.0 ( tag stable) of the shared library After the release the tag stables points to a different version (2.0 for example ) but a replay in this case is not loading version 2.0, and the users are still using the old version 1.0 ( sometimes with breaking changes ) therefore it would be good for us if we could disable the "replay" button completely (it shouldn't be visible) for normal users who have the "build" permission and no "configure" permission

          Jim Klimov added a comment -

          Additionally, "replay" is not equal to "rebuild" for jobs that can take build arguments: the "replay" does not offer to change their values, and just uses what was specified in the replayed run.

          If you had a typo in one of a dozen arguments, with Replay alone you have to schedule a new job (Build with Arguments) and copy-paste all those args and amend the one you got wrong the first time.

          On a related side note: Woe on you if you are in the midst of developing a pipeline in a (hopefully local) Jenkins instance, replaying its iterations a few dozen times before you copy-paste successful stuff back to an editor, and need to change some build argument to test a codepath.

           

          At the very least, it is confusing however to see two "Rebuild" buttons for under-privileged users, whereas ones allowed to edit the pipeline see "Rebuild" (from respective plugin) and "Replay" separately:

           
          ...and that in Blue Ocean the same action is known as a "Rerun"

          Jim Klimov added a comment - Additionally, "replay" is not equal to "rebuild" for jobs that can take build arguments: the "replay" does not offer to change their values, and just uses what was specified in the replayed run. If you had a typo in one of a dozen arguments, with Replay alone you have to schedule a new job (Build with Arguments) and copy-paste all those args and amend the one you got wrong the first time. On a related side note: Woe on you if you are in the midst of developing a pipeline in a (hopefully local) Jenkins instance, replaying its iterations a few dozen times before you copy-paste successful stuff back to an editor, and need to change some build argument to test a codepath.   At the very least, it is confusing however to see two "Rebuild" buttons for under-privileged users, whereas ones allowed to edit the pipeline see "Rebuild" (from respective plugin) and "Replay" separately:   ...and that in Blue Ocean the same action is known as a "Rerun"

          Edgars Batna added a comment - - edited

          Also, replay has "no idea what it is doing" in the context of shared library load calls (and the load calls themselves have a race condition https://issues.jenkins.io/browse/JENKINS-69224). We are using a shared library that handles every job out of 999+ and there the load step is called in some random place in Groovy. If I press Replay, then it lists all scripts numerically like Script1...N, but the thing is, they all come from nested parallel steps, so the order is not reproducible. If a user replays the job, the wrong override text is used for the wrong load step so we end up with random behavior.

          Edgars Batna added a comment - - edited Also, replay has "no idea what it is doing" in the context of shared library load calls (and the load calls themselves have a race condition https://issues.jenkins.io/browse/JENKINS-69224 ). We are using a shared library that handles every job out of 999+ and there the load step is called in some random place in Groovy. If I press Replay, then it lists all scripts numerically like Script1...N, but the thing is, they all come from nested parallel steps, so the order is not reproducible. If a user replays the job, the wrong override text is used for the wrong load step so we end up with random behavior.

            Unassigned Unassigned
            netsabes Sebastien Vas
            Votes:
            25 Vote for this issue
            Watchers:
            29 Start watching this issue

              Created:
              Updated: