[JIRA] Commented: (HUDSON-3802) Published jobs should disable build triggers

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[JIRA] Commented: (HUDSON-3802) Published jobs should disable build triggers

Hudson issues mailing list

    [ http://issues.hudson-ci.org/browse/HUDSON-3802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=140403#action_140403 ]

holywen commented on HUDSON-3802:
---------------------------------

It seems that LiangjiChen already posted this patch.
Now we are running build-publisher with this patch for a long time and it seems quite stable.

> Published jobs should disable build triggers
> --------------------------------------------
>
>                 Key: HUDSON-3802
>                 URL: http://issues.hudson-ci.org/browse/HUDSON-3802
>             Project: Hudson
>          Issue Type: Bug
>          Components: build-publisher
>    Affects Versions: current
>         Environment: Platform: All, OS: All
>            Reporter: jsiirola
>            Assignee: vjuranek
>         Attachments: klemett1-created_optional_build_trigger_removal.diff, PATCH
>
>
> 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.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.hudson-ci.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]