-
Bug
-
Resolution: Fixed
-
Major
-
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.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.
[JENKINS-3802] Published jobs should disable build triggers
jsiirola
created issue -
jsiirola
added a comment - I might be able to get away with adding "hudson.triggers.Trigger.timer.cancel()"
to the public instance init.groovy for the time being. The problem is that it
precludes using the public instance to host any strictly-public jobs (not only
public builds of publicly-hosted SCMs, but also "infrastructure" jobs like
bookkeeping, monitoring, summarizing or notification).
That said, I still think that native support for removing the build triggers on
published jobs (even if it has known and documented flaws) would be "a good
thing" for the plugin: that way, the default out-of-the-box behavior is closer
to what a user might expect.
I would also recommend documenting the timer.cancel() workaround on the
build-publisher wiki...
jsiirola
added a comment - I might be able to get away with adding "hudson.triggers.Trigger.timer.cancel()"
to the public instance init.groovy for the time being. The problem is that it
precludes using the public instance to host any strictly-public jobs (not only
public builds of publicly-hosted SCMs, but also "infrastructure" jobs like
bookkeeping, monitoring, summarizing or notification).
That said, I still think that native support for removing the build triggers on
published jobs (even if it has known and documented flaws) would be "a good
thing" for the plugin: that way, the default out-of-the-box behavior is closer
to what a user might expect.
I would also recommend documenting the timer.cancel() workaround on the
build-publisher wiki... 
olorijn
added a comment - It'll also replace any configuration on the public server with the same name,
with the one on the private server. This was totally unexpected behaviour.
The description of the plugin makes it sound as if it just copies the results of
a build, not the complete configuration, overwriting any existing config.
olorijn
added a comment - It'll also replace any configuration on the public server with the same name,
with the one on the private server. This was totally unexpected behaviour.
The description of the plugin makes it sound as if it just copies the results of
a build, not the complete configuration, overwriting any existing config. 
dvrzalik
added a comment - Well, the reasoning behind this is that you need the original configuration for
displaying the build result properly. Perhaps it should be stated clearly on the
wiki page. Why do you need to change job configuration on the public instance?
dvrzalik
added a comment - Well, the reasoning behind this is that you need the original configuration for
displaying the build result properly. Perhaps it should be stated clearly on the
wiki page. Why do you need to change job configuration on the public instance? dvrzalik
made changes -
| Assignee | Original: dvrzalik [ dvrzalik ] | New: vjuranek [ vjuranek ] |
I also hope to publish just only the result of private hudson's job.
Because I have some hudson which can't connect directly but want to monitor build status a single hudson.
I thought it sounds great if I can make an public hudson as a aggregator of my own hudsons...
vjuranek
added a comment - Hi, is there any reason why you need copying results only? As David has already pointed out, proper job configuration is mandatory to show the results properly. Currently I have no idea how to workaround this and publish only the results.
vjuranek
added a comment - Hi, is there any reason why you need copying results only? As David has already pointed out, proper job configuration is mandatory to show the results properly. Currently I have no idea how to workaround this and publish only the results. 
LiangjiChen
added a comment - We added an option to remove job triggers. If select to remove, the Public Hudson will not trigger new builds automatically.
LiangjiChen
added a comment - We added an option to remove job triggers. If select to remove, the Public Hudson will not trigger new builds automatically. LiangjiChen
made changes -
| Attachment | New: PATCH [ 19563 ] |
I used to update the job's XML for some reason in the past but then I managed to
). The other
avoid that and I'd prefer not to do it again (it's just ugly
option is a bit prettier but you are right: there is a small time frame when the
job is already loaded and the triggers are yet to be deleted, thus it isn't 100%
reliable.
Here is what I suggest to do: call "hudson.triggers.Trigger.timer.cancel()" in
the system console or in the init.groovy script. Your public Hudson will never
try to trigger a build again. Does this sound viable?