[JIRA] (JENKINS-57736) SiteMonitor jobs fail if not re-saved after latest update
Title: Message Title Marc Esher created an issue Jenkins / JENKINS-57736 SiteMonitor jobs fail if not re-saved after latest update Issue Type: Bug Assignee: Francisco Hernandez Suarez Components: sitemonitor-plugin Created: 2019-05-29 11:45 Environment: Jenkins LTS 2.164.2 on Linux Priority: Minor Reporter: Marc Esher After installing the most recent SiteMonitor plugin, all of our jobs that use SiteMonitor began failing with a null pointer exception. I didn't see any meaningful output in jenkins.log. Here's all I see in the console output for a job build: java.lang.NullPointerException - null URL: http://google.com, response code: null, status: EXCEPTION I assume this is because any existing jobs do not have the setting for the new cert-related checkbox, and under the hood the code doesn't handle this condition. Consequently, all jobs using SiteMonitor must be resaved. This isn't ideal if you have a lot of SiteMonitor jobs across a lot of servers. Any chance you could add a null check in the code and release a new version? Or, if you're willing to accept a n00b contribution, I'm happy to take a crack at it myself. Thanks! We've been using the SiteMonitor plugin for years and it's served extremely well. I really appreciate all the (free) work you put in to maintaining a plugin.
[JIRA] (JENKINS-25046) Cookie header too long, causing a 413 HTTP error
Title: Message Title Marc Esher commented on JENKINS-25046 Re: Cookie header too long, causing a 413 HTTP error Definitely a problem for us. We run jenkins behind nginx, and for various reasons, we're required to have a fairly strict setting on cookie size, which means this problem hits our users every week or two. It's incredibly annoying. I'd be happy to submit a PR for the behavior requested above if the Jenkins folks think it'd be accepted Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-38785) "Send separate e-mails to individuals who broke the build" is sending to the "Jenkins" user
Title: Message Title Marc Esher updated an issue Jenkins / JENKINS-38785 "Send separate e-mails to individuals who broke the build" is sending to the "Jenkins" user Change By: Marc Esher In our Jenkins, we have a user named "jenkins"We have jobs that use the mailer plugin to send emails.On those jobs, if we select "Send separate e-mails to individuals who broke the build", we notice that intermittently, build failures builds on those jobs will attempt to send emails to the email address for that "jenkins" user, even though that user is not configured to receive emails in the job configuration. I have seen this on builds that fail and that succeed. It's almost as if the detection for "who broke the build" is identifying the jenkins user as a culprit and deciding to send that user email. I can find no evidence, though, that the jenkins user is responsible for breaking these builds. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are
[JIRA] (JENKINS-38785) "Send separate e-mails to individuals who broke the build" is sending to the "Jenkins" user
Title: Message Title Marc Esher created an issue Jenkins / JENKINS-38785 "Send separate e-mails to individuals who broke the build" is sending to the "Jenkins" user Issue Type: Bug Assignee: Unassigned Components: mailer-plugin Created: 2016/Oct/06 1:09 PM Environment: RHEL Linux, Jenkins LTS version 2.7.4 Priority: Minor Reporter: Marc Esher In our Jenkins, we have a user named "jenkins" We have jobs that use the mailer plugin to send emails. On those jobs, if we select "Send separate e-mails to individuals who broke the build", we notice that intermittently, build failures on those jobs will attempt to send emails to the email address for that "jenkins" user, even though that user is not configured to receive emails in the job configuration. It's almost as if the detection for "who broke the build" is identifying the jenkins user as a culprit and deciding to send that user email. I can find no evidence, though, that the jenkins user is responsible for breaking these builds. Add Comment
[JIRA] (JENKINS-37188) 2nd failure emails being sent even when build is successful with job-dsl-plugin
Title: Message Title Marc Esher commented on JENKINS-37188 Re: 2nd failure emails being sent even when build is successful with job-dsl-plugin Thanks David! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37188) 2nd failure emails being sent even when build is successful
Title: Message Title Marc Esher commented on JENKINS-37188 Re: 2nd failure emails being sent even when build is successful Hi David, I believe I've gotten to the bottom of this. I'm not sure what the exact right fix is, because it seems there might be several. Bear with me, this might take a while: We use job-dsl-plugin to configure our jobs. And when I added a secondFailure trigger via job-dsl-plugin, that's when I observed the behavior I described. If I then re-saved the job in the Jenkins UI, the problem went away. This led me to investigate the difference in config.xml between the job-dsl generated version and the JenkinsUI generated version, and it was this: in the job-dsl generated job, I saw: "0" for the SecondFailureTrigger element. But in the Jenkins UI generated job, I saw "2" for the SecondFailureTrigger element. I then added some debugging to the email-ext and uploaded, and saw that in https://github.com/jenkinsci/email-ext-plugin/blob/master/src/main/java/hudson/plugins/emailext/plugins/trigger/NthFailureTrigger.java#L35-L53, because failureCount was 0, then that entire loop was skipped, and it'd hit the last line: return run == null || run.getResult() == Result.SUCCESS || run.getResult() == Result.UNSTABLE; And since the result was SUCCESS, it'd return true, and the email would get triggered. So there are 2 problems: 1) for some reason, the job-dsl version generates a failureCount of 0, which causes the for loop to get skipped 2) the return seems, to me, to have incorrect logic. I can't figure out why it'd return true if the result was SUCCESS. So to fix this, I noticed that FirstFailureTrigger has a readResolve() block that seems to cover this exact condition. Thus, I added a readResolve() block to SecondFailureTrigger, just replacing "1" with "2" Re-uploaded the plugin, and that fixed everything. So to me, that seems like a sensible fix and I'm happy to submit a PR if you think that's correct. Still, though, that return in trigger() seems off to me, so you probably want to check that out. If you think the logic should be Result.FAILURE instead of Result.SUCCESS, let me know and I can add that to the PR Add Comment
[JIRA] (JENKINS-37188) 2nd failure emails being sent even when build is successful
Title: Message Title Marc Esher created an issue Jenkins / JENKINS-37188 2nd failure emails being sent even when build is successful Issue Type: Bug Assignee: David van Laatum Components: email-ext-plugin Created: 2016/Aug/04 7:29 PM Environment: Jenkins 2+, running on linux Priority: Minor Reporter: Marc Esher I have just configured some jobs to send emails on "Failure - 2nd" and "Fixed". The behavior I'm seeing is that if the job has ever failed in the past, then the "Failure - 2nd" email gets sent on every subsequent build, even if the build is successful. Here's the output I see in Jenkins: Email was triggered for: Failure - 2nd Trigger Failure - Any was overridden by another trigger and will not send an email. Trigger Failure - Still was overridden by another trigger and will not send an email. Sending email for trigger: Failure - 2nd Sending email to: .. Finished: SUCCESS The expected behavior, according to the plugin doc, is that it would only be sent on successive failures. Note that this build is neither a failure, nor a successive failure.
[JIRA] (JENKINS-31118) Workflow jobs that are waiting for input should have a visual cue in build history
Title: Message Title Marc Esher commented on JENKINS-31118 Re: Workflow jobs that are waiting for input should have a visual cue in build history Big +1 on this. Right now, it's very hard to tell when something is waiting on input unless you know exactly what you're looking for. Making it more obvious / prominent would be a big UX win. Related, I had a job that kicked off, and we didn't know it was waiting on input. Several days later, the thing is still waiting, and then it wouldn't abort or proceed when we clicked the links, no matter how many times. The job would not cancel, either. The only thing that cleared out its cobwebs was a Jenkins restart. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36224) Environment variables not visible / linked for pipeline jobs
Title: Message Title Marc Esher created an issue Jenkins / JENKINS-36224 Environment variables not visible / linked for pipeline jobs Issue Type: Bug Assignee: Manuel Recena Soto Components: workflow-multibranch-plugin, workflow-plugin Created: 2016/Jun/25 6:52 PM Environment: Jenkins 2.10 Priority: Minor Reporter: Marc Esher In other job types, for a given build, if the EnvInject plugin is installed then "Environment variables" shows up as a link on the left sidebar. In addition, if Build Environment plugin is installed, it'll add a "Compare Environment" link to builds that lets you easily compare environment variables across builds. Both of these are very useful for troubleshooting build problems, but they're missing from Pipeline jobs. Not sure if this is something about Pipeline plugins themselves, or if those two plugins need to be updated to support pipeline jobs. Add Comment
[JIRA] (JENKINS-36078) Should the pipeline screen show just pipeline jobs, or all jobs?
Title: Message Title Marc Esher commented on JENKINS-36078 Re: Should the pipeline screen show just pipeline jobs, or all jobs? Roger that. Thanks again for the explanation and conversation, Michael. I'll close this now since the original question's been answered. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36078) Should the pipeline screen show just pipeline jobs, or all jobs?
Title: Message Title Marc Esher resolved as Not A Defect Jenkins / JENKINS-36078 Should the pipeline screen show just pipeline jobs, or all jobs? Change By: Marc Esher Status: Open Resolved Resolution: Not A Defect Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36078) Should the pipeline screen show just pipeline jobs, or all jobs?
Title: Message Title Marc Esher commented on JENKINS-36078 Re: Should the pipeline screen show just pipeline jobs, or all jobs? Thanks for the response, Michael. That makes sense. I don't really have any strong opinions on what it should be, and I Am Not a UXer I will describe our current reality at work, and see what you all think that might look like in blue-ocean world. We have hundreds of jobs. Maybe half of those jobs are in some way related to deploy pipelines; the other half are just... automations of this and that. They're not pipeliney, just freestyle job type things that "do stuff". So in blue-ocean pipeline world, they probably aren't what I'd consider first-class citizens. That said, if blue ocean will one day become the main Jenkins UI, well, then you have to show that stuff! I wonder if somewhere down the road, what y'all come up with is a screen that is devoted to just pipelines – or maybe a persistent filter or something – and then the "kitchen sink" screen for all the things, like the current Jenkins and blue ocean main screens. Anyway, something to think about. Thanks again for all the work you're doing on this. It's very exciting. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36078) Should the pipeline screen show just pipeline jobs, or all jobs?
Title: Message Title Marc Esher created an issue Jenkins / JENKINS-36078 Should the pipeline screen show just pipeline jobs, or all jobs? Issue Type: Bug Assignee: James Dumay Components: blueocean-plugin Created: 2016/Jun/19 1:11 PM Priority: Minor Reporter: Marc Esher This is more a question, or perhaps just behavior that differed from what I'd have expected. When loading the /blue screen, and seeing it titled "Pipelines", and seeing that the REST call filters on "type:pipeline", I would have expected that this screen would only load jobs that are, in fact, pipelines. So: no build flows, no freestyle jobs, etc... just pipelines. Is the current behavior – to show all jobs regardless of type – the expected behavior? Or is it a known bug? Thanks for clarifying. Add Comment
[JIRA] (JENKINS-36074) "failed to write commitId" causes /blue to break completely
Title: Message Title Marc Esher commented on JENKINS-36074 Re: "failed to write commitId" causes /blue to break completely PR submitted: https://github.com/jenkinsci/blueocean-plugin/pull/278 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36074) "failed to write commitId" causes /blue to break completely
Title: Message Title Marc Esher commented on JENKINS-36074 Re: "failed to write commitId" causes /blue to break completely So, I was able to modify the plugin and identify the issue. Before I go into it, huge applause to your team for making blueocean-plugin "just work" out of the box. With minimal jenkins development experience, I was able to git clone, read the README, find the code to fix, re-build and re-deploy to an existing Jenkins, and figure it out. I know that's how it should always work in open source ; I find that it rarely does. So... thank you. Now, here's what I discovered. in AbstractRunImpl.getCommitId(), I have a single job where buildData is not null, but getLastBuiltRevision() is null, which causes the NPE in the stack trace above. What would cause that? This crazy edge case: someone had configured a job, ran it once, and the git repo configured for the job was bad. Consequently, it had a build, but no valid git data. Crazy, huh? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-36074) "failed to write commitId" causes /blue to break completely
Title: Message Title Marc Esher created an issue Jenkins / JENKINS-36074 "failed to write commitId" causes /blue to break completely Issue Type: Bug Assignee: James Dumay Components: blueocean-plugin Created: 2016/Jun/18 8:30 PM Environment: Jenkins 2.9, RHEL, hundreds of jobs Priority: Blocker Reporter: Marc Esher I've installed all the blue ocean hpis, and all dependencies, into an existing Jenkins 2.9 server running on RHEL. Jenkins starts fine, and I get the "try blue ocean" button at the top of the screen. However, when I go to /blue, I get "no pipelines found", and if I go to the XHR that failed (http://myjenkins/blue/rest/search/?q=type:pipeline), I see the following stack trace. thanks! Marc java.io.IOException: Failed to write commitId at org.kohsuke.stapler.export.Property.safeGetValue(Property.java:151) at org.kohsuke.stapler.export.Property.writeTo(Property.java:126) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:227) at org.kohsuke.stapler.export.Property.writeValue(Property.java:279) at org.kohsuke.stapler.export.Property.writeValue(Property.java:168) at org.kohsuke.stapler.export.Property.writeTo(Property.java:139) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:227) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:223) at org.kohsuke.stapler.export.Model.writeTo(Model.java:198) at org.kohsuke.stapler.ResponseImpl.writeOne(ResponseImpl.java:285) at org.kohsuke.stapler.ResponseImpl.serveExposedBean(ResponseImpl.java:273) at hudson.model.Api.doJson(Api.java:211) at
[JIRA] [checkmarx-plugin] (JENKINS-33607) getServerLicenseData: no corresponding wsdl operation
Title: Message Title Marc Esher commented on JENKINS-33607 Re: getServerLicenseData: no corresponding wsdl operation This prevents us (I imagine anyone) from updating to this version of the plugin, since it makes the Checkmarx plugin unusable. We're stuck on 7.x till it's fixed, unless anyone knows of a workaround 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-34642) Jenkins 2.0: pinning plugins no longer works
Title: Message Title Marc Esher created an issue Jenkins / JENKINS-34642 Jenkins 2.0: pinning plugins no longer works Issue Type: Bug Assignee: Unassigned Components: core Created: 2016/May/06 12:58 PM Environment: jenkins 2.1, installed via yum Priority: Minor Reporter: Marc Esher Creating a ".pinned" file used to cause the Jenkins UI to show a "pinned" label in the plugin update center, as documented at https://wiki.jenkins-ci.org/display/JENKINS/Pinned+Plugins This was extremely useful for dealing with plugins that caused problems after updating, and was a real help for Jenkins administrators because we could just pin the plugin rather than having to remember which plugins to leave alone during our scheduled plugin update cycle. It looks like pinning has gone away in Jenkins 2, as evidenced by the fact that we have half a dozen plugins with a ".pinned" file, and yet none of them show up as pinned in the Jenkins UI, and all of them are updatable in the plugin center. I do not know whether this is a half-implemented change, i.e. pinning was removed but the UI wasn't changed to reflect that, or whether pinning is broken. Thanks for considering. Pinning is
[JIRA] [ghprb-plugin] (JENKINS-18577) Add support for multiple GitHub endpoints
Title: Message Title Marc Esher commented on JENKINS-18577 Re: Add support for multiple GitHub endpoints The changelog indicates that the plugin now supports multiple endpoints, but I don't see any evidence of that when I try to configure a job. Does the plugin in fact now support multiple endpoints, and if so, where are the docs explaining how to do so? 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] [job-dsl-plugin] (JENKINS-25747) Error creating jobs with job-dsl-plugin example for Grails and Gradle builders
Marc Esher created JENKINS-25747 Error creating jobs with job-dsl-plugin example for Grails and Gradle builders Issue Type: Bug Assignee: Daniel Spilker Attachments: jenkins-job-dsl-error.png Components: job-dsl-plugin Created: 22/Nov/14 10:46 PM Description: I'm trying to use the example project at https://github.com/sheehan/job-dsl-gradle-example to create jobs. 1. I created a new job that uses this repo as the SCM. 2. Add an Invoke Gradle build step, use gradle wrapper, invoking clean test workspace 3. Add a 'process job dsl' build step, using 'build/workspace/*/.groovy' as the scripts Result: Gradle - Launching build. workspace $ /home/marc/.jenkins/jobs/job-dsl-example-thingie/workspace/gradlew clean test workspace :clean :compileJava UP-TO-DATE :compileGroovy :processResources UP-TO-DATE :classes :compileTestJava UP-TO-DATE :compileTestGroovy :processTestResources UP-TO-DATE :testClasses :test :workspace BUILD SUCCESSFUL Total time: 7.989 secs Build step 'Invoke Gradle script' changed build result to SUCCESS FATAL: org.codehaus.groovy.runtime.InvokerHelper$2 cannot be cast to javaposse.jobdsl.dsl.JobParent java.lang.ClassCastException: org.codehaus.groovy.runtime.InvokerHelper$2 cannot be cast to javaposse.jobdsl.dsl.JobParent at javaposse.jobdsl.dsl.DslScriptLoader.runDslEngineForParent(DslScriptLoader.java:64) at javaposse.jobdsl.dsl.DslScriptLoader.runDslEngine(DslScriptLoader.java:89) at javaposse.jobdsl.plugin.ExecuteDslScripts.perform(ExecuteDslScripts.java:177) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533) at hudson.model.Run.execute(Run.java:1759) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) Environment: ubuntu 14.10 jenkins 1.590 Project: Jenkins Priority: Minor Reporter: Marc Esher 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] [sitemonitor] (JENKINS-25363) SiteMonitor plugin doesn't seem to honor proxy settings
Marc Esher created JENKINS-25363 SiteMonitor plugin doesnt seem to honor proxy settings Issue Type: Bug Assignee: cliffano Components: sitemonitor Created: 29/Oct/14 5:14 PM Description: I'm using Jenkins behind a proxy. I've set the http proxy setting on the plugins screen and can update plugins properly. I've set global environment variables for proxy settings, as well: http_proxy=http://blah: and so forth, and inside jobs I can wget and/or curl to URLs, watch it pick up the proxy setting, and successfully connect. However, with the SiteMonitor plugin, it can't connect outbound, and I'm wondering if it's not picking up on the proxy setting. Unfortunately, I don't see any logging that helps me get to the bottom of this. This is all I get in the console output: ava.net.SocketTimeoutException: connect timed out - connect timed out URL: http://google.com, response code: null, status: DOWN Project: Jenkins Priority: Minor Reporter: Marc Esher 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-flow] (JENKINS-23167) BuildFlow jobs can't find workspace and restart on every SCM Poll
Marc Esher created JENKINS-23167 BuildFlow jobs cant find workspace and restart on every SCM Poll Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: build-flow Created: 23/May/14 1:56 PM Description: I have jobs that use the BuildFlow plugin, and they're configured to poll SCM every so often. I upgraded from 1.547 to the latest, and now some (not all) of those jobs will start on every SCM Poll. The polling log gives this message: Started on May 23, 2014 8:34:00 AM No workspace is available, so can’t check for updates. Scheduling a new build to get a workspace. (use_ondemand_slave) Done. Took 1 ms Changes found This is using BuildFlow version .10. Upgrading to .12 did not solve the problem. Project: Jenkins Priority: Critical Reporter: Marc Esher 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] [performance-plugin] (JENKINS-18690) Unable to contribute to plugin: performance reports error on parse
Marc Esher created JENKINS-18690 Unable to contribute to plugin: performance reports error on parse Issue Type: Bug Assignee: Manuel Carrasco Components: performance-plugin Created: 10/Jul/13 11:35 AM Description: I've forked the latest code at github and am running with mvn hpi:run. I set up a job to run a jmeter test and emit a .jtl file, and then have configured the job to parse that file. When it attempts to do so, I get this error: Performance: Parsing JMeter report file simple_hammer.jtl Jul 10, 2013 7:20:38 AM hudson.model.AbstractBuild$AbstractRunner performAllBuildSteps WARNING: Publisher hudson.plugins.performance.PerformancePublisher aborted due to exception java.util.InputMismatchException at java.util.Scanner.throwFor(Scanner.java:840) at java.util.Scanner.next(Scanner.java:1461) at java.util.Scanner.nextLong(Scanner.java:2196) at java.util.Scanner.nextLong(Scanner.java:2156) at hudson.plugins.performance.JmeterSummarizerParser.parse(JmeterSummarizerParser.java:76) at hudson.plugins.performance.PerformancePublisher.perform(PerformancePublisher.java:222) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:603) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:582) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:560) at hudson.model.Build$RunnerImpl.post2(Build.java:156) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:529) at hudson.model.Run.run(Run.java:1363) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:140) As a result, I see no way to contribute to this plugin Project: Jenkins Priority: Major Reporter: Marc Esher 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] [performance-plugin] (JENKINS-18690) Unable to contribute to plugin: performance reports error on parse
Marc Esher commented on JENKINS-18690 Unable to contribute to plugin: performance reports error on parse This is using Apache JMeter 2.9 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] [performance-plugin] (JENKINS-18690) Unable to contribute to plugin: performance reports error on parse
Marc Esher updated JENKINS-18690 Unable to contribute to plugin: performance reports error on parse .jtl file causing the error Change By: Marc Esher (10/Jul/13 11:44 AM) Attachment: results_scrubbed.jtl 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] [performance-plugin] (JENKINS-15553) Would be nice to have a performance threshold for each performance report? Some reports are supposed to fail (ex: rate limit testing)..
Marc Esher commented on JENKINS-15553 Would be nice to have a performance threshold for each performance report? Some reports are supposed to fail (ex: rate limit testing).. In the absence of this feature, which I'd consider critical, is there a way to use asserts in the jmeter tests themselves to achieve the same thing? 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] [performance-plugin] (JENKINS-18576) Add throughput column to performance plugin charts
Marc Esher created JENKINS-18576 Add throughput column to performance plugin charts Issue Type: Improvement Assignee: Manuel Carrasco Components: performance-plugin Created: 02/Jul/13 9:57 AM Description: When running JMeter tests via the JMeter runner, the aggregate chart has a Throughput column which shows requests / sec. Adding this to the performance plugin charts would be super helpful. Bonus: add the ability to fail a build if req/sec falls below a certain threshold. Project: Jenkins Priority: Major Reporter: Marc Esher 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] [ghprb] (JENKINS-18577) Add support for multiple GitHub endpoints
Marc Esher created JENKINS-18577 Add support for multiple GitHub endpoints Issue Type: Improvement Assignee: Honza Brázdil Components: ghprb Created: 02/Jul/13 10:18 AM Description: Currently, you configure a single API endpoint in the main Jenkins config. This effectively limits this incredibly useful plugin to only a single GitHub instance for all builds. With GitHub Enterprise becoming increasingly popular, organizations are working with a mix of publicly hosted and internal projects. Adding support for multiple GH endpoints would enable, at the job level, for us to choose which endpoint to use for a given job. I'd define an endpoint as an API URL + credentials. I'm not sure how much value there would be in pulling all of the other values (admin lists, etc) into endpoint-specific properties as those seem like they'd apply to all endpoints equally. I looked into contributing this functionality, but I confess that being new to Jenkins plugin authoring the way forward was unclear. For example, would endpoints become an property of the main task? How do you add repeaters for that property? Or would the entire main task become a repeatable? Thanks for considering! Project: Jenkins Priority: Major Reporter: Marc Esher 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-14302) Integration with the Build Pipeline Plugin
Marc Esher commented on JENKINS-14302 Integration with the Build Pipeline Plugin I put a bit of money where my mouth is on this one via the "Sponsor this" link... $100 bucks isn't much, but if others value this one as much as I do perhaps we could contribute enough to have this issue bubbled up to the top, worked on, and released. The build flow plugin is exactly what I was looking for external job flow configuration and integration with the Build Pipeline view is it's killer missing feature. http://www.freedomsponsors.org/core/offer/243/integration-with-the-build-pipeline-plugin? 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.
