-
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
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? 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. vjuranek
added a comment - Thanks for the patch. However, this patch has the disadvantage as was originally pointed out by jsiirola that the build triggers are loaded for some time before they are removed. On the other hand, I haven't figured out any better solution so far as the loading of triggers is implemented in Hudson core and can be hardly changed. I'll post this problem on Hudson dev list and if nobody propose any better solution, I'll probably used this one.
vjuranek
added a comment - Thanks for the patch. However, this patch has the disadvantage as was originally pointed out by jsiirola that the build triggers are loaded for some time before they are removed. On the other hand, I haven't figured out any better solution so far as the loading of triggers is implemented in Hudson core and can be hardly changed. I'll post this problem on Hudson dev list and if nobody propose any better solution, I'll probably used this one. jsiirola
added a comment - FWIW, a recent Hudson release (1.361 I think) automatically disables copied jobs (that is, new jobs based on an existing job) until after the edited configuration is saved by the user. You may be able to use the same logic for this plugin (under the theory that if it is close enough for the core, it is close enough for us).
jsiirola
added a comment - FWIW, a recent Hudson release (1.361 I think) automatically disables copied jobs (that is, new jobs based on an existing job) until after the edited configuration is saved by the user. You may be able to use the same logic for this plugin (under the theory that if it is close enough for the core, it is close enough for us). vjuranek
added a comment - yes, this is (resolved) JENKINS-2494. Unfortunately, I still have had no time to look at it, if it will be useful for this plugin as well. But I hope, that it will be possible (and hope that I will look at it in near future).
vjuranek
added a comment - yes, this is (resolved) JENKINS-2494 . Unfortunately, I still have had no time to look at it, if it will be useful for this plugin as well. But I hope, that it will be possible (and hope that I will look at it in near future). My organization is evaluating Sonar, and as part of that evaluation I would like to mention this plugin as an attractive alternative that meets our needs without having to maintain a separate technology and installation. However, this issue is a complete show stopper for us. It seems like any organization that makes heavy use of triggers (isn't that everyone?), and would not want their triggers to be triggered twice (again - everyone?) would not be able to make use of this plugin until this issue is resolved. In addition to the original intent of this issue, I would mention that for organizations that are looking for this kind of "aggregated dashboard" behavior, then it would be preferable if this plugin were to somehow mark these jobs as "read only" such that they weren't configurable or buildable (manually or through trigger). Which isn't to say that all jobs on the "dashboard" hudson would be disabled - just the ones that are being published by "client" hudsons.
For me, I feel that an imperfect patch that gets things working in a new release would be great, and if later it was revisited to provide the correct solution that's good too. If I'm understanding the limitation of the proposed patch, I have no problem with the triggers being "temporarily" live since the vast majority of our triggers are nightly.
Jacob Robertson
added a comment - - edited My organization is evaluating Sonar, and as part of that evaluation I would like to mention this plugin as an attractive alternative that meets our needs without having to maintain a separate technology and installation. However, this issue is a complete show stopper for us. It seems like any organization that makes heavy use of triggers (isn't that everyone?), and would not want their triggers to be triggered twice (again - everyone?) would not be able to make use of this plugin until this issue is resolved. In addition to the original intent of this issue, I would mention that for organizations that are looking for this kind of "aggregated dashboard" behavior, then it would be preferable if this plugin were to somehow mark these jobs as "read only" such that they weren't configurable or buildable (manually or through trigger). Which isn't to say that all jobs on the "dashboard" hudson would be disabled - just the ones that are being published by "client" hudsons.
For me, I feel that an imperfect patch that gets things working in a new release would be great, and if later it was revisited to provide the correct solution that's good too. If I'm understanding the limitation of the proposed patch, I have no problem with the triggers being "temporarily" live since the vast majority of our triggers are nightly. Jacob Robertson
added a comment - A few more thoughts:
Disabling copied builds is a little less useful to me, because a disabled build shows the status as Grey instead of red/yellow/blue.
I am playing with this now, and I note that when the client hudson and master hudsons both have triggers going off (or manual actually too), the build number generated by the client means it overrides the build on the master. So, allowing builds (triggered or manual) on the master really doesn't make any sense.
I've just started looking at the hudson.model.Queue.QueueDecisionHandler and thinking about whether that would be one way to prevent builds from taking place. Since it's an extension point, it would automatically hook into the schedule vetoers. This might be just another workaround, since it wouldn't tell the user why their manual builds weren't doing anything, but it might be a clean way of stopping triggered builds from going into the queue.
Jacob Robertson
added a comment - A few more thoughts:
Disabling copied builds is a little less useful to me, because a disabled build shows the status as Grey instead of red/yellow/blue.
I am playing with this now, and I note that when the client hudson and master hudsons both have triggers going off (or manual actually too), the build number generated by the client means it overrides the build on the master. So, allowing builds (triggered or manual) on the master really doesn't make any sense.
I've just started looking at the hudson.model.Queue.QueueDecisionHandler and thinking about whether that would be one way to prevent builds from taking place. Since it's an extension point, it would automatically hook into the schedule vetoers. This might be just another workaround, since it wouldn't tell the user why their manual builds weren't doing anything, but it might be a clean way of stopping triggered builds from going into the queue. vjuranek
added a comment - Thanks for comments. A few points: not sure, why this issue is complete stopper for you - removing trigger via Groovy script works fine (see David's comment above). I'm not aware of any Hudson feature to mark jobs as read only - remove the right to configure/build the project should be sufficient. However, both can be done only if you are publishing Hudson builds on Hudson instance dedicated for publishing builds, but I would expect such dedicated instance.
Agree that disabling the projects is not a good solution (moreover has the same disadvantage as removing the triggers).
I'm afraid that any patch which utilizes QueueDecisionHandler is not a perfect solution as the published job will run e.g. SCM polling, which is not acceptable (at least for us) on public Hudson.
Currently I'm investigating if same approach as in JENKINS-2494 can be used, but it seems to me, that it won't be possible without other changes in Hudson core. As I wrote in my previous comment, if I don't find a good solution in some near future, I'll use the imperfect one discussed above - i.e. this should be (somehow) solved within one month or so.
vjuranek
added a comment - Thanks for comments. A few points: not sure, why this issue is complete stopper for you - removing trigger via Groovy script works fine (see David's comment above). I'm not aware of any Hudson feature to mark jobs as read only - remove the right to configure/build the project should be sufficient. However, both can be done only if you are publishing Hudson builds on Hudson instance dedicated for publishing builds, but I would expect such dedicated instance.
Agree that disabling the projects is not a good solution (moreover has the same disadvantage as removing the triggers).
I'm afraid that any patch which utilizes QueueDecisionHandler is not a perfect solution as the published job will run e.g. SCM polling, which is not acceptable (at least for us) on public Hudson.
Currently I'm investigating if same approach as in JENKINS-2494 can be used, but it seems to me, that it won't be possible without other changes in Hudson core. As I wrote in my previous comment, if I don't find a good solution in some near future, I'll use the imperfect one discussed above - i.e. this should be (somehow) solved within one month or so. Jacob Robertson
added a comment - If I can resign myself to one "dashboard" Hudson where no builds are ever performed, then using the groovy solution and security together should give me exactly what I want. I guess I had some jobs I still wanted to run on that instance, but the more I think about it that probably isn't a hard requirement.
Jacob Robertson
added a comment - If I can resign myself to one "dashboard" Hudson where no builds are ever performed, then using the groovy solution and security together should give me exactly what I want. I guess I had some jobs I still wanted to run on that instance, but the more I think about it that probably isn't a hard requirement. 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.
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.
Code changed in hudson
User: : vjuranek
Path:
trunk/hudson/plugins/build-publisher/src/main/java/hudson/plugins/build_publisher/BuildPublisher.java
trunk/hudson/plugins/build-publisher/src/main/java/hudson/plugins/build_publisher/ExternalProjectProperty.java
trunk/hudson/plugins/build-publisher/src/main/resources/hudson/plugins/build_publisher/BuildPublisher/global.jelly
http://jenkins-ci.org/commit/33375
Log:
Added option to remove triggers from published builds - JENKINS-3802 (not completely perfect, see the discussion, but probably best what we have so far)
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
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
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
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. 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>
Jacob Robertson
added a comment - We've been using this for a few weeks now and it seems to be working perfectly.
Jacob Robertson
added a comment - We've been using this for a few weeks now and it seems to be working perfectly. 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.
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. 
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?