[JIRA] (JENKINS-58222) xunit 2.3.4 fails to read xunit 1.102 configs
Title: Message Title Darrel Vuncannon created an issue Jenkins / JENKINS-58222 xunit 2.3.4 fails to read xunit 1.102 configs Issue Type: Bug Assignee: Nikolas Falco Components: xunit-plugin Created: 2019-06-26 19:46 Priority: Major Reporter: Darrel Vuncannon Somewhere between versions 1.102 and 2.3.4 xunit introduced a not-backward-compatible change to reading its config. Steps to reproduce: Install xunit 1.102. Add xunit to a job config, including a tool (such a GoogleTest). Upgrade to xunit 2.3.4. Run the job. Expected Result Job succeeds. Actual Result Job fails with: ERROR: Build step failed with exception java.lang.IllegalArgumentException: The tools section is required. at org.jenkinsci.plugins.xunit.XUnitProcessor.(XUnitProcessor.java:141) at org.jenkinsci.plugins.xunit.XUnitPublisher.perform(XUnitPublisher.java:170) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:81) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:744) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:690) at hudson.model.Build$BuildExecution.post2(Build.java:186) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:635) at hudson.model.Run.execute(Run.java:1835) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceContro
[JIRA] (JENKINS-54590) NPE on CopyArtifact.java line 441 if the job config XML is missing
Title: Message Title Darrel Vuncannon created an issue Jenkins / JENKINS-54590 NPE on CopyArtifact.java line 441 if the job config XML is missing Issue Type: Bug Assignee: ikedam Components: copyartifact-plugin Created: 2018-11-12 17:48 Priority: Major Reporter: Darrel Vuncannon CopyArtifact 1.4.1 will crash with a NullPointerException on CopyArtifact.java line 441 if the job config XML is missing . This is a problem because JJB version =2.0.0.0b3.201803131321 doesn't write that tag if "target: null". This should be easily fixable if we can modify and test the Copy Artifact plugin on Jenkins. The crashing line of code is: if (target.length() > 0) targetDir = new FilePath(targetDir, env.expand(target)); Add Comment
[JIRA] (JENKINS-49658) One JCloud node type can starve another in Jenkins
Title: Message Title Darrel Vuncannon commented on JENKINS-49658 Re: One JCloud node type can starve another in Jenkins Hey Fritz Elfert, Ahmad Bayat, and Vijay Kiran: Last chance before I give up trying to hear from you. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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] (JENKINS-49658) One JCloud node type can starve another in Jenkins
Title: Message Title Darrel Vuncannon edited a comment on JENKINS-49658 Re: One JCloud node type can starve another in Jenkins Hey [~felfert], [~ahmadziabayat], and [~ aakashvijayvergiya vijaykiran ]: This seems like a reasonable enhancement to JCloud -- don't you agree? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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] (JENKINS-49658) One JCloud node type can starve another in Jenkins
Title: Message Title Darrel Vuncannon commented on JENKINS-49658 Re: One JCloud node type can starve another in Jenkins Hey Fritz Elfert, Ahmad Bayat, and aakash vijayvergiya: This seems like a reasonable enhancement to JCloud – don't you agree? Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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] (JENKINS-49658) One JCloud node type can starve another in Jenkins
Title: Message Title Darrel Vuncannon commented on JENKINS-49658 Re: One JCloud node type can starve another in Jenkins Hey Fritz Elfert, Andrew Bayer, and Vijay Kiran: Don't forget me, please. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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] (JENKINS-49658) One JCloud node type can starve another in Jenkins
Title: Message Title Darrel Vuncannon commented on JENKINS-49658 Re: One JCloud node type can starve another in Jenkins Hey Fritz Elfert: Do you have any insight into this? It looks like a significant deficiency to me. (That makes it a bug in the requirements, not the coding!) Hey Andrew Bayer and Vijay Kiran: I'd be curious to hear your opinion too, please. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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] (JENKINS-49658) One JCloud node type can starve another in Jenkins
Title: Message Title Darrel Vuncannon updated an issue Jenkins / JENKINS-49658 One JCloud node type can starve another in Jenkins Change By: Darrel Vuncannon Summary: One JCloud image node type can starve another in Jenkins Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- 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] (JENKINS-49658) One JCloud image type can starve another in Jenkins
Title: Message Title
Darrel Vuncannon updated an issue
Jenkins / JENKINS-49658
One JCloud image type can starve another in Jenkins
Change By:
Darrel Vuncannon
h5. Problem StatementOn a given Jenkins instance, a desired cloud-node type (e.g. Ubuntu) may not spin up for hours because another image cloud-node type (e.g. Win7) has saturated the cloud's quota. {color:darkred}_Due to node retention times, this can happen even if the existing cloud nodes are idle, resulting in wasted computing power!_{color}h5. Steps to Reproduce* Start with an idle Jenkins and idle cloud quota of 10 nodes* Start 10 builds that require Win7 images* Allow each build to run and complete, e.g. 1 hour* Start 1 build that requires Ubuntuh5. Expected Results* The Ubuntu build enters the build queue* An idle Win7 node should be killed and spin up with Ubuntu* Now the cloud quota of 10 is maxed at 9 idle Win7 nodes and 1 running Ubuntu nodeh5. Actual Results* The Ubuntu build enters the build queue* All 10 Win7 nodes continue to stay idle* No Ubuntu node is spun up because the cloud quota is maxed out at 10* The retention time expires after (default) 30 minutes, and the Win7 nodes are killed* An Ubuntu image spins up and starts building the build requested 30 minutes agoWe prefer a long retention time because we're using our private cloud instead of paying for usage from a 3rd party. We want cloud nodes to live a while so we can avoid spin-up time when reused. But we don't want that behavior at the expense of queuing other builds while cloud nodes are idle .
Add Comment
[JIRA] (JENKINS-49658) One JCloud image type can starve another in Jenkins
Title: Message Title Darrel Vuncannon created an issue Jenkins / JENKINS-49658 One JCloud image type can starve another in Jenkins Issue Type: Bug Assignee: Fritz Elfert Components: jclouds-plugin Created: 2018-02-20 18:25 Environment: Jenkins 2.73.2 JCloud 2.14 Priority: Major Reporter: Darrel Vuncannon Problem Statement On a given Jenkins instance, a desired cloud-node type (e.g. Ubuntu) may not spin up for hours because another image type (e.g. Win7) has saturated the cloud's quota. Due to node retention times, this can happen even if the existing cloud nodes are idle, resulting in wasted computing power! Steps to Reproduce Start with an idle Jenkins and idle cloud quota of 10 nodes Start 10 builds that require Win7 images Allow each build to run and complete, e.g. 1 hour Start 1 build that requires Ubuntu Expected Results The Ubuntu build enters the build queue An idle Win7 node should be killed and spin up with Ubuntu Now the cloud quota of 10 is maxed at 9 idle Win7 nodes and 1 running Ubuntu node Actual Results
[JIRA] [throttle-concurrent-builds-plugin] (JENKINS-33940) Throttle plugin "per project" doesn't work with Matrix jobs
Title: Message Title Darrel Vuncannon commented on JENKINS-33940 Re: Throttle plugin "per project" doesn't work with Matrix jobs Thanks, Oleg Nenashev, and let me know if you find anything interesting. I'm scheduled to upgrade Jenkins next month. I'll probably go straight to the latest 1.642.x version. I can recheck then. 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] [throttle-concurrent-builds-plugin] (JENKINS-33940) Throttle plugin "per project" doesn't work with Matrix jobs
Title: Message Title Darrel Vuncannon commented on JENKINS-33940 Re: Throttle plugin "per project" doesn't work with Matrix jobs I read JENKINS-16521 and JENKINS-13619 , but they don't address what I'm seeing. I'm able to reproduce this on my production Jenkins instance and my test Jenkins instance. 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] [throttle-concurrent-builds-plugin] (JENKINS-33940) Throttle plugin "per project" doesn't work with Matrix jobs
Title: Message Title Darrel Vuncannon created an issue Jenkins / JENKINS-33940 Throttle plugin "per project" doesn't work with Matrix jobs Issue Type: Bug Assignee: Oleg Nenashev Attachments: CCI_Adm_Darrel_play_Matrix.xml, screenshot-1.png, screenshot-2.png, screenshot-3.png Components: throttle-concurrent-builds-plugin Created: 2016/Mar/31 1:45 PM Environment: Jenkins 1.609.3, Windows Server 2008, Oracle's JRE 7 update 79 throttle-concurrents 1.8.4 Priority: Major Reporter: Darrel Vuncannon The "per project" throttling is broken for matrix jobs. For testing, I've created a 96 element (12x8) matrix job. It's attached as CCI_Adm_Darrel_play_Matrix.xml. Control Attempt With no throttling, the quantity of concurrent child builds is limited only by my available executors. Attempt #1 Throttling thusly:
[JIRA] [htmlpublisher-plugin] (JENKINS-26343) Workflow integration for HTMLPublisher
Title: Message Title Darrel Vuncannon commented on JENKINS-26343 Re: Workflow integration for HTMLPublisher Oleg: Yes, that helps a lot. Thanks! 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] [htmlpublisher-plugin] (JENKINS-26343) Workflow integration for HTMLPublisher
Title: Message Title Darrel Vuncannon commented on JENKINS-26343 Re: Workflow integration for HTMLPublisher Hey Oleg Nenashev or Jesse Glick or anyone: Question: Does this integration mean that I cannot use HTMLPublisher unless I have Workflow (aka "Pipeline") installed on my Jenkins? I'd like to use it without, if possible. Regards, Darrel Vuncannon SW Configuration Management and Build Tools Team Garmin International 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] [plugin-proposals] (JENKINS-9802) Manage Plugins section should be more informative and User freindly
Title: Message Title Darrel Vuncannon commented on JENKINS-9802 Re: Manage Plugins section should be more informative and User freindly I'm commenting based CloudBees' Jenkins November 2015 Newsletter soliciting input for Jenkins 2.0 My Use Case: I NEVER want to upgrade a plugin to the latest version! My request to you is: Make sure I can easily browse and install specific versions of plugins. Also, help me verify their dependencies without automagically installing the dependency. Background I value stability in my Jenkins. A few times a year, I review the possible updates to our 100+ installed plugins by reading their change-logs and dependencies. I have confidence in the core LTS versions, but practically no plugin has earned my confidence with its latest version. Therefore, I often skip the latest version to avoid risk when my potential benefit is low. I prefer stability for my hundreds of developers. Timing is the other reason I need this feature. After I select my candidate plugin-versions, I test and soak them on a special Jenkins instance at my company, which takes a couple of weeks. When I'm ready to install them on my production instances, I only want the versions I tested. It's possible there's been new versions released since I started testing, but I don't want them. Lastly, it's difficult to manually check the dependencies for a latest plugin version, and it's worse/impossible for a previous version. I use the plugin manager's "Advanced" tab to load the specific version I want, but I understand that this skips automatic dependency checking. We Jenkins users that value stability need dependency checking on old versions too – but don't load a depended upon plugin-version without user confirmation, because I may not have tested it yet. Thanks in advance for your consideration, Darrel Vuncannon SW Configuration Management and Build Tools Team Garmin International Add Comment
[JIRA] [script-security-plugin] (JENKINS-31234) Unable to reference Calendar.instance.get(Calendar.DAY_OF_MONTH) in matrix job's combination filter
Title: Message Title Darrel Vuncannon commented on JENKINS-31234 Re: Unable to reference Calendar.instance.get(Calendar.DAY_OF_MONTH) in matrix job's combination filter Jesse: Thanks for your work around and the fix that I see you committed. As far as I'm concerned, this ticket may be closed. I don't plan to pursue the RFE for matrix-project-plugin, because I don't think my company makes changes there often enough to warrant my time. Thanks again! 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] [script-security-plugin] (JENKINS-31234) Unable to reference Calendar.instance.get(Calendar.DAY_OF_MONTH) in matrix job's combination filter
Title: Message Title Darrel Vuncannon updated an issue Jenkins / JENKINS-31234 Unable to reference Calendar.instance.get(Calendar.DAY_OF_MONTH) in matrix job's combination filter The advised work around in fact works, but it took 2 failed attempts and 2 trips to "in process script approvals" to get it to work. Jesse: thank you for the workaround instructions! There really should be a more graceful way to make this change than getting these exceptions. Darrel's Details I verified the syntax beforehand in Script Console: Here's my config change attempt: Upon clicking save, the resulting exception started: javax.servlet.ServletException: org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use staticMethod java.util.Calendar getInstance at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:796) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) I went to "Manage Jenkins" > "In process Script Approval" and clicked button "Approve". I repeated the test cycle, getting a exception with javax.servlet.ServletException: org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method java.util.Calendar get int Again, "Manage Jenkins" > "In process Script Approval" and click button "Approve". This time, the config loaded (as shown by read-only configuration plugin)! Change By: Darrel Vuncannon Attachment: cci_1747__workaround_config_change.png Attachment: cci_1747__workaround_scriptconsole.png Attachment:
[JIRA] [script-security-plugin] (JENKINS-31234) Unable to reference Calendar.instance.get(Calendar.DAY_OF_MONTH) in matrix job's combination filter
Title: Message Title Darrel Vuncannon created an issue Jenkins / JENKINS-31234 Unable to reference Calendar.instance.get(Calendar.DAY_OF_MONTH) in matrix job's combination filter Issue Type: Bug Assignee: Jesse Glick Attachments: cci_1747__config_w_combo_filter.png, cci_1747__job_xml.txt, cci_1747__plugin_versions.txt, cci_1747__webpage_exception.png Components: script-security-plugin Created: 28/Oct/15 3:04 PM Environment: We're running Jenkins core version LTS 1.596.3 and the plugins listed in attachment "cci_1747__plugin_versions.txt". The master and slaves on Windows Server 2008. Labels: exception configuration Priority: Minor Reporter: Darrel Vuncannon We get an exception in Jenkins when trying to reference Calendar.instance.ge
[JIRA] [compress-build-log-plugin] (JENKINS-29861) compress-build-log doesn't delete file "log" but leaves "log.gz"
Title: Message Title Darrel Vuncannon commented on JENKINS-29861 Re: compress-build-log doesn't delete file "log" but leaves "log.gz" Hey Daniel Beck or Oleg Nenashev: Could I get someone to address this Jira ticket please? Let me know if there's something I need to do. 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] [build-timeout-plugin] (JENKINS-29602) Abort wildly verbose job-runs
Title: Message Title Darrel Vuncannon closed an issue as Won't Fix I'm closing because another plugin seems better suited for this functionality. Jenkins / JENKINS-29602 Abort wildly verbose job-runs Change By: Darrel Vuncannon Status: Open Closed Resolution: Won't 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] [compress-build-log-plugin] (JENKINS-29861) compress-build-log doesn't delete file "log" but leaves "log.gz"
Title: Message Title Darrel Vuncannon updated an issue Jenkins / JENKINS-29861 compress-build-log doesn't delete file "log" but leaves "log.gz" Change By: Darrel Vuncannon I see both "log" and "log.gz" in my file system, but I instead expect only "log.gz".I've installed this on 2 different Jenkins instances and 2 different jobs. One job _consistently_ has this problem; the other does not.Perhaps this is interference with [Log Parser Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Log+Parser+Plugin]? It might have file "log" open for reading while compress-buildlog wants to delete it, therefore the deletion fails. That's pure speculation on my part.Here's a screenshot to prove my point:!cci_1635__log_and_loggz.png|thumbnail! NOTE: I marked this ticket as "Major" because it severely impacts the _plugin_'s main purpose: saving disk space. 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] [compress-build-log-plugin] (JENKINS-29861) compress-build-log doesn't delete file "log" but leaves "log.gz"
Title: Message Title Darrel Vuncannon created an issue Jenkins / JENKINS-29861 compress-build-log doesn't delete file "log" but leaves "log.gz" Issue Type: Bug Assignee: Daniel Beck Attachments: cci_1635__log_and_loggz.png Components: compress-build-log-plugin Created: 07/Aug/15 6:30 PM Environment: Jenkins core 1.596.3 compress-build-log 1.0 Labels: plugin Priority: Major Reporter: Darrel Vuncannon I see both "log" and "log.gz" in my file system, but I instead expect only "log.gz". I've installed this on 2 different Jenkins instances and 2 different jobs. One job consistently has this problem; the other does not. Perhaps this is interference
[JIRA] [build-timeout-plugin] (JENKINS-29602) Abort wildly verbose job-runs
Title: Message Title Darrel Vuncannon commented on JENKINS-29602 Re: Abort wildly verbose job-runs I'll consider Logfilesizechecker Plugin. It troubles me some that it hasn't been widely adopted by the Jenkins community, judging by the low number of installations. I know build-timeout plugin already monitors writing to the console – that's in order to abort a build that seems stuck. Admittedly, my request would enhance the plugin from "timeout" to "build intervention". Thanks for pointing me to the other plugin! 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] [build-timeout-plugin] (JENKINS-29602) Abort wildly verbose job-runs
Title: Message Title Darrel Vuncannon created an issue Jenkins / JENKINS-29602 Abort wildly verbose job-runs Issue Type: New Feature Assignee: Kohsuke Kawaguchi Components: build-timeout-plugin Created: 23/Jul/15 7:32 PM Environment: Build timeout plugin version 1.14 Priority: Minor Reporter: Darrel Vuncannon I have request for feature that you might initially find unusual, but it makes sense: I'd like the option for Build Timeout plugin to abort my job-run if it gets wildly verbose in the log console. (You might even extend that to wildly large and fast artifact generation, but I'm not asking for that.) My specific use case is fairly obvious and really happened. One job owner on my Jenkins instance had his automated unit tests go wrong, and in a few hours' time, its console file consumed the remaining 520 GB of my Jenkins master disk space. The console was merely exception after exception written to stdout. Consequently, Jenkins master would not build, and it had to be shutdown to recover. (You might stress how your plugin makes Jenkins master safer after you implement this!) For the specifics of this request, I'd envision that this feature be independent of the time-out strategy; i.e. regardless of which time-out strategy I pick, I still want this feature too. I'd also envision that it be chec
[JIRA] [build-timeout] (JENKINS-23012) Build-timeout plugin causes builds to slow
Darrel Vuncannon commented on JENKINS-23012 Build-timeout plugin causes builds to slow I might be able to install it over the weekend. And I'll be careful. Thanks for your help with this! I'll be in touch. 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] [build-timeout] (JENKINS-23012) Build-timeout plugin causes builds to slow
Darrel Vuncannon commented on JENKINS-23012 Build-timeout plugin causes builds to slow Wow, great job reproducing the problem! Questions: Do you have any special advice I should pass on to my Jenkins users regarding their behavior to avoid slow builds? What's the next step in getting the fix? And thank you so much for your work on this! 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] [build-timeout] (JENKINS-23012) Build-timeout plugin causes builds to slow
Darrel Vuncannon commented on JENKINS-23012 Build-timeout plugin causes builds to slow I've put my reply in-line with a copy of your questions. My text is dark red to make it easier to follow. Again, thank you for your attention to this. OS of the master node and slave nodes. - Master and slaves are Windows Server 2008 R2 Standard. Outline of your build process. For example, running maven, running gcc, or running other native process. I think whether builds are performed in Java or native processes can affect this problem. - There are 561 defined projects that have built in the past two weeks, so I'll have to generalize. - Our projects are 80 to 90% "free-style software projects", the rest being "multi-configuration projects". - We use Git and Gerrit for source code management, however some projects select "none" and use multiple git repos. - Our build-steps are normally "execute shell" or "execute windows batch command" - Overwhelmingly we use WAF for building C/C++ source files; that's both with licensed compilers and "free" compilers. - For authorization, we use "project-based Matrix Authorization Strategy" with 40 defined users plus anonymous. Some projects also enable project-based security. How much log outputs? I think the size of whole log and the time builds take will be helpful. I think much log outputs may trigger the problem. - Quick survey says... 20,000 to 40,000 lines of text for our most popular projects. - These builds average 25 to 50 minutes; strangely, the quicker projects tend to generate more logs. Can you see what process gets slow in builds? If building processes outputs timestamps, please compare them before and after downgrading build-timeout plugin. If you installed Timestampler plugin, please compare timestamps in console outputs. Timestamps logged with timestampler-plugin may differ from the activity of the building process as they can be buffered and delayed. If you don't have timestamper-plugin installed, you'd better not install that as that plugin also captures log output and may cause the same problem. - Plugin timestamper is installed, but only some projects use it. However, the builds in question are no longer saved because they're so long ago, therefore I cannot examine them with the timestamps. - I do have some data captured in a database about those builds. That's data like job-name, build-number, result, build-duration, and interestingly, excerpts from the logs for failed/aborted 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/d/optout.
[JIRA] [build-timeout] (JENKINS-23012) Build-timeout plugin causes builds to slow
Darrel Vuncannon commented on JENKINS-23012 Build-timeout plugin causes builds to slow No, I cannot subject my employer's production jenkins to this problem again because that would impact hundreds of developers. That's unfortunate, because I know you need a place to investigate this problem. Can you think of another way to proceed? If you think you know the problem and can generate a version that you think is 70% likely to fix this problem, then I will risk my jenkins instance on trying it. 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] [build-timeout] (JENKINS-23012) Build-timeout plugin causes builds to slow
Darrel Vuncannon created JENKINS-23012 Build-timeout plugin causes builds to slow Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: build-timeout Created: 13/May/14 9:11 PM Description: Upon upgrading plugin "build-timeout" from 1.12.2 to 1.13, all builds took about 50% longer to complete. This resulted in an unacceptably long build queue and builds timing out. This continued for 6 or 7 hours until an emergency downgrade of "build-timeout" from 1.13 back to 1.12.2 was done, which cleared the problem immediately. No other plugins were upgraded or downgraded during this time, nor were any other system wide configuration changes made. I suspect the use of "synchronized" in the source code change made writing to the console effectively single threaded for all running builds. (My jenkins instance has 125 slave-nodes, so I have several dozens of concurrent builds all the time.) Priority: I've made this "Major" because a mere install this plugin version causes my Jenkins instance to be unusable due to slower builds which cause a growing build queue and timed-out builds. Environment: I'm running Jenkins core LTS 1.532.2 version. I'll be glad to furnish more information as you request it. Environment: Jenkins core 1.532.2 Build-timeout plugin 1.13 Project: Jenkins Labels: plugin performance Priority: Major Reporter: Darrel Vuncannon 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.
