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

Published jobs should disable build triggers



    • Bug
    • Resolution: Fixed
    • Major
    • build-publisher-plugin
    • None
    • Platform: All, OS: All


      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); }


      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.




            vjuranek vjuranek
            jsiirola jsiirola
            9 Vote for this issue
            7 Start watching this issue