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

Copied jobs should be disabled by default

    XMLWordPrintable

Details

    • Improvement
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Fixed
    • core
    • None
    • Platform: All, OS: All

    Description

      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.

      Attachments

        Issue Links

          Activity

            jpederzolli jpederzolli added a comment -

            committed patch after getting ok from Kohsuke.

            jpederzolli jpederzolli added a comment - committed patch after getting ok from Kohsuke.

            Code changed in hudson
            User: : mindless
            Path:
            trunk/www/changelog.html
            http://jenkins-ci.org/commit/31454
            Log:
            JENKINS-2494 note in change log

            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/www/changelog.html http://jenkins-ci.org/commit/31454 Log: JENKINS-2494 note in change log
            nealeu nealeu added a comment -

            I've just copied a Maven job and found that it ran with the existing before I'd saved it.

            Has the "Apply" button behaviour caused a regression here?

            nealeu nealeu added a comment - I've just copied a Maven job and found that it ran with the existing before I'd saved it. Has the "Apply" button behaviour caused a regression here?

            Code changed in jenkins
            User: Stephen Connolly
            Path:
            core/src/main/java/hudson/model/Job.java
            http://jenkins-ci.org/commit/jenkins/503c3bd2e6f2ec85514e16a260396ddae68f03ae
            Log:
            [FIXES JENKINS-2494] Restore correct behaviour

            • Fixes a regression in core where the display name clear on copy was triggering a save
            • More than one way to do this, could also have used the marker interface approach
              This route seems slightly less fragile, though people could still add ItemListeners
              with order == -Double.MAX_VALUE which would then introduce intdeterminism.
              A marker interface would remove that indeterminism as the onCopyComplete method would
              be only called on the Job as the last method... but it could be hard to
              ensure that all ItemGroupMixin's respect the calling of onCopyComplete contract
              hence this approach seems better to me for that reason
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Stephen Connolly Path: core/src/main/java/hudson/model/Job.java http://jenkins-ci.org/commit/jenkins/503c3bd2e6f2ec85514e16a260396ddae68f03ae Log: [FIXES JENKINS-2494] Restore correct behaviour Fixes a regression in core where the display name clear on copy was triggering a save More than one way to do this, could also have used the marker interface approach This route seems slightly less fragile, though people could still add ItemListeners with order == -Double.MAX_VALUE which would then introduce intdeterminism. A marker interface would remove that indeterminism as the onCopyComplete method would be only called on the Job as the last method... but it could be hard to ensure that all ItemGroupMixin's respect the calling of onCopyComplete contract hence this approach seems better to me for that reason
            dogfood dogfood added a comment -

            Integrated in jenkins_main_trunk #2687

            Result = UNSTABLE

            dogfood dogfood added a comment - Integrated in jenkins_main_trunk #2687 Result = UNSTABLE

            People

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

              Dates

                Created:
                Updated:
                Resolved: