[JIRA] Updated: (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] Updated: (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:all-tabpanel ]

holywen updated HUDSON-3802:

    Attachment: klemett1-created_optional_build_trigger_removal.diff

One of my colleague created this patch to fix this issue.
An option for remove the build trigger was added in the global configuration page (default is not removed).So the default behavior is not changed.

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