[JIRA] (JENKINS-62211) Justin Harringa asked me to open this: pipeline triggers not working using https://github.com/jenkinsci/config-driven-pipeline-plugin
Title: Message Title
Justin Harringa edited a comment on JENKINS-62211
Re: Justin Harringa asked me to open this: pipeline triggers not working using https://github.com/jenkinsci/config-driven-pipeline-plugin
[~funeeldy] ah! Actually, I believe what is going on here is that the template may not actually be in the actual job workspace since we attempt to do a lightweight checkout (so {{getWorkSpace()}} will likely return {{null}} or something unexpected - I think that's your declared method if I understand correctly). Would you be able to utilize {{env.BRANCH_NAME}} instead of {{getWorkSpace()}} or perhaps [one of the other envs|https://docs.cloudbees.com/docs/admin-resources/latest/automating-with-jenkinsfile/working-with-the-env] ({{JOB_NAME}} may be another candidate depending on whether this is a MultiBranch setup or another root job type) ?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.206145.151564000.23905.1588971240153%40Atlassian.JIRA.
[JIRA] (JENKINS-62211) Justin Harringa asked me to open this: pipeline triggers not working using https://github.com/jenkinsci/config-driven-pipeline-plugin
Title: Message Title
Justin Harringa commented on JENKINS-62211
Re: Justin Harringa asked me to open this: pipeline triggers not working using https://github.com/jenkinsci/config-driven-pipeline-plugin
marlene cote ah! Actually, I believe what is going on here is that the template may not actually be in the actual job workspace since we attempt to do a lightweight checkout (so getWorkSpace() will likely return null or something unexpected - I think that's your declared method if I understand correctly). Would you be able to utilize env.BRANCH_NAME instead of getWorkSpace() or perhaps one of the other envs{{}}?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.206145.151564000.23901.1588971120206%40Atlassian.JIRA.
[JIRA] (JENKINS-62211) Justin Harringa asked me to open this: pipeline triggers not working using https://github.com/jenkinsci/config-driven-pipeline-plugin
Title: Message Title
Justin Harringa edited a comment on JENKINS-62211
Re: Justin Harringa asked me to open this: pipeline triggers not working using https://github.com/jenkinsci/config-driven-pipeline-plugin
[~funeeldy] ah! Actually, I believe what is going on here is that the template may not actually be in the actual job workspace since we attempt to do a lightweight checkout (so {{getWorkSpace()}} will likely return {{null}} or something unexpected - I think that's your declared method if I understand correctly). Would you be able to utilize {{env.BRANCH_NAME}} instead of {{getWorkSpace()}} or perhaps [one of the other envs|https://docs.cloudbees.com/docs/admin-resources/latest/automating-with-jenkinsfile/working-with-the-env] {{}} ?
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.206145.151564000.23903.1588971120435%40Atlassian.JIRA.
[JIRA] (JENKINS-62211) Justin Harringa asked me to open this: pipeline triggers not working using https://github.com/jenkinsci/config-driven-pipeline-plugin
Title: Message Title Justin Harringa commented on JENKINS-62211 Re: Justin Harringa asked me to open this: pipeline triggers not working using https://github.com/jenkinsci/config-driven-pipeline-plugin Thanks marlene cote! If I recall correctly, some triggers require an initial pipeline run to save (even for a raw pipeline without this plugin) but that may have been fixed. I'm also curious if this may have something to do with `getWorkSpace()`. Will take a look. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.206145.151564000.23808.1588959480200%40Atlassian.JIRA.
[JIRA] (JENKINS-58662) Allow users to specify a mirror URL which would point to an internal mirror of the public plugin repo
Title: Message Title Justin Harringa commented on JENKINS-58662 Re: Allow users to specify a mirror URL which would point to an internal mirror of the public plugin repo I didn't add this to the GSoC epic and didn't add the GSoC label because I thought I would leave that up to the group on whether this would be in scope. Note: Oleg Nenashev mentioned that Custom WAR Packager does something like this. He also mentioned "Will change in 2.0.0 tho, I will integrate the Plugin Manager Lib there" Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200944.1564072122000.1027.1564072320128%40Atlassian.JIRA.
[JIRA] (JENKINS-58662) Allow users to specify a mirror URL which would point to an internal mirror of the public plugin repo
Title: Message Title Justin Harringa created an issue Jenkins / JENKINS-58662 Allow users to specify a mirror URL which would point to an internal mirror of the public plugin repo Issue Type: New Feature Assignee: Natasha Stopa Components: plugin-installation-manager-tool Created: 2019-07-25 16:28 Labels: plugin-manager Priority: Minor Reporter: Justin Harringa It would be nice to be able to provide a single mirror URL to override the normal Jenkins public infrastructure. Background: Some companies run something like Sonatype Nexus Repository or Artifactory to mirror public Maven repositories. While they could run an internal update center, some organizations choose not to because of the extra management. Add Comment
[JIRA] (JENKINS-58532) Credentials don't seem to refresh or can't switch protocol for a server?
Title: Message Title Justin Harringa updated an issue Jenkins / JENKINS-58532 Credentials don't seem to refresh or can't switch protocol for a server? Change By: Justin Harringa I had originally started out using a single GitLab server configuration in Manage Jenkins with an SSH Key. I then tried to add a new GitLab Personal Access Token from within the job creation screen and it didn't show up after hitting Save. Next, I tried to create a GitLab Personal Access Token from the main Credentials screen. It still did not show up in the job configuration. I can see all of the credentials in the Credentials plugin screens. However, it appears that the GitLab configuration only wants to show the SSH Key credential. Perhaps the server configuration somehow gets locked to a protocol? If that's the case, that might not be great from a security perspective since it would seem that job configuration might affect the whole Jenkins server configuration. !image-2019-07-17-08-22-43-775.png!!image-2019-07-17-08-23-52-586.png! Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://group
[JIRA] (JENKINS-58532) Credentials don't seem to refresh or can't switch protocol for a server?
Title: Message Title Justin Harringa created an issue Jenkins / JENKINS-58532 Credentials don't seem to refresh or can't switch protocol for a server? Issue Type: Bug Assignee: Parichay Barpanda Attachments: image-2019-07-17-08-22-43-775.png, image-2019-07-17-08-23-52-586.png Components: gitlab-branch-source-plugin Created: 2019-07-17 15:24 Priority: Major Reporter: Justin Harringa I had originally started out using a single GitLab server configuration in Manage Jenkins with an SSH Key. I then tried to add a new GitLab Personal Access Token from within the job creation screen and it didn't show up after hitting Save. Next, I tried to create a GitLab Personal Access Token from the main Credentials screen. It still did not show up in the job configuration. I can see all of the credentials in the Credentials plugin screens. However, it appears that the GitLab configuration only wants to show the SSH Key credential. Add Comment
[JIRA] (JENKINS-58531) New GitLab Group w/ SSH key can't check out repos
Title: Message Title Justin Harringa created an issue Jenkins / JENKINS-58531 New GitLab Group w/ SSH key can't check out repos Issue Type: Bug Assignee: Parichay Barpanda Components: gitlab-branch-source-plugin Created: 2019-07-17 14:55 Priority: Major Reporter: Justin Harringa Steps to reproduce: start a new GitLab Group with an SSH Key credential Save Observe that candidate repos are found See the following error in the Indexing Console (e.g. http://localhost:8080/jenkins/job/test/job/justin-harringa%252Fjenkins-test/indexing/console) ``` ERROR: [Wed Jul 17 07:51:22 PDT 2019] Could not fetch branches from source io.jenkins.plugins.gitlabbranchsource.GitLabSCMNavigator:: https://gitlab.com::justin-harringa::justin-harringa/jenkins-test java.net.URISyntaxException: Illegal character in scheme name at index 3: g...@gitlab.com:justin-harringa/jenkins-test.git at java.net.URI$Parser.fail(URI.java:2848) at java.net.URI$Parser.checkChars(URI.java:3021) at java.net.URI$Parser.parse(URI.java:3048) at java.net.URI.(URI.java:588) at java.net.URI.create(URI.java:850) Caused: java.lang.IllegalArgumentException: Illegal character in scheme name at index 3: g...@gitlab.com:justin-harringa/jenkins-test.git at java.net.URI.create(URI.java:852) at io.jenkins.plugins.gitlabbranchsource.GitLabSCMBuilder.checkoutUriTemplate(GitLabSCMBuilder.java:132) at io.jenkins.plugins.gitlabbranchsource.GitLabSCMBuilder.checkoutUriTemplate(GitLabSCMBuilder.java:179) at io.jenkins.plugins.gitlabbranchsource.GitLabSCMBuilder.withGitLabRemote(GitLabSCMBuilder.java:192) at io.jenkins.plugins.gitlabbranchsource.GitLabSCMBuilder.build(GitLabSCMBuilder.
[JIRA] (JENKINS-58445) Decide on GitLab Pipeline status notifier strategy
Title: Message Title Justin Harringa edited a comment on JENKINS-58445 Re: Decide on GitLab Pipeline status notifier strategy RE: comment about potentially allowing the user to provide the option of how they'd like statuses to show up in GitLab - Perhaps this story should be the simpler thing to implement and then another story could be to add the other option? I suspect that just the overall pipeline status would be easier but [~baymac] can make that determination. :) Thoughts [~jequals5]? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200577.1562856316000.14106.1563371580108%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58445) Decide on GitLab Pipeline status notifier strategy
Title: Message Title Justin Harringa edited a comment on JENKINS-58445 Re: Decide on GitLab Pipeline status notifier strategy RE: comment about potentially allowing the user to provide the option of how they'd like statuses to show up in GitLab - Perhaps this story should be the simpler thing to implement and then another story could be to add the other option? I suspect that just the overall pipeline status would be easier but [~baymac] can make that determination. :) Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200577.1562856316000.14104.1563371520095%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58445) Decide on GitLab Pipeline status notifier strategy
Title: Message Title Justin Harringa commented on JENKINS-58445 Re: Decide on GitLab Pipeline status notifier strategy Perhaps this story should be the simpler thing to implement and then another story could be to add the other option? I suspect that just the overall pipeline status would be easier but Parichay Barpanda can make that determination. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200577.1562856316000.14102.1563371460186%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-52963) Provide list of invalid xml files in build output (or provide option for this)
Title: Message Title Justin Harringa closed an issue as Fixed I'm closing this out as I was able to confirm that this issue is fixed and these logs show up in newer versions of the plugin. Thanks Nikolas Falco! Jenkins / JENKINS-52963 Provide list of invalid xml files in build output (or provide option for this) Change By: Justin Harringa Status: Open Closed Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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-52963) Provide list of invalid xml files in build output (or provide option for this)
Title: Message Title Justin Harringa commented on JENKINS-52963 Re: Provide list of invalid xml files in build output (or provide option for this) Hi Nikolas Falco, I guess I didn't see that. We're running version 1.102 (we had upgraded but backed off due to JEP-200. It appears that you also resolved the JEP-200 issues so I'll try to upgrade and close this out if it's resolved. Thanks! Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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-52963) Provide list of invalid xml files in build output (or provide option for this)
Title: Message Title Justin Harringa created an issue Jenkins / JENKINS-52963 Provide list of invalid xml files in build output (or provide option for this) Issue Type: Improvement Assignee: Nikolas Falco Components: xunit-plugin Created: 2018-08-09 16:56 Priority: Major Reporter: Justin Harringa Currently, the actual files that have format errors are stored in the Jenkins log which is generally only available for administrators. It would be nice to either provide a summary list of files that had formatting errors or provide an option for people to get this information in their build logs. This is a pretty big usability issue for non-admins. Add Comment
[JIRA] [openid] (JENKINS-22368) Discovery fails when Jenkins is behind a proxy
Justin Harringa
updated JENKINS-22368
Discovery fails when Jenkins is behind a proxy
Change By:
Justin Harringa
(26/Mar/14 8:01 PM)
Description:
The OpenId plugin doesn't work properly when attempting to discover the provider. My specific case is with the Google provider. I confirmed that I could access the URL with Jenkins by testing the Google URL in the proxy settings screen (I have also been downloading plugins, etc). Upon inspection of the code, I noticed that the constructor that calls the discovery method in openid4java never initialized
the proxy settings for
HttpClient with the HttpClientFactory. This was only occurring in the getManager() method. Here is an example of the log entry. {noformat}Mar 24, 2014 3:37:46 PM org.apache.catalina.core.ApplicationContext logSEVERE: Error while serving http://someserver.mydomain.com/jenkins/configureSecurity/configurejava.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:120) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631) at org.kohsuke.stapler.Stapler.service(Stapler.java:225) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:203) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:90) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at org.apache.catalina.core.ApplicationFilterChain.in
[JIRA] [openid] (JENKINS-22368) Discovery fails when Jenkins is behind a proxy
Justin Harringa created JENKINS-22368 Discovery fails when Jenkins is behind a proxy Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: openid Created: 26/Mar/14 6:41 PM Description: The OpenId plugin doesn't work properly when attempting to discover the provider. My specific case is with the Google provider. I confirmed that I could access the URL with Jenkins by testing the Google URL in the proxy settings screen (I have also been downloading plugins, etc). Upon inspection of the code, I noticed that the constructor that calls the discovery method in openid4java never initialized HttpClient with the HttpClientFactory. This was only occurring in the getManager() method. Here is an example of the log entry. Mar 24, 2014 3:37:46 PM org.apache.catalina.core.ApplicationContext log SEVERE: Error while serving http://someserver.mydomain.com/jenkins/configureSecurity/configure java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:120) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631) at org.kohsuke.stapler.Stapler.service(Stapler.java:225) at javax.servlet.http.HttpServlet.service(HttpServlet.java:728) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:203) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:181) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:90) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:46) at org.apache.catalina.core.Appl
[JIRA] [core] (JENKINS-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Justin Harringa commented on JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException @Jesse: On Monday, we're going to upgrade from 1.480.3 to the 1.509.2.JENKINS-14362-jzlib.war on an instance that seems to hit this every few days or so. I'll be sure to report by the end of next week if we see this issue crop up again. I'm hopeful that this will help and I suspect reporting the result will be helpful to you. 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-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Justin Harringa edited a comment on JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException That sounds good. I'll see what I can do. I thought I had reproduced the issue by opening the Wall Display plugin report in a few tabs. After that, I hit refresh rapidly on one of the tabs. Then, the CPU was pegged. Unfortunately, the CPU usage calmed down after a while and I didn't see a thread dump indicating the usage of Deflater.deflateBytes. This seemed to cause issues in one of our more heavily used instances but it appears it corrects itself in the sandbox environment so it could be a red herring. This doesn't appear to be an effective way to reproduce the issue. I'm currently on 1.480.3. Once I find a way to reproduce, I'll try to reproduce on 1.509.2 as well and then move to your patched WAR in this sandbox environment. 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-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Justin Harringa updated JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException Sorry, I should have clarified that I didn't see any threads using Deflater.deflateBytes in the my attempt to reproduce using the Wall Display plugin. I have seen that, in conjunction with consistently pegged CPUs, in my production instance on 1.480.3 (see thread-dump-prod.txt). I was hoping to properly indicate that the Wall Display method I was using wouldn't adequately reproduce the situation since the CPU usage fell. Just to make sure I've got it clear, my impression is that the combination of pegged CPUs, which stay pegged, as well as a threadDump with threads using Deflater.deflateBytes is what we're looking for in order to call it a valid reproduction of the problem. Is that correct? It seems like the closest I've gotten to reproducing this is by using dave catalan's suggested steps. Unfortunately, I was only able to get the thread dump with threads using Deflater.deflateBytes but the CPU usage only spiked to 100% for a few minutes. It seems that this would indicate that I haven't reproduced the issue that could be fixed. I attached 3 separate dumps for the reproduced items (thread-dump-reproduce-1.txt appears to be before or after the deflateBytes call). It would seem that we don't have a deterministic way to reproduce this yet. Change By: Justin Harringa (23/Jul/13 10:45 PM) Attachment: thread-dump-reproduce-2.txt Attachment: thread-dump-reproduce-3.txt Attachment: thread-dump-prod.txt Attachment: thread-dump-reproduce-1.txt 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-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Justin Harringa edited a comment on JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException That sounds good. I'll see what I can do. I thought I had reproduced the issue by opening the Wall Display plugin report in a few tabs. After that, I hit refresh rapidly on one of the tabs. Then, the CPU was pegged. Unfortunately, the CPU usage calmed down after a while. This seemed to cause issues in one of our more heavily used instances but it appears it corrects itself in the sandbox environment so it could be a red herring. I'm currently on 1.480.3. I'll try to reproduce on 1.509.2 as well and then move to your patched WAR in this sandbox environment. 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-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Justin Harringa commented on JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException That sounds good. I'll see what I can do. I just reproduced the issue by opening the Wall Display plugin report in a few tabs. After that, I hit refresh rapidly on one of the tabs. Now the CPU is pegged. I'm currently on 1.480.3. I'll try to reproduce on 1.509.2 as well and then move to your patched WAR in this sandbox environment. 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-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Justin Harringa commented on JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException Is there any chance that this might get back-ported besides just providing the WAR? I noticed that you already marked it as an lts-candidate but it didn't make it into 1.509.2 and wasn't rejected either. 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-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Justin Harringa edited a comment on JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException Is there any chance that this might get backported besides just providing the WAR? I noticed that you already marked it as an lts-candidate but it didn't make it into 1.509.2 and wasn't rejected either. Our infra guys prefer installing via RPM. 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-14362) 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException
Justin Harringa edited a comment on JENKINS-14362 100% CPU load during org.kohsuke.stapler.compression.CompressionFilter.reportException Is there any chance that this might get backported besides just providing the WAR? I noticed that you already marked it as an lts-candidate but it didn't make it into 1.509.2 and wasn't rejected either. 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-9258) "Remember me on this computer", still getting asked to log in after a few hours
Justin Harringa commented on JENKINS-9258 "Remember me on this computer", still getting asked to log in after a few hours Are those of you who see only the 2 options running your master on Windows? I see only the 2 options on Windows and I see all of the options James Howe mentioned on my Linux masters. 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-15321) Campfire proxy support doesn't allow for basic auth with the proxy server
Justin Harringa created JENKINS-15321 Campfire proxy support doesn't allow for basic auth with the proxy server Issue Type: Improvement Assignee: jenslukowski Components: campfire Created: 26/Sep/12 3:04 PM Description: In Campfire.java, HttpClient is being used to set the proxy host and port but there isn't currently support for passing credentials to the proxy. I may try to work on this if I get some time but thought I would get this out there in case others can work on it and test. Project: Jenkins Labels: plugin jenkins Priority: Major Reporter: Justin Harringa 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
