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

Published jobs should disable build triggers

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      When the build-publisher transfers a job to the public Hudson instance, the
      entire job configuration is copied verbatim, including the build triggers. This
      is problematic as the published builds still attempt to query the SCM and place
      themselves in the build queue on the public Hudson instance. Provided the job
      is runnable on the public instance, the job will now be run twice! If it is not
      runnable (e.g. tied to a label or node that the public instance doesn't know
      about), then the job will sit in the public instance's build queue indefinitely.

      I think there are two ways to correct this, but neither one is perfect:

      1) add the following to the ExternalProjectProperty.doAcceptBuild() [r18636,
      line 130]:
      for(TriggerDescriptor trigger: project.getTriggers().keySet())

      { project.removeTrigger(trigger); }

      project.save();

      2) use an xml filter to replace the <triggers> element in the job's original
      config.xml with an empty element, before transmitting it to the public
      instance (i.e. in PublisherThread.submitConfig()). [I can provide a patch that
      implements this.]

      The first option has the benefit of being concise and working through the
      standard Hudson core API. However, the job arrives with its build triggers
      intact and is loaded for a brief moment before the private instance transmits
      the build (running doAcceptBuild() and removing the triggers). The second
      option is logically cleaner: it never sends the triggers in the first place, but
      it relies on direct hacking of the config.xml instead of working through the
      Hudson API.

        Attachments

          Activity

          Hide
          vjuranek vjuranek added a comment -

          Hi, I've commit the proposed patch (thanks for the patch again). If the aren't any objections against this solution, I'll do the release next week.

          Show
          vjuranek vjuranek added a comment - Hi, I've commit the proposed patch (thanks for the patch again). If the aren't any objections against this solution, I'll do the release next week.
          Hide
          vjuranek vjuranek added a comment -

          Hi, Build publisher was released. Keeping this JIRA open for case that some problems with this solution appear (not to have create and watch another new JIRA), I'll close it after some time if not problems will be reported.

          Show
          vjuranek vjuranek added a comment - Hi, Build publisher was released. Keeping this JIRA open for case that some problems with this solution appear (not to have create and watch another new JIRA), I'll close it after some time if not problems will be reported.
          Hide
          holywen holywen added a comment -

          It seems one file in the patch is missing:
          Index: src/main/webapp/help/global/remove_triggers.html

          ===================================================================

          — src/main/webapp/help/global/remove_triggers.html (revision 0)

          +++ src/main/webapp/help/global/remove_triggers.html (revision 0)

          @@ -0,0 +1,3 @@

          +<div>

          + If this Hudson instance is working as a Master, the build triggers will be removed on receive.

          +</div>

          Show
          holywen holywen added a comment - It seems one file in the patch is missing: Index: src/main/webapp/help/global/remove_triggers.html =================================================================== — src/main/webapp/help/global/remove_triggers.html (revision 0) +++ src/main/webapp/help/global/remove_triggers.html (revision 0) @@ -0,0 +1,3 @@ +<div> + If this Hudson instance is working as a Master, the build triggers will be removed on receive. +</div>
          Hide
          jacob_robertson Jacob Robertson added a comment -

          We've been using this for a few weeks now and it seems to be working perfectly.

          Show
          jacob_robertson Jacob Robertson added a comment - We've been using this for a few weeks now and it seems to be working perfectly.
          Hide
          jacob_robertson Jacob Robertson added a comment -

          We've been using this for some time now, and have never had a job build accidentally on our "dashboard" hudson instance. I consider this fixed.

          Show
          jacob_robertson Jacob Robertson added a comment - We've been using this for some time now, and have never had a job build accidentally on our "dashboard" hudson instance. I consider this fixed.

            People

            Assignee:
            vjuranek vjuranek
            Reporter:
            jsiirola jsiirola
            Votes:
            9 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: