[JIRA] [coverity] (JENKINS-17467) CoverityPublisher aborted due to NullPointerException
Loren Keagle commented on JENKINS-17467 CoverityPublisher aborted due to NullPointerException I've been informed that this was fixed a month ago in plugin revision 1.3.1. Does anyone know why there would be a holdup on releasing it to the Jenkins plugin repository? 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] [coverity] (JENKINS-17467) CoverityPublisher aborted due to NullPointerException
Loren Keagle commented on JENKINS-17467 CoverityPublisher aborted due to NullPointerException I'm still having this issue in 1.554: Archiving artifacts ERROR: Publisher jenkins.plugins.coverity.CoverityPublisher aborted due to exception java.lang.NullPointerException at jenkins.plugins.coverity.analysis.CoverityToolHandler.getHandler(CoverityToolHandler.java:44) at jenkins.plugins.coverity.CoverityPublisher.perform(CoverityPublisher.java:233) at hudson.tasks.BuildStepMonitor$2.perform(BuildStepMonitor.java:32) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:725) at hudson.model.Run.execute(Run.java:1701) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Has there been any update from Coverity support on their internal issue? I can't seem to find that issue visible in any web searches. Is this really a bug that can only be fixed by Coverity? Is the only workaround at this point to disable the Coverity plugin completely? I perform all of my analysis from within my msbuild scripts, so we're only using the plugin for visualization of issues posted to the server. 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] (JENKINS-7813) Archiving artifacts very slow
Loren Keagle commented on JENKINS-7813 Archiving artifacts very slow I see this same slowness when archiving artifacts just on the master. Final output of our build sequence generates ISO images with our installers and tools, and archiving these files takes ages. No master/slave setup, same hard disk... Agonizingly slow. This would take only a minute or two if I were fingerprinting and copying the files manually. 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] (JENKINS-15652) All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs
Loren Keagle commented on JENKINS-15652 All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs Pascal, from what I recall, those two settings are supposed to be mirrored by design. I've never tried it, but the documentation led me to believe that changing that setting in an upstream project automatically changed the corresponding setting in the downstream project. i.e. you can't disable it in one without disabling it in the other. Is there anything else you did to your configuration while you were resolving your issue? 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
[JIRA] (JENKINS-15652) All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs
Loren Keagle commented on JENKINS-15652 All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs I can confirm that removing all build history seems to stabilize the system. I noticed that I had an assortment of items in my build history. Some jobs had each build in a directory based on its build number. Some had build directories that were timestamped. Some were timestamped, but also had a symbolic link named after the build number, but pointing to a timestamp directory. I also manually deleted all of the lastBuilt and lastFailed links in the job directories. Nothing has failed since, but it sucks that I have to rebuild every job in order to turn all those little circles from gray to green again. So it seems as though there's some assumptions being made regarding the layout and naming conventions of build output directories. I don't know if it's due to a combination of plugins or the base Jenkins code not cleaning up after itself. I guess it could be related to clocks and DST, but I'm pretty sure my problems started before we jumped forward. 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
[JIRA] (JENKINS-15652) All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs
Loren Keagle commented on JENKINS-15652 All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs I'm seeing a similar stack trace randomly. I can generally restart Jenkins and everything will be find for another day or so. Running 1.489 on Windows Server 2008, all 64 bit. Here's a snippet of the failure from the build log: Time Elapsed 00:04:10.80 Build step 'Build a Visual Studio project or solution using MSBuild' marked build as failure locks-and-latches Releasing all the locks locks-and-latches All the locks released Archiving artifacts Recording test results Processing tests results in file(s) BinaryFiles/Exe/*/_results.trx BinaryFiles\Exe\Win32\Debug\UnitTests\gui\test_results.trx BinaryFiles\Exe\Win32\Release\UnitTests\gui\test_results.trx Description set: ERROR: Publisher hudson.tasks.Mailer aborted due to exception java.lang.ArrayIndexOutOfBoundsException: Assertion error: failing to load #94 EXACT: lo=8,hi=0,size=9,size2=9 at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:418) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:502) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:355) at jenkins.model.lazy.AbstractLazyLoadRunMap.newestBuild(AbstractLazyLoadRunMap.java:297) at hudson.model.AbstractProject.getLastBuild(AbstractProject.java:1015) at hudson.model.AbstractProject.hasParticipant(AbstractProject.java:1514) at hudson.model.User.getProjects(User.java:444) at hudson.scm.MailAddressResolverImpl.findMailAddressFor(MailAddressResolverImpl.java:21) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:530) at hudson.tasks.MailSender.buildCulpritList(MailSender.java:407) at hudson.tasks.MailSender.createEmptyMail(MailSender.java:367) at hudson.tasks.MailSender.createFailureMail(MailSender.java:226) at hudson.tasks.MailSender.getMail(MailSender.java:153) at hudson.tasks.MailSender.execute(MailSender.java:99) at hudson.tasks.Mailer.perform(Mailer.java:115) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:779) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726) at hudson.model.Run.execute(Run.java:1541) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Finished: FAILURE 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
[JIRA] (JENKINS-14693) Conditional BuildStep Fails Build with NullPointerException
Loren Keagle created JENKINS-14693 Conditional BuildStep Fails Build with NullPointerException Issue Type: Bug Affects Versions: current Assignee: domi Components: conditional-buildstep Created: 06/Aug/12 5:40 PM Description: I set up a conditional build step to run a 'Clean' target once a week on our nightly build. The night following the successful clean failed with a NullPointerException: Exception caught evaluating condition: java.lang.NullPointerException: null, action = "" class="error">Fail the build Build step 'Conditional step (single)' changed build result to FAILURE Build step 'Conditional step (single)' marked build as failure locks-and-latches Releasing all the locks locks-and-latches All the locks released Archiving artifacts I have not been able to initiate a successful build since this first occurred. The same error prevents all subsequent tasks from initiating. Environment: Windows Server 2008R2, Jenkins 1.476, Conditional BuildStep plugin 1.1 Project: Jenkins Priority: Major Reporter: Loren Keagle 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
[JIRA] (JENKINS-3991) Svn tagging by module
Loren Keagle commented on JENKINS-3991 Svn tagging by module I have a similar issue. We have a job that performs an svn checkout of a project, along with a handful of additional checkouts for other resources. svn-tag plugin goes through each checkout and overwrites the previous tag with the url of each checkout. The result is that our tag does not contain the source code for the main project, but rather whatever url was tagged last. We need to be able to selectively tag each individual checkout with its own path, AND to disable tagging on checkouts that do not need to be tagged. 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
