[JIRA] (JENKINS-57143) JNLP4 error: "Connection closed before acknowledgement sent"
Title: Message Title Nathan Neulinger commented on JENKINS-57143 Re: JNLP4 error: "Connection closed before acknowledgement sent" I'd also ask question of why it has to reverse resolve - i.e. why is that requirement in there in the first place. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.198893.1555967243000.191.1575483540240%40Atlassian.JIRA.
[JIRA] (JENKINS-57143) JNLP4 error: "Connection closed before acknowledgement sent"
Title: Message Title Nathan Neulinger commented on JENKINS-57143 Re: JNLP4 error: "Connection closed before acknowledgement sent" There was near zero useful reporting server side - if the JNLP server side handler has "remote client has to resolve in DNS" at the very least reporting that explicitly in the failure logs. I can understand it not being able to necessarily make it back to the client side but at the least the server side should report it usefully in logs. (Just guessing there, but I can certainly see that possibility from JNLP4 protocol limitations.) Would be great if server side could report it in the agent status on the node page, but at the very least getting it in the logs. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.198893.1555967243000.187.1575483480319%40Atlassian.JIRA.
[JIRA] (JENKINS-57143) JNLP4 error: "Connection closed before acknowledgement sent"
Title: Message Title Nathan Neulinger commented on JENKINS-57143 Re: JNLP4 error: "Connection closed before acknowledgement sent" Yep, almost exact same failure, with addition of it indicating that all protocols were rejected. Re-enabling JNLP3 fixed it as a test. It was just dumb luck viewing an strace of the jenkins master that I saw the hangs/failures of reverse dns lookups on the master. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.198893.1555967243000.179.1575482880227%40Atlassian.JIRA.
[JIRA] (JENKINS-29616) java.lang.Exception: The server rejected the connection: None of the protocols were accepted
Title: Message Title Nathan Neulinger commented on JENKINS-29616 Re: java.lang.Exception: The server rejected the connection: None of the protocols were accepted FYI in case it helps any – I just had to go through a big diag effort on my site with a bunch of windows JNLP agents that stopped working sometime in past few days with the same above failures/errors. After a long set of rabbit trails - what I found in my case – the problem wound up being reverse DNS resolution stopped working (unrelated local problem – "It's always DNS", right?) - but that inability to reverse resolve the connecting client (windows box) was causing the JNLP server side to drop the connection. Just wanted to add this here in case it helps anyone else with future similar issues if it happens to be related. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.164090.1437742638000.11637.1575420780965%40Atlassian.JIRA.
[JIRA] (JENKINS-57143) JNLP4 error: "Connection closed before acknowledgement sent"
Title: Message Title Nathan Neulinger commented on JENKINS-57143 Re: JNLP4 error: "Connection closed before acknowledgement sent" I realize this has already been closed - but just had to go through a big diag effort on my site with a bunch of windows JNLP agents that stopped working sometime in past few days. After a long set of rabbit trails - what I found in my case – the problem wound up being reverse DNS resolution stopped working (unrelated local problem – "It's always DNS", right?) - but that inability to reverse resolve the connecting client (windows box) was causing the JNLP server side to drop the connection. Just wanted to add this here in case it helps anyone else with future similar issues if it happens to be related. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.198893.1555967243000.11633.1575420420188%40Atlassian.JIRA.
[JIRA] (JENKINS-59169) JNLP4 Connect Error - Connection closed before acknowledgement sent
Title: Message Title Nathan Neulinger commented on JENKINS-59169 Re: JNLP4 Connect Error - Connection closed before acknowledgement sent I realize this has already been closed - but just had to go through a big diag effort on my site with a bunch of windows JNLP agents that stopped working sometime in past few days. After a long set of rabbit trails - what I found in my case – the problem wound up being reverse DNS resolution stopped working (unrelated local problem – "It's always DNS", right?) - but that inability to reverse resolve the connecting client (windows box) was causing the JNLP server side to drop the connection. Just wanted to add this here in case it helps anyone else with future similar issues if it happens to be related. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.201606.1567306209000.11610.1575418440300%40Atlassian.JIRA.
[JIRA] (JENKINS-59229) csrf protection too strict?
Title: Message Title Nathan Neulinger commented on JENKINS-59229 Re: csrf protection too strict? Never mind, I missed the option to put on the 'Strict Crumb Issuer' plugin to allow tuning. 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.201686.1567613166000.7320.1567709460120%40Atlassian.JIRA.
[JIRA] (JENKINS-59229) csrf protection too strict?
Title: Message Title Nathan Neulinger commented on JENKINS-59229 Re: csrf protection too strict? Jan Heylen I do think this is something that they should be addressing since it seems like "outright break existing functionality" is something that shouldn't be sprung on users in a security update without any ability for an admin to say "Hey, I get this is a problem, but the fix is worse than the problem in terms of breakage – let me turn it off and have a chance to make the appropriate updates in my build system while you continue to generate WARNINGS internally, and when I (customer) am ready for it, I'll fully enable it – just like the option to enable CSRF protection at all." 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.201686.1567613166000.7312.1567709280184%40Atlassian.JIRA.
[JIRA] (JENKINS-59229) csrf protection too strict?
Title: Message Title Nathan Neulinger commented on JENKINS-59229 Re: csrf protection too strict? Either way - it's clear that the change above has likely broken tons of legacy code that already was previously broken when enabling CSRF. Tons of examples on how to use it are now likely wrong/broken. 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.201686.1567613166000.6858.1567637880112%40Atlassian.JIRA.
[JIRA] (JENKINS-59229) csrf protection too strict?
Title: Message Title Nathan Neulinger commented on JENKINS-59229 Re: csrf protection too strict? Started getting this on my instance as well. In my case, changing my triggering code to maintain session cookies was sufficient to get it to work. Didn't find a "nice" way to do that with curl/wget though, so wound up switching to a perl based trigger. It seems like --cookie-jar SHOULD work, but didn't for me. I believe it's related to this: https://jenkins.io/security/advisory/2019-07-17/#SECURITY-626 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.201686.1567613166000.6856.1567637820193%40Atlassian.JIRA.
[JIRA] (JENKINS-52232) Credentials not usable after upgrade to 1.14
Title: Message Title Nathan Neulinger commented on JENKINS-52232 Re: Credentials not usable after upgrade to 1.14 Had a chance to try this again, and cannot reproduce now - upgrade processed smoothly with no issues. Sorry I can't provide anything further. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-52232) Credentials not usable after upgrade to 1.14
Title: Message Title Nathan Neulinger commented on JENKINS-52232 Re: Credentials not usable after upgrade to 1.14 For the credentials for me - it's almost entirely pre-existing use of ~jenkins/.ssh/id_rsa that was affected. Very little use of built-in creds - and none at all of that for agent connections. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-52232) Credentials not usable after upgrade to 1.14
Title: Message Title Nathan Neulinger commented on JENKINS-52232 Re: Credentials not usable after upgrade to 1.14 Gotta love when failure = working fine. No folders, all jobs visible to anonymous, but have a handful of jobs that are restricted from execution. Didn't look at credentials related to anything within the jobs - only for the agent connections. It's possible there was impact inside the jobs as well - didn't get that far when I saw the upgrade fail. Aside from sitting behind apache, and being in a different directory structure the instance should be pretty vanilla. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-52232) Credentials not usable after upgrade to 1.14
Title: Message Title Nathan Neulinger commented on JENKINS-52232 Re: Credentials not usable after upgrade to 1.14 I had the same symptom - just been watching the issues here, have not tried re-updating since the last failure. In the first iteration, I didn't pay any active attention to log during upgrade itself, only noticed the resolve errors afterwards. In my case, using project matrix auth. Will try to see if symptom reproduces and capture some additional logs for you if so. 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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-40496) Need way to clear/reset allocated xvnc ports - groovy?
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-40496 Need way to clear/reset allocated xvnc ports - groovy? Issue Type: Task Assignee: Levon Saldamli Components: xvnc-plugin Created: 2016/Dec/16 3:45 AM Priority: Minor Reporter: Nathan Neulinger See here: http://stackoverflow.com/questions/31481107/jenkins-xvnc-plugin-some-display-numbers-stay-allocated-when-a-build-is-stopped I'm having the same issue. I can probably get this done during a scheduled outage on the jenkins master, but that's really invasive. Is there any way to call a function via groovy to reset and clear the content? Add Comment
[JIRA] (JENKINS-31819) vSphere-cloud plugin 2.7 does not work with vSphere 6.0
Title: Message Title Nathan Neulinger commented on JENKINS-31819 Re: vSphere-cloud plugin 2.7 does not work with vSphere 6.0 Fair enough - 'full admin' might be a bit exaggerated. I do know that at a minimum though - it doesn't prompt for what folder to put the resulting cloned vm in, and I 100% certain that the user will not have rights to either the top level folder nor write access to the folder where the master/source VM is located. Given that, I can't think of any other place where it would choose to put the VM. The plugin DOES work great for us for restarts/power ops - I've only just started looking at using it to provision test/CI vms. Running 2.14 on on jenkins 2.19.3 currently. Independently, the backtraces/faults/exceptions are not resulting in a failure in the job itself, which would be nice to see - job just acts like it worked and proceeds, even though it didn't create anything. 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-31819) vSphere-cloud plugin 2.7 does not work with vSphere 6.0
Title: Message Title Nathan Neulinger commented on JENKINS-31819 Re: vSphere-cloud plugin 2.7 does not work with vSphere 6.0 In my case, I was getting 'no snapshots found' until I actually created a snapshot on the VM. But - even with that, the plugin is not usable for cloning due to it seeming to require full admin rights over the entire vcenter. Biggest missing piece is ability to specify the destination folder when cloning. I've given jenkins automation account the same access as our developers, but it is unable to perform the same cloning that they are able to do since it doesn't give option to specify destination folder. 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-19408) Implement option to select data store and/or folder for new vm clone
Title: Message Title Nathan Neulinger commented on JENKINS-19408 Re: Implement option to select data store and/or folder for new vm clone It appears that datastore is one of the options now on the plugin for clone task - but I still don't see anything to specify the folder. It's not even clear what folder it will even TRY to use... This makes it useless for cloning unfortunately since the jenkins automation user doesn't have admin rights over the entire vcenter, only to certain portions of the environment. 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-39108) Add recipient exclusion field to email notifications for broken builds
Title: Message Title Nathan Neulinger commented on JENKINS-39108 Re: Add recipient exclusion field to email notifications for broken builds Unfortunately, that doesn't really help this use case. In most projects, I do want notifications, but for certain jobs - I don't want the notifications because they are virtually never because of my (or certain ops users) commits – specifically for those jobs. 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-39108) Add recipient exclusion field to email notifications for broken builds
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-39108 Add recipient exclusion field to email notifications for broken builds Issue Type: New Feature Assignee: David van Laatum Components: email-ext-plugin, mailer-plugin Created: 2016/Oct/19 1:22 PM Priority: Minor Reporter: Nathan Neulinger There are cases in build setup where you want to have "notify people who broke the build" or equivalent selected, but certain people (or internal system committer users/etc.) should not be notified just because a developer broke the build. In my case, it's cause we have a separate repository with CI utility scripts that is included in the checkouts. As it stands now, if a dev on the main project repo breaks something - any committer on the CI tools repo ALSO gets notifications of those failing builds in the mean time. Granted - they could be a build breaker, but in our environment, that's the .1% case. Suggested implementation: Exclude Recipients: [ ] - takes a comma separated list of email addresses and/or Exclude Patterns: [ multiline ] - takes a newline separated list of regexes or email addresses Note - I've listed both mailer-plugin and ext-mail-plugin as they both have this functionality, but I expect that this issue will need to be split/cloned.
[JIRA] [all-changes-plugin] (JENKINS-34765) "All Changes" returning stack overflow
Title: Message Title Nathan Neulinger assigned an issue to wolfs Jenkins / JENKINS-34765 "All Changes" returning stack overflow Change By: Nathan Neulinger Assignee: wolfs 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] [all-changes-plugin] (JENKINS-34765) "All Changes" returning stack overflow
Title: Message Title Nathan Neulinger updated an issue Jenkins / JENKINS-34765 "All Changes" returning stack overflow Change By: Nathan Neulinger Component/s: core 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] [all-changes-plugin] (JENKINS-34765) "All Changes" returning stack overflow
Title: Message Title Nathan Neulinger updated an issue Jenkins / JENKINS-34765 "All Changes" returning stack overflow Change By: Nathan Neulinger Component/s: all-changes-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] [core] (JENKINS-34765) "All Changes" returning stack overflow
Title: Message Title Nathan Neulinger commented on JENKINS-34765 Re: "All Changes" returning stack overflow A problem occurred while processing the request. Please check our bug tracker to see if a similar problem has already been reported. If it is already reported, please vote and put a comment on it to let us gauge the impact of the problem. If you think this is a new issue, please file a new issue. When you file an issue, make sure to add the entire stack trace, along with the version of Jenkins and relevant plugins. The users list might be also useful in understanding what has happened. Stack trace com.google.common.util.concurrent.ExecutionError: java.lang.StackOverflowError at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2232) at com.google.common.cache.LocalCache.get(LocalCache.java:3965) at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:3969) at com.google.common.cache.LocalCache$LocalManualCache.get(LocalCache.java:4829) at com.google.common.cache.LocalCache$LocalManualCache.getUnchecked(LocalCache.java:4834) at org.kohsuke.stapler.CachingScriptLoader.findScript(CachingScriptLoader.java:62) at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:102) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:735) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$11.dispatch(MetaClass.java:380) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:233) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:135) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:95) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:59) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:176) at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:145) at org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:92) at com.marvelution.jenkins.plugins.jira.filter.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:51) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at com.marvelution.jenkins.plugins.jira.filter.OAuthFilter.doFilter(OAuthFilter.java:87) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:126) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTr
[JIRA] [core] (JENKINS-34765) "All Changes" returning stack overflow
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-34765 "All Changes" returning stack overflow Issue Type: Bug Assignee: Mark Waite Components: core, git-plugin Created: 2016/May/12 2:12 PM Priority: Critical Reporter: Nathan Neulinger Jenkins 2.3 on fc20 with jdk 1.8.0_77 Backtrace whenever choosing the 'All Changes' option on a build. Using git repositories. Add Comment This
[JIRA] [xvfb-plugin] (JENKINS-34443) xvfb config options don't show up in manage jenkins
Title: Message Title Nathan Neulinger commented on JENKINS-34443 Re: xvfb config options don't show up in manage jenkins FYI, the Xvfb plugin page on the jenkins site has this which leads users in the wrong direction: --- Usage The plugin starts and stops the Xvfb virtual framebuffer X11 server so your jobs can use X11 displays in headless environments such as servers, or when dedicated X11 display is required for each job. Start by going to Manage Jenkins / Configure System and setup your Xvfb installation. You need to give it a arbitrary name like default Xvfb and directory in which the Xvfb executable is located like /usr/X11R6/bin. Unfortunately there is no support for automatic installation of Xvfb. As of version 1.1.0 you can define a single Xvfb tool installation or have a installation named "default" and the jobs are going to run even if you don't define what installation to use in the job configuration. -- 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] [xvfb-plugin] (JENKINS-34443) xvfb config options don't show up in manage jenkins
Title: Message Title Nathan Neulinger resolved as Not A Defect That's exactly it - was completely unaware of that Global Tool Configuration menu and was looking for it in configure system. Jenkins / JENKINS-34443 xvfb config options don't show up in manage jenkins Change By: Nathan Neulinger Status: Open Resolved Resolution: Not A Defect 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] [xvfb-plugin] (JENKINS-34443) xvfb config options don't show up in manage jenkins
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-34443 xvfb config options don't show up in manage jenkins Issue Type: Bug Assignee: zregvart Components: xvfb-plugin Created: 2016/Apr/26 1:57 AM Priority: Minor Reporter: Nathan Neulinger Recently reinstalled this plugin after having some problems with Xvnc + selenium. Strange thing is - I can't get any of the admin level configuration options (xvfb installations) to be visible. I've tried completely removing the plugin, restarting, including manually removing any old xvfb config files... Still no go - nothing is visible on the configure screen. I did just update to the 2.0 jenkins release - is there any possible compatibility issue? Add Comment
[JIRA] [core] (JENKINS-32212) "Check Now" to refresh plugin data isn't available on updates tab if last had none
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-32212 "Check Now" to refresh plugin data isn't available on updates tab if last had none Issue Type: Bug Assignee: Unassigned Components: core Created: 28/Dec/15 6:26 PM Environment: 1.642 on fc20 Labels: plugin plugin-manager Priority: Minor Reporter: Nathan Neulinger If most recent cache update indicated that no plugins were available for update, the 'Check Now' and last update date information is not displayed on the updates tab. It is still displayed on the Available tab, and you can click on it there (at which point, since new ones were available, the button started showing up on the updates tab). I think this info should be displayed on all of the plugin update tabs.
[JIRA] [vsphere-cloud-plugin] (JENKINS-32112) NullPointerExceptions about templates in various places
Title: Message Title Nathan Neulinger commented on JENKINS-32112 Re: NullPointerExceptions about templates in various places I don't specifically see any comment on this issue - I was seeing this in JENKINS-32098 and resolution for me was to re-save in jenkins/manage jenkins/configure system to get appropriate values set in the vsphere cloud/advanced/number of slaves fields. 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] [vsphere-cloud-plugin] (JENKINS-32117) NPE in vSphereCloud.getTemplate
Title: Message Title Nathan Neulinger commented on JENKINS-32117 Re: NPE in vSphereCloud.getTemplate Possibly also related to JENKINS-32098 What I found in my case in case it helps was possibly related to bad default handling upgrading 2.6 to 2.8. What fixed it for me was simply going into manage jenkins/configure system and resaving the settings. 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-32116) Can't use "Restrict where this project can be run" due to the NPE in Cloud implementation
Title: Message Title Nathan Neulinger commented on JENKINS-32116 Re: Can't use "Restrict where this project can be run" due to the NPE in Cloud implementation Possibly related to JENKINS-32098 Resolution (so far) in my case was to go to manage jenkins / configure system - and resave the vsphere settings. In my case, I had no dynmically provisioned nodes - only using this plugin for control of test vm instances. 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update Looks to be a bad behavior in vsphere Cloud going from 2.6 to 2.8. Config contents diff from after 1.642 and after re-saving: @@ -115,7 +115,8 @@ xx xx - 0 + 2147483647 + vSphereCloud @@ -125,7 +126,8 @@ xx xx - 0 + 2147483647 + 5 Looking at older saved config - it didn't have the instanceCap element at all. My guess is that the upgrade process defaulted the value incorrectly - or used a different value for the zero indicator, and thus changed behavior. I'll raise with that component. 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update Saving system configuration on the main configure jenkins screen - but not actually changing anything - appears to have made the symptom go away after it restarted vsphere cloud plugin. – even though we had no dynamically provisioned nodes. 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update This symptom has come back, and not my regex/etc. problem... tried your suggested commands in the script console and get this java.lang.NullPointerException at org.jenkinsci.plugins.vSphereCloud.getTemplate(vSphereCloud.java:176) at org.jenkinsci.plugins.vSphereCloud.canProvision(vSphereCloud.java:233) at hudson.model.Label.getClouds(Label.java:227) at hudson.model.Label.isEmpty(Label.java:435) at jenkins.model.Jenkins.getLabels(Jenkins.java:1642) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:233) at groovy.lang.MetaClassImpl$GetBeanMethodMetaProperty.getProperty(MetaClassImpl.java:3500) at org.codehaus.groovy.runtime.callsite.GetEffectivePojoPropertySite.getProperty(GetEffectivePojoPropertySite.java:61) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callGetProperty(AbstractCallSite.java:227) at Script1.run(Script1.groovy:1) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:580) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:618) at groovy.lang.GroovyShell.evaluate(GroovyShell.java:589) at hudson.util.RemotingDiagnostics$Script.call(RemotingDiagnostics.java:142) at hudson.util.RemotingDiagnostics$Script.call(RemotingDiagnostics.java:114) at hudson.remoting.LocalChannel.call(LocalChannel.java:45) at hudson.util.RemotingDiagnostics.executeGroovy(RemotingDiagnostics.java:111) at jenkins.model.Jenkins._doScript(Jenkins.java:3599) at jenkins.model.Jenkins.doScript(Jenkins.java:3571) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:497) 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:121) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:95) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:129) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:59) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:129) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:123) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$Cac
[JIRA] [core] (JENKINS-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger resolved as Cannot Reproduce Jenkins / JENKINS-32098 "Restrict where build can run" missing after 1.642 update Change By: Nathan Neulinger Status: Reopened Resolved Resolution: Cannot Reproduce 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update Ah never mind. ARGH. This was my fault with a crappy regex. Sorry for the waste of time. 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update @@ -72,7 +70,7 @@ true false -14455.3925900 +1447851305480 Etc/UTC false I have not tried tweaking that in 1.641 and 1.642 then reloading to see if it changes behavior any, but that changed content (spontaneously aquired in 1.641/2) appears to result in the similar failed job loading in 1.640. 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger reopened an issue Ok, reopening this - symptom is back - and it looks like it's actually far more widespread. It looks like something is causing the job to actually fail loading - I just wasn't seeing the details before. with 1.641 or 1.642 - when I go to configure a job - it looks like a bunch of parameters are blank - including some build steps. The field for restriction though is still present. I'm seeing this backtrace in the logs. One thing that jumped out when looking at the job before and active saving in new version is that format of one of the elements changed. The element in job metadata plugin section is the only unexpected difference. (The resulting job won't load at all in 1.640.) It looks like a strange mix of formats - but what's consistent is that in newer saves, it's got decimal point in places instead of a java time with milliseconds. Dec 17 02:19:47 fc-jenkins-ito jenkins: Dec 17, 2015 2:19:47 AM hudson.ExpressionFactory2$JexlExpression evaluate Dec 17 02:19:47 fc-jenkins-ito jenkins: WARNING: Caught exception evaluating: h.getRelativeLinkTo(job) in /jenkins/job/itp_Hercules--v5.3/configure. Reason: java.lang.NullPointerException Dec 17 02:19:47 fc-jenkins-ito jenkins: java.lang.NullPointerException Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at hudson.Functions.getRelativeLinkTo(Functions.java:1068) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at sun.reflect.GeneratedMethodAccessor105.invoke(Unknown Source) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at java.lang.reflect.Method.invoke(Method.java:497) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jelly._expression_.ExpressionSupport.evaluateAsString(ExpressionSupport.java:46) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.buildAttributes(ReallyStaticTagLibrary.java:111) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:95) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:120) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:99) Dec 17 02:19:47 fc-jenkins-ito jenkins: #011at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:
[JIRA] [core] (JENKINS-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update "Did I try turning it off and on again". No. 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update wtf. just replaced war again to take to 1.642 and the option is there. something else was clearly causing this then. Very confused now. 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update 1.641 - field is still present in the edit job screen. going to check 1.642 again just to be certain. 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update Not sure what you mean by "have slaves configured"? There are a dozen or so slaves with labels - and everything looked normal, except when bringing up the edit job screen on 1.642 the option to restrict simply wasn't displayed. I'll see if I can try 1.641 - I didn't upgrade to it since it didn't resolve the backtrace issue I was seeing. (Other resolved bug.) 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger commented on JENKINS-32098 Re: "Restrict where build can run" missing after 1.642 update Confirmed that 1.640 option comes back. 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-32098) "Restrict where build can run" missing after 1.642 update
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-32098 "Restrict where build can run" missing after 1.642 update Issue Type: Bug Assignee: Unassigned Components: core Created: 16/Dec/15 3:43 PM Labels: labels Priority: Critical Reporter: Nathan Neulinger After upgrading to 1.642 - this setting appears to be missing, and jobs are now trying to run anywhere they feel like, which clearly isn't going to work. The 'assignedNode' element is still present in the configs, but the configuration element is not displayed when editing the job, and doesn't appear to be used at all. Trying to downgrade to 1.640 (previous release I was running) to confirm that it comes back.
[JIRA] [core] (JENKINS-31954) StackOverflow in hudson.model.Descriptor$NewInstanceBindInterceptor.onConvert
Title: Message Title Nathan Neulinger commented on JENKINS-31954 Re: StackOverflow in hudson.model.Descriptor$NewInstanceBindInterceptor.onConvert Noam Manos pretty sure that build with fix hasn't been released yet 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-31954) StackOverflow in hudson.model.Descriptor$NewInstanceBindInterceptor.onConvert
Title: Message Title Nathan Neulinger commented on JENKINS-31954 Re: StackOverflow in hudson.model.Descriptor$NewInstanceBindInterceptor.onConvert Correction, looks like it's in 1.642. Did you test with 642 or 641? 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-32016) Allow marking as 'keep forever' even if no retention/purge rules are in effect
Title: Message Title Nathan Neulinger commented on JENKINS-32016 Re: Allow marking as 'keep forever' even if no retention/purge rules are in effect Fair enough on the usage - though this actually came out of getting confused that I couldn't set that flag - I believe due to a different bug that has since been fixed (that caused the setting for retention to get turned off unexpectedly). (i.e. I was surprised to find it turned off when I dug into why I couldn't set the option. This suggestion was just a side effect of that.) Will take a look at your suggestion (just turning on with no rules) as that will likely be good enough. 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-32016) Allow marking as 'keep forever' even if no retention/purge rules are in effect
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-32016 Allow marking as 'keep forever' even if no retention/purge rules are in effect Issue Type: New Feature Assignee: Unassigned Components: core Created: 10/Dec/15 7:49 PM Priority: Minor Reporter: Nathan Neulinger The ability to set build retention rules is very useful, as is the ability to mark a build as 'keep forever'. It would however be nice to set that marker even if there aren't currently any build rules in effect since it can act as a clear indicator that a given build is special, and would automatically take effect IF you turned on any of the purge rules. Add Comment
[JIRA] [conditional-buildstep-plugin] (JENKINS-31988) Segfault with stack overflow saving job with conditional build steps
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-31988 Segfault with stack overflow saving job with conditional build steps Issue Type: Bug Assignee: Dominik Bartholdi Attachments: config.xml Components: conditional-buildstep-plugin Created: 09/Dec/15 6:12 PM Environment: 1.640 on linux, full jdk 1.8_45 Priority: Minor Reporter: Nathan Neulinger I have NOT been able to reproduce this except by copies of the job exhibiting the symptom. Config is attached. The user indicates they were able to edit job at will, but shortly after adding the conditional build steps, they were then unable to save further - and get the error/backtrace every time. I created a new job as a copy of their's and see the same symptom. Oops! A problem occurred while processing the request. Please check our bug tracker to see if a similar problem has already been reported. If it is already reported, please vote and put a comment o
[JIRA] [crowd2-plugin] (JENKINS-17957) Crowd plugin - "remember me" doesn't work
Title: Message Title Nathan Neulinger commented on JENKINS-17957 Re: Crowd plugin - "remember me" doesn't work FYI, I am no longer using Crowd. I'm sure there is value in fixing this issue, but I'm not in a position to test/validate/etc. 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-31140) Suggestion - add a "lastBuild" link in the builds tree
Title: Message Title Nathan Neulinger commented on JENKINS-31140 Re: Suggestion - add a "lastBuild" link in the builds tree No, sorry, I should have been more clear and said 'symlink' - referring to the link that is in the filesystem builds/ directory. 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-31207) UI improvement for console log view - show beginning of log when skipping
Title: Message Title Nathan Neulinger commented on JENKINS-31207 Re: UI improvement for console log view - show beginning of log when skipping Very cool! Thanks for that plugin pointer! Rest of request still stands though. 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] [exclusion-plugin] (JENKINS-12399) Dynamic exclusion resourced based on parameter name
Title: Message Title Nathan Neulinger commented on JENKINS-12399 Re: Dynamic exclusion resourced based on parameter name Yeah, it works wonderfully... significant simplification of the jobs. Lack of the control panel is the only real flaw. I am actually not even using 0.11 yet. 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-31210) Add configure option to allow showing a limited subset of build description on the main screen
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-31210 Add configure option to allow showing a limited subset of build description on the main screen Issue Type: Improvement Assignee: Unassigned Components: core Created: 28/Oct/15 2:15 AM Priority: Minor Reporter: Nathan Neulinger We occasionally use the build description to track job progress by sending specific status messages. It's great to be able to see these on the job history view, but would be nice to be able to see all or a portion of this in the Build Agents view on the main page. I'd like to see an option in configure screen: [ X ] Show last line of build description in nodes list for any actively running jobs. This would extract only the last individual line of the build description and show it. That would allow the main screen to show a build progress indicator provided by the job itself. Add Comment
[JIRA] [core] (JENKINS-31209) Make the length of the build description display user settable
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-31209 Make the length of the build description display user settable Issue Type: Improvement Assignee: Unassigned Components: core Created: 28/Oct/15 2:12 AM Priority: Minor Reporter: Nathan Neulinger Right now, the build description gets truncated with ... at the end if too long. Would like to see two options in the configure jenkins screen: 1. Truncate build description at (X) Beginning ( ) End 2. Maximum length of build description to show in build history [ ] Add Comment
[JIRA] [core] (JENKINS-31207) UI improvement for console log view - show beginning of log when skipping
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-31207 UI improvement for console log view - show beginning of log when skipping Issue Type: Improvement Assignee: Unassigned Components: core Created: 28/Oct/15 1:16 AM Priority: Minor Reporter: Nathan Neulinger When viewing a console log of builds - it is often useful to see the start of the log, and skip in the middle - not just skip from the start of the log. Such as to quickly see revision numbers, what agent it's building up, upstream jobs, etc. It would be nice if the 'skipped' view would show the first 20-40 lines of the file, then skip to wherever it picks up again. Even better would be to show the first and last 15-20 lines of build output from every build step, but that's likely a lot more complicated. Even better than that would be if it supported folding the output like teamcity (one of the few things I liked better about TC) - but that's just a pipe dream. First step - please modify the skipped log screen to show the beginning of the build log before skipping lines.
[JIRA] [core] (JENKINS-31140) Suggestion - add a "lastBuild" link in the builds tree
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-31140 Suggestion - add a "lastBuild" link in the builds tree Issue Type: Improvement Assignee: Unassigned Components: core Created: 23/Oct/15 4:45 PM Priority: Minor Reporter: Nathan Neulinger Went to go look at a bunch of jobs and noticed that there was no 'last build' link, only individual for last successful and last failed. Seems like a trivial addition to add a common 'lastBuild' one as well. Add Comment
[JIRA] [core] (JENKINS-31082) Would like to see the ability to adjust "smart" scheduling on a per job basis
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-31082 Would like to see the ability to adjust "smart" scheduling on a per job basis Issue Type: Improvement Assignee: Unassigned Components: core Created: 21/Oct/15 12:32 PM Priority: Minor Reporter: Nathan Neulinger I frequently have situations where a set of intense builds wind up getting placed on the same agent (of several in a farm). This is not ideal since the other nodes are idle. It is more efficient from a IO/transfer standpoint, but not as ideal from a load distribution standpoint. I'd like to be able to have a checkbox or selection next to the tied label for a job to say "Spread load evenly across labelled nodes" - where it would completely ignore previous build attempts and always place the build on the least loaded node that matched the label. Could go one step further and just have a selectable "Node selection strategy: " that would be used if more than one node matched the label. Add Comment
[JIRA] [core] (JENKINS-30956) Disable instead of hiding 'Build Now' link when disabled
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-30956 Disable instead of hiding 'Build Now' link when disabled Issue Type: Improvement Assignee: Unassigned Components: core Created: 14/Oct/15 4:35 PM Labels: ui Priority: Minor Reporter: Nathan Neulinger On a deployment with a lot of jobs, I've found in a number of cases that it's very handy to bounce on middle click and control-tab to quickly open a bunch of tabs to then bring up configuration page/etc. One flaw to this is that if any of the jobs are disabled, it changes the arrangement of links in the left side pane. Suggestion is - instead of removing the 'Build Now' or 'Build with Properties' links - gray out/disable the link instead. Then the positioning of items in the list stays more consistent. (And yes, I'm aware of config slicing - it doesn't work for everything.)
[JIRA] [exclusion-plugin] (JENKINS-30879) Exclusion plugin does not handle a single job listing same resource multiple times
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-30879 Exclusion plugin does not handle a single job listing same resource multiple times Issue Type: Bug Assignee: Unassigned Components: exclusion-plugin Created: 10/Oct/15 11:28 PM Priority: Minor Reporter: Nathan Neulinger It's not entirely clear if this should work, but seems like it should be detected as a deadlock if job X #Y is waiting on resource held by job X #Y. Add Comment
[JIRA] [exclusion-plugin] (JENKINS-30877) Exclusion admin panel doesn't work right with dynamic resource names
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-30877 Exclusion admin panel doesn't work right with dynamic resource names Issue Type: Bug Assignee: Unassigned Components: exclusion-plugin Created: 10/Oct/15 2:16 PM Priority: Minor Reporter: Nathan Neulinger The exclusion plugin itself seems to work great with dynamic resources pulled from properties/environment variables, but the admin panel just shows $VAR_NAME. Add Comment
[JIRA] [exclusion-plugin] (JENKINS-12399) Dynamic exclusion resourced based on parameter name
Title: Message Title Nathan Neulinger commented on JENKINS-12399 Re: Dynamic exclusion resourced based on parameter name I think this is actually working - or at least it is for me - specifying an environment variable name in the resource like "host-$DYNAMIC_JOB_TEST_HOST" 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-30775) Please add support for the "Abort build if stuck" fields of Build-timeout plugin
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-30775 Please add support for the "Abort build if stuck" fields of Build-timeout plugin Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: build-timeout-plugin, configurationslicing-plugin Created: 02/Oct/15 8:28 PM Priority: Minor Reporter: Nathan Neulinger Would be really nice to be able to use config slicer with these config elements. here's for an 'absolute' timeout: 40 Add Comment
[JIRA] [core] (JENKINS-30758) Add ability to hide/collapse idle runners
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-30758 Add ability to hide/collapse idle runners Issue Type: Improvement Assignee: Unassigned Components: core Created: 02/Oct/15 4:00 AM Priority: Minor Reporter: Nathan Neulinger If you have a bunch of nodes - many with lots of slots - the main screen ui tends to be filled with large numbers of "Idle" entries. Would be nice to have a checkbox or setting to have the list collapsed by default, such as: Instead of: node1: 1 Idle 2 Idle 3 Idle 4 JobX 5 Idle 6 Idle Display as: node1: 1,2,3,5,6 Idle 4 JobX or 1,2,3 Idle 4 JobX 5,6 Idle or 4 JobX [5] Idle Add Comment
[JIRA] [multiple-scms-plugin] (JENKINS-30709) SCM env vars for multiple scm's plugin not useful with multiple git repos
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-30709 SCM env vars for multiple scm's plugin not useful with multiple git repos Issue Type: Bug Assignee: Kevin Bell Components: multiple-scms-plugin Created: 29/Sep/15 9:21 PM Environment: fc20 jenkins 1.620 Priority: Minor Reporter: Nathan Neulinger If you have multiple git repos specified in project, the environment variables for revision/etc are only populated from the last one, so there is no good way to get the details of the revisions except by having build steps extract it themselves with git commands. Add Comment
[JIRA] [managed-scripts-plugin] (JENKINS-30476) Bad link in config element for managed-scripts plugin when jenkins in subdir
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-30476 Bad link in config element for managed-scripts plugin when jenkins in subdir Issue Type: Bug Assignee: Dominik Bartholdi Components: managed-scripts-plugin Created: 16/Sep/15 12:08 AM Priority: Minor Reporter: Nathan Neulinger If you have jenkins hosted at /jenkins, the managed scripts plugin generates a link to "/configfiles" in it's error message if you don't have any defined instead of to "/jenkins/configfiles". Add Comment
[JIRA] [template-project-plugin] (JENKINS-30436) template proxy/proxyscm does not output useful error if source project name doesn't exist
Title: Message Title
Nathan Neulinger created an issue
Jenkins / JENKINS-30436
template proxy/proxyscm does not output useful error if source project name doesn't exist
Issue Type:
Bug
Assignee:
huybrechts
Components:
template-project-plugin
Created:
14/Sep/15 12:33 PM
Priority:
Minor
Reporter:
Nathan Neulinger
If proxy scm is set to point to a project that no longer exists (i.e. rename or delete) - the job execution just fails with:
{{2015-09-14 05:25:09.820 | FATAL: null 2015-09-14 05:25:09.820 | java.lang.NullPointerException 2015-09-14 05:25:09.820 | at hudson.plugins.templateproject.ProxySCM.checkout(ProxySCM.java:91) 2015-09-14 05:25:09.821 | at hudson.scm.SCM.checkout(SCM.java:485) 2015-09-14 05:25:09.821 | at hudson.model.AbstractProject.checkout(AbstractProject.java:1282) 2015-09-14 05:25:09.821 | at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610) 2015-09-14 05:25:09.821 | at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) 2015-09-14 05:25:09.821 | at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532) 2015-09-14 05:25:09.821 | at hudson.model.Run.execute(Run.java:1741) 2015-09-14 05:25:09.821 | at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 2015-09-14 05:25:09.821 | at hudson.model.ResourceController.execute(ResourceController.java:98) 2015-09-14 05:25:09.821 | at hudson.model.Executor.run(Executor.java:381)}}
Would be better to specifically check for that scenario and output a useful error message.
[JIRA] [template-project-plugin] (JENKINS-30435) Renaming project doesn't update references in proxy scm configuration
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-30435 Renaming project doesn't update references in proxy scm configuration Issue Type: Bug Assignee: huybrechts Components: template-project-plugin Created: 14/Sep/15 12:31 PM Priority: Minor Reporter: Nathan Neulinger Renamed projects, noticed that afterwards one of my other jobs was failing due to the job name reference in the "Use SCM from another project" field pointing to the old project name. Add Comment
[JIRA] [copyartifact-plugin] (JENKINS-30428) Would like to user CopyArtifact to drive other actions
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-30428 Would like to user CopyArtifact to drive other actions Issue Type: New Feature Assignee: Unassigned Components: copyartifact-plugin Created: 12/Sep/15 9:15 PM Priority: Minor Reporter: Nathan Neulinger CopyArtifact works great for it's primary function. However, if you're trying to work toward avoiding actually using jenkins artifact copying/transfer code (due to it being slow or wanting to avoid data IO from the master) - it isn't directly useful. What I'd be very interested in would be some way to leverage the plugin for it's upstream project detection/file analysis/etc - but not actually do the copying. Here's two things that I believe would be easy improvements that would allow it to be used this way: 1. Add a checkbox to the build step: "Detect only, do not copy file." 2. Add an additional environment variable COPYARTIFACT_BUILD_PROJECT_%s functioning equivalently to the COPYARTIFACT_BUILD_NUMBER_%s except providing the name of the upstream project that was pulled from. The combination of these two would allow using all of CopyArtifact's detection/etc. functions, but I could instead hook in a shell build step and use the environment variables to more efficiently transfer the files, including options like leveraging a local cache/etc. I think it would be great to go beyond this and have a plugin that could get info about the upstream build, contents, etc. and ma
[JIRA] [copyartifact-plugin] (JENKINS-30428) Would like to use CopyArtifact to drive other actions
Title: Message Title Nathan Neulinger updated an issue Jenkins / JENKINS-30428 Would like to use CopyArtifact to drive other actions Change By: Nathan Neulinger Summary: Would like to user use CopyArtifact to drive other actions 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-29807) NullPointerException when triggering dependent builds
Title: Message Title Nathan Neulinger commented on JENKINS-29807 Re: NullPointerException when triggering dependent builds Sorry, actually, I DID have a disabled build... just missed it when reviewing the config. 1.620 definitely worked again for me as well. 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-29807) NullPointerException when triggering dependent builds
Title: Message Title Nathan Neulinger commented on JENKINS-29807 Re: NullPointerException when triggering dependent builds I'm seeing this same symptom/trace - however, I do NOT have a disabled build. Also tried with 1.627 with no luck, rolling back to 1.620 now to see if that works. 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] [git-client-plugin] (JENKINS-26748) Git plugin sometimes reports Could not checkout null with start point
Title: Message Title Nathan Neulinger commented on JENKINS-26748 Re: Git plugin sometimes reports Could not checkout null with start point Previously had 1.17.1 / 2.3.5 installed. Applied the referenced pre-release builds above. I suppose it's possible that it hasn't actually fixed it, and we just haven't triggered the problem again Seems like it's triggered when the devs do force pushes of branches. 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] [git-client-plugin] (JENKINS-26748) Git plugin sometimes reports Could not checkout null with start point
Title: Message Title Nathan Neulinger commented on JENKINS-26748 Re: Git plugin sometimes reports Could not checkout null with start point So far, indications are that this has resolved the issue. Any idea when the fix will be in the update repository? 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] [git-client-plugin] (JENKINS-26748) Git plugin sometimes reports Could not checkout null with start point
Title: Message Title Nathan Neulinger commented on JENKINS-26748 Re: Git plugin sometimes reports Could not checkout null with start point We're seeing this problem (likely due to some dev teams frequently force pushing). Trying the binaries you listed in comment above. 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-29116) Request for UI improvent - scroll to top on login form
Title: Message Title Nathan Neulinger commented on JENKINS-29116 Re: Request for UI improvent - scroll to top on login form From a quick test - simply adding "#" to the login link is sufficient to improve the behavior as described. 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-29116) Request for UI improvent - scroll to top on login form
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-29116 Request for UI improvent - scroll to top on login form Issue Type: Improvement Assignee: Unassigned Attachments: login-1.png, login-2.png Components: core Created: 28/Jun/15 1:58 AM Labels: login authentication auth ui Priority: Minor Reporter: Nathan Neulinger Right now, if you have more than a screen worth of build agents - when you click to log in, the login form is almost always above the fold. Please consider either: A) forcing the login link to include an anchor reference above the login form B) center the login form vertically C) trigger a vertical scroll to the top of the page
[JIRA] [configurationslicing-plugin] (JENKINS-28771) Slicing UI available for regular users, but only visible in 'Manage Jenkins'
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-28771 Slicing UI available for regular users, but only visible in 'Manage Jenkins' Issue Type: Bug Assignee: mdonohue Components: configurationslicing-plugin Created: 05/Jun/15 1:55 PM Priority: Minor Reporter: Nathan Neulinger A regular user can go to the configuration slicing UI via direct URL, but if they don't have access to 'Manage Jenkins' they can't see the link to it. Seems like this is either an oversight (if they SHOULD have that ability), or a security issue (if only admins are supposed to be able to use the plugin). If it's intended to be available to users that can edit the jobs and not just admins - consider making the config slicing link available in the main jenkins menu so that others can see it. If not, please fix the security/access checks. Even better - integrate w/ matrix auth plugin as it's own specific permission. Add Comment
[JIRA] [core] (JENKINS-28278) Environment variables "stuck" on windows slave
Title: Message Title Nathan Neulinger commented on JENKINS-28278 Re: Environment variables "stuck" on windows slave Unfortunately, I do not know how long this has been an issue and am not currently in a position to try and roll back for testing. I do wonder though - is it only windows, or is it anything launched with JNLP/WebStart/Client initiated? If the latter, it should be significantly easier to test for. All my linux slaves start with SSH, so never really came up there. 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] [windows-slaves-plugin] (JENKINS-28278) Environment variables "stuck" on windows slave
Title: Message Title Nathan Neulinger commented on JENKINS-28278 Re: Environment variables "stuck" on windows slave Just to be clear though, "restart master =~ clear cache" and not a permanent 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] [crowd2-plugin] (JENKINS-17957) Crowd plugin - "remember me" doesn't work
Title: Message Title Nathan Neulinger commented on JENKINS-17957 Re: Crowd plugin - "remember me" doesn't work Any update on this? Would sure be nice to have my users stop complaining about their login sessions randomly being lost on Jenkins. 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] [windows-slaves-plugin] (JENKINS-28278) Environment variables "stuck" on windows slave
Title: Message Title Nathan Neulinger updated an issue Jenkins / JENKINS-28278 Environment variables "stuck" on windows slave Change By: Nathan Neulinger Component/s: envinject-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] [envinject-plugin] (JENKINS-28278) Environment variables "stuck" on windows slave
Title: Message Title Nathan Neulinger updated an issue Jenkins / JENKINS-28278 Environment variables "stuck" on windows slave Change By: Nathan Neulinger Component/s: envinject-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] [envinject-plugin] (JENKINS-28278) Environment variables "stuck" on windows slave
Title: Message Title Nathan Neulinger updated an issue Jenkins / JENKINS-28278 Environment variables "stuck" on windows slave Change By: Nathan Neulinger Priority: Minor Major 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] [envinject-plugin] (JENKINS-28278) Environment variables "stuck" on windows slave
Title: Message Title Nathan Neulinger commented on JENKINS-28278 Re: Environment variables "stuck" on windows slave Glad to see someone else is seeing it and it's not just my imagination. Until I found this it was a complete brain stumper trying to figure out what was going on since the symptom/behavior made no sense whatsoever. I don't know whether it's something with the remote connection or with the environment setting plugin. Out of curiosity - do you have the EnvInject plugin installed as well? 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] [windows-slaves-plugin] (JENKINS-28278) Environment variables "stuck" on windows slave
Title: Message Title Nathan Neulinger commented on JENKINS-28278 Re: Environment variables "stuck" on windows slave Been able to reproduce this several times now. Changes to environment variables are only taking place for a windows jnlp slave if I delete the node and recreate it. Anything else and the vars "stick". I've tried completely deleting java cache on slave as well, no effect. Any ideas? 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] [windows-slaves-plugin] (JENKINS-28278) Environment variables "stuck" on windows slave
Title: Message Title Nathan Neulinger created an issue Jenkins / JENKINS-28278 Environment variables "stuck" on windows slave Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: windows-slaves-plugin Created: 07/May/15 3:59 AM Priority: Minor Reporter: Nathan Neulinger Finally tracked down a really perplexing problem I've been having with some windows slaves. It appears that somehow - the slaves are getting "stuck" with a particular set of environment variables. No amount of reconfiguration of the windows box - switching user it runs as, running interactively, etc. would change it. The only thing I found that cleared it up is completely deleting the slave from jenkins node list, and re-adding it - then it finally reset what environment variables would be present on the slave. Note - I didn't do ANYTHING other than changing the 'secret' value on the windows box. i.e. I did not reinstall service, relaunch from the nodes list, etc. - just changed the secret that it used to connect with. Is this something obvious that I'm missing in how windows slaves are supposed to behave? Slave is being launched with java web start.
[JIRA] [timestamper-plugin] (JENKINS-28226) Add a "display in UTC" option
Title: Message Title
Nathan Neulinger created an issue
Jenkins / JENKINS-28226
Add a "display in UTC" option
Issue Type:
New Feature
Assignee:
stevengbrown
Components:
timestamper-plugin
Created:
05/May/15 2:12 AM
Priority:
Minor
Reporter:
Nathan Neulinger
You already have a use browser timezone feature (pull request #11) - and have option to display with server timezone. It would be really handy to have a "display in UTC" option.
Minor suggestion at same time (though should probably be in different request) - none of the options actually display the timezone itself. That would be a nice addition.
( ) System clock time ( ) System time {PDT}
( ) Use browser timezone {CDT}
( ) UTC ( ) Elapsed ... ...
Add Comment
[JIRA] [git-plugin] (JENKINS-27211) Please add ability to use the git 'clean' options AFTER job execution
Nathan Neulinger commented on JENKINS-27211 Please add ability to use the git 'clean' options AFTER job execution That's true, for the 'delete' case. However, it's a lot easier to universally say "Hey, if you have a job, mark it to 'git clean' at the end of the job if the job is successful". That takes care of most of the build scenarios where the content of the job is much larger than the repo. It looks like I could rig up something with: https://wiki.jenkins-ci.org/display/JENKINS/Global+Post+Script+Plugin Just seems like this would be much easier to have here since it's already controlling that cleanup process during init, and it's already aware of each of the clone paths in the job. 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] [git-plugin] (JENKINS-27211) Please add ability to use the git 'clean' options AFTER job execution
Nathan Neulinger commented on JENKINS-27211 Please add ability to use the git 'clean' options AFTER job execution I can clean the whole workspace, but that just means the inefficiency of updating the clone from repo server again. 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] [git-plugin] (JENKINS-27211) Please add ability to use the git 'clean' options AFTER job execution
Nathan Neulinger commented on JENKINS-27211 Please add ability to use the git 'clean' options AFTER job execution In my case it's from developers that don't clean up after themselves and leave numerous very large/bloated builds sitting around. Particularly when they create new jobs, and then delete them - since jenkins doesn't seem to clean any of that up out on the agents. 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] [git-plugin] (JENKINS-27211) Please add ability to use the git 'clean' options AFTER job execution
Nathan Neulinger
created JENKINS-27211
Please add ability to use the git 'clean' options AFTER job execution
Issue Type:
Improvement
Assignee:
Nicolas De Loof
Components:
git-plugin
Created:
03/Mar/15 1:10 AM
Description:
I would love to be able to have my jobs automatically return the workspace to a clean state after execution - but otherwise leave the cloned repo present at the end of a job automatically. I could do this myself in a post step, but seems like it would be nice to be able to just define this in the SCM section and have it done automatically.
Even better would be ability to say "Clean after job, if: {stable|unstable|failed}" - to allow leaving the workspace around for examination if the job fails, but otherwise clean when done.
Project:
Jenkins
Priority:
Minor
Reporter:
Nathan Neulinger
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] [git-plugin] (JENKINS-26868) Add "repack after cloning" option to the 'reference' support in git clone
Nathan Neulinger commented on JENKINS-26868 Add "repack after cloning" option to the 'reference' support in git clone Cool. That's a nice additional option in git. Sounds like it does equivalent to running a git repack -a afterwards, but probably a lot more efficient. Unfortunately, it'll be a while before 2.3 is available on many of the build agent systems, where 'git repack -a' works now. I'm just looking for something that would remove the dependency on the referenced repo after the cloning - to use it purely as a cache and not for live use. (Would be even nicer if the git plugin had some way of caching the repo on the master, but that's a major functionality change.) Seems like a checkbox to repack would be easy/simple way to accomplish that. 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] [git-plugin] (JENKINS-26868) Add "repack after cloning" option to the 'reference' support in git clone
Nathan Neulinger created JENKINS-26868 Add "repack after cloning" option to the 'reference' support in git clone Issue Type: New Feature Assignee: Nicolas De Loof Components: git-plugin Created: 09/Feb/15 10:58 PM Description: I like using the --reference support in the additional clone options to provide a pre-cache for a remote git server, but would prefer that the cloned repositories not have the persistent 'alternates' referenced - even though the remotes are read only. Would like to see a checkbox in the 'Additional Clone Behaviors' config section for the reference to say "Repack after Clone" to run 'git repack -a'. This would obviously negate space savings, but still accomplishes the goal of avoiding network transfer when the primary repository is on a remote slow link. Project: Jenkins Priority: Minor Reporter: Nathan Neulinger 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] [vsphere-cloud-plugin] (JENKINS-26832) Please add a 'reconfigure' mode for 'change attached CD rom'
Nathan Neulinger created JENKINS-26832 Please add a 'reconfigure' mode for 'change attached CD rom' Issue Type: New Feature Assignee: Unassigned Components: vsphere-cloud-plugin Created: 06/Feb/15 2:39 PM Description: Would very much like to be able to control the ISO attachment from datastores via this plugin. Project: Jenkins Priority: Minor Reporter: Nathan Neulinger This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-25934) Add ability to set a comment with any installed plugin or "lock" a plugin
Nathan Neulinger created JENKINS-25934 Add ability to set a comment with any installed plugin or "lock" a plugin Issue Type: New Feature Assignee: Unassigned Components: core Created: 05/Dec/14 2:52 PM Description: Been bit several times recently by accidentially upgrading Mercurial plugin, which triggers JENKINS-25523 error. This has also hurt me in past with some other plugins. It would be really nice to be able to do one of the following: 1. Set a comment/NOTE that would be displayed next to any installed plugin so that I could put a warning to myself "DO NOT UPGRADE - breaks compatability with X" next to a plugin that I know cannot be upgraded, or other comments about the plugin such as if I'm trying to make notes about where certain plugins are used. or 2. Allow "locking" a plugin so that it cannot be upgraded unless I unlock it first. Project: Jenkins Priority: Minor Reporter: Nathan Neulinger 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] [jacoco] (JENKINS-23708) Unable to view JaCoCo report and history graph
Nathan Neulinger commented on JENKINS-23708 Unable to view JaCoCo report and history graph We are seeing this symptom also. Haven't tried the fix (not set up to build jenkins module code) though. Tobias, would you share your .jpi file? 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] [maven] (JENKINS-21144) Is there any way to disable/prevent use of the built-in maven job types?
Nathan Neulinger reopened JENKINS-21144 Is there any way to disable/prevent use of the built-in maven job types? Change By: Nathan Neulinger (20/Aug/14 6:00 PM) Resolution: Not A Defect Status: Resolved Reopened 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] [maven] (JENKINS-21144) Is there any way to disable/prevent use of the built-in maven job types?
Nathan Neulinger commented on JENKINS-21144 Is there any way to disable/prevent use of the built-in maven job types? Doesn't that also disable the ability to use the auto provisioning of maven itself? I don't want to disable ability to use "Invoke Maven 3" target, just the "maven" job type. 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.
