• Icon: Improvement Improvement
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None
    • Platform: All, OS: All

      When you copy a job it should be disabled by default so that any modifications
      can be made to it before it tries to run.

          [JENKINS-2494] Copied jobs should be disabled by default

          ajpurkiss created issue -

          ajpurkiss added a comment -

          Created an attachment (id=411)
          Patch to disable the job

          ajpurkiss added a comment - Created an attachment (id=411) Patch to disable the job

          torbent added a comment -

          Absolutely! I've been bitten by this many times, sadly. The problem is made
          worse in our setup because we use custom workspaces, so the new copy actually
          builds on top of the original. Unless I'm quick to disable the new job.
          Maintainers, there's already a (year-old) patch to fix this issue, so can we
          have it fixed, please?

          torbent added a comment - Absolutely! I've been bitten by this many times, sadly. The problem is made worse in our setup because we use custom workspaces, so the new copy actually builds on top of the original. Unless I'm quick to disable the new job. Maintainers, there's already a (year-old) patch to fix this issue, so can we have it fixed, please?

          torbent added a comment -

          (added me as cc)

          torbent added a comment - (added me as cc)

          mdillon added a comment -

          We had a ticket in our (Yahoo!'s) internal tracker for this same thing. Here is
          the comment I made there:

          Here's the rough sequence for a clone:

          1. Make an in memory copy of the job to be cloned
          2. Change the name on that copy
          3. Add the copy to Hudson's internal job list
          4. Save the job to disk
          5. Redirect to the post configuration screen

          The sequence for a new job is about the same except it starts with a blank copy
          of the job.

          In terms of implementation, it may be that we could do this:

          2a. Set disabled flag to true
          ...
          5a. Set disabled flag in the HTML form to whatever it was in the original job

          This way, when someone saves it will be enabled without them having to remember
          to check the checkbox, but Hudson won't actually see an enabled job unless it is
          saved. This behavior would only happen on the post config redirect; if you
          abandon the post config page, the job stays disabled and if you edit it, the
          form will show it as disabled.

          mdillon added a comment - We had a ticket in our (Yahoo!'s) internal tracker for this same thing. Here is the comment I made there: Here's the rough sequence for a clone: 1. Make an in memory copy of the job to be cloned 2. Change the name on that copy 3. Add the copy to Hudson's internal job list 4. Save the job to disk 5. Redirect to the post configuration screen The sequence for a new job is about the same except it starts with a blank copy of the job. In terms of implementation, it may be that we could do this: 2a. Set disabled flag to true ... 5a. Set disabled flag in the HTML form to whatever it was in the original job This way, when someone saves it will be enabled without them having to remember to check the checkbox, but Hudson won't actually see an enabled job unless it is saved. This behavior would only happen on the post config redirect; if you abandon the post config page, the job stays disabled and if you edit it, the form will show it as disabled.

          mdillon added a comment -

          Can't believe this thing makes me add a comment to put myself on the cc list...
          Can't wait for JIRA.

          mdillon added a comment - Can't believe this thing makes me add a comment to put myself on the cc list... Can't wait for JIRA.

          ajpurkiss added a comment -

          Interesting, though from my point of view I have no problem either unchecking
          the box before I save or clicking the enable button when the job is saved.

          ajpurkiss added a comment - Interesting, though from my point of view I have no problem either unchecking the box before I save or clicking the enable button when the job is saved.

          When slaves are copied, the newly created one is put into a temporary transitive
          "disabled until next save" state. I wonder if the same should be done for jobs,
          instead of disabling the job, which would require people enabling it manually.

          Kohsuke Kawaguchi added a comment - When slaves are copied, the newly created one is put into a temporary transitive "disabled until next save" state. I wonder if the same should be done for jobs, instead of disabling the job, which would require people enabling it manually.

          mdillon added a comment -

          I hadn't seen holdOffLaunchUntilSave, but something that is basically what I was
          suggesting. That would let the "disabled" flag keep the original state of the
          copied job, while the other flag would make isDisabled() return true regardless
          of the state of the "disabled" field. The jelly form would need to be changed to
          look at a method other than isDisabled() to allow it to reflect the original
          state of the copied job until a save is done.

          mdillon added a comment - I hadn't seen holdOffLaunchUntilSave, but something that is basically what I was suggesting. That would let the "disabled" flag keep the original state of the copied job, while the other flag would make isDisabled() return true regardless of the state of the "disabled" field. The jelly form would need to be changed to look at a method other than isDisabled() to allow it to reflect the original state of the copied job until a save is done.

          ajpurkiss added a comment -

          Interesting, I like the idea of only a temporary disable (unless of course the
          user marks it disabled). My main concern right now is that polling jobs that
          are copied are risky right now as they can run before all relevant changes are
          made. If the full fix to address this is going to take some time to implement
          (and I dont have time to help try to implement it) then I would like the
          temporary fix put in place as I have stopped building Hudson locally now as I
          can do most of my changes through plugin bar this.

          ajpurkiss added a comment - Interesting, I like the idea of only a temporary disable (unless of course the user marks it disabled). My main concern right now is that polling jobs that are copied are risky right now as they can run before all relevant changes are made. If the full fix to address this is going to take some time to implement (and I dont have time to help try to implement it) then I would like the temporary fix put in place as I have stopped building Hudson locally now as I can do most of my changes through plugin bar this.

            jpederzolli jpederzolli
            ajpurkiss ajpurkiss
            Votes:
            4 Vote for this issue
            Watchers:
            7 Start watching this issue

              Created:
              Updated:
              Resolved: