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