[JIRA] [core] (JENKINS-9913) Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
Title: Message Title Jesse Glick commented on JENKINS-9913 Re: Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent Eric Cooper there are distinct issues for various plugins. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-9913) Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
Title: Message Title Eric Cooper commented on JENKINS-9913 Re: Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent My apologies if this is the wrong please to ask this but I really did look for the right place and couldn't find it - is there a schedule for when this fix will be released? I am running into this issue and would benefit from the fix. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-9913) Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
SCM/JIRA link daemon commented on JENKINS-9913 Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent Code changed in jenkins User: Tim-Clifford Path: src/main/java/jenkins/plugins/slack/ActiveNotifier.java http://jenkins-ci.org/commit/slack-plugin/832e7b50028ca086dd49311ce454e7a19c9a3af9 Log: Change .getPreviousBuild() to allow for higher concurrency Jenkins changed getPreviousBuild() to halt jobs if a previous build hasn't finished, meaning jobs of variable runtime end up being serialized: https://issues.jenkins-ci.org/browse/JENKINS-9913?focusedCommentId=184188page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-184188 This change switches to the latest completed build, allowing this plugin to work with jobs of variable length. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-9913) Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
M S commented on JENKINS-9913 Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent To resolve this problem use xplugin as an intermediary to nunit/junit. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-9913) Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
Not Again commented on JENKINS-9913 Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent Got bitten by the same thing. Now planning to move the post build stuff into an additional last step of the build job. Only problem is that I need to get data from the slave to master before that. And that is also a Post build action (I use Copy-To-Slave plugin). Any way I can do it as a part of build job only? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-9913) Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
Byron Brummer commented on JENKINS-9913 Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent I have to wholeheartedly agree with surya et al: There needs to be a (non-plugin) switch for this. Perhaps not a global switch (although, why not?), but at an absolute minimum a per-job switch. This is a Jenkins-wide issue and giving plugins enough rope to hang the users does not strike me as the best process. The only "workaround" really is to throw out the entire Post-Build functionality and recreated it from whole cloth as Build Steps. That is really what this bug means: The entire Post-Build feature must be considered suspect and unreliable. At the very minimum there should be a huge user warning around the Concurrent Build check box telling users that Post-Build actions may likely serialize their jobs anyway and should be avoided. It should also be noted that Jenkins jobs are leveraged for MUCH more than simply "pulling code from an SCM and compiling it" type jobs. There are a huge number of utility tasks around a typical development lifecycle (deployments, environment setups and refreshes, data jobs, etc) that fit very well into Jenkins. In the real world I see such utility jobs far, far outnumber "real" build jobs. I mention this because of all the debate above about Git vs Subversion workflows and the like: It doesn't matter...in real world Jenkins usage it's common to find that MOST jobs aren't calling SCM at all because they aren't "buliding" anything, rendering all such workflow debates mute. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-9913) Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
Jesse Glick commented on JENKINS-9913 Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent Build step monitors are an aspect of any build step, including both “builders” and “post-build steps” (recorders and notifiers), so that is an artificial distinction. Prior to the introduction of concurrent builds, plugins were free to assume that a build with a lower number than the current one was in fact completed—and some did in fact make that assumption. Monitors were introduced to ensure full binary compatibility. All plugins with build steps need to be updated to specify the monitor style they actually require, which is usually none. This has to be done on a case-by-case basis, while reviewing the plugin code for calls such as getPreviousBuild and ensuring that the logic continues to make sense when this build might be finishing well before earlier builds. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-9913) Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent
Jesse Glick updated JENKINS-9913 Not obvious why some post-build tasks enforce serial behavior even when builds are concurrent Not a bug per se, but Jenkins needs to make sure that post-build actions which require the previous build to be complete (a) are documented to do so, e.g. in inline help; (b) print a helpful message to the build log when waiting for a previous build. And of course wherever feasible, offer an option to not block in this way, or to perform the processing dependent on the previous build asynchronously, e.g. in a RunListener. Change By: Jesse Glick (26/Jul/13 5:55 PM) Summary: Concurrentbuildsgettingbatched/nodesnotgettingreleased Notobviouswhysomepost-buildtasksenforceserialbehavioreven when jobs builds are completed concurrent Labels: concurrent-buildjunit Assignee: KohsukeKawaguchi JesseGlick Priority: Blocker Major Component/s: core Component/s: concurrent-build This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
