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

Published jobs should disable build triggers

    XMLWordPrintable

Details

    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

          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.

          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.
          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.

          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.
          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>

          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>

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

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

          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.

          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

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

            Dates

              Created:
              Updated:
              Resolved: