[JIRA] (JENKINS-33285) Old jenkins versions are not listed in Debian repository Packages.gz
Title: Message Title Kohsuke Kawaguchi updated JENKINS-33285 Jenkins / JENKINS-33285 Old jenkins versions are not listed in Debian repository Packages.gz Change By: Kohsuke Kawaguchi Status: Open Fixed but Unreleased Resolution: Fixed 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-33285) Old jenkins versions are not listed in Debian repository Packages.gz
Title: Message Title Kohsuke Kawaguchi updated JENKINS-33285 Jenkins / JENKINS-33285 Old jenkins versions are not listed in Debian repository Packages.gz Change By: Kohsuke Kawaguchi Status: Fixed but Unreleased Resolved 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-33285) Old jenkins versions are not listed in Debian repository Packages.gz
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-33285 Re: Old jenkins versions are not listed in Debian repository Packages.gz I came across this old issue that I happened to confirm has been fixed since then. 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-52868) Windows packaging embeds 32bit Java, and it makes process management malfunctional on 64bit systems
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-52868 Re: Windows packaging embeds 32bit Java, and it makes process management malfunctional on 64bit systems Cool, you are way ahead of me! Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-52868) Windows packaging embeds 32bit Java, and it makes process management malfunctional on 64bit systems
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-52868 Re: Windows packaging embeds 32bit Java, and it makes process management malfunctional on 64bit systems The last time I checked, which is admittedly years ago, bulk of the Windows users were still running 32bit Windows. Did that situation change? Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51447) Unable to download 2.123 war to upgrade Jenkins
Title: Message Title Kohsuke Kawaguchi resolved as Fixed Jenkins / JENKINS-51447 Unable to download 2.123 war to upgrade Jenkins Change By: Kohsuke Kawaguchi Status: Reopened Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-51447) Unable to download 2.123 war to upgrade Jenkins
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-51447 Re: Unable to download 2.123 war to upgrade Jenkins A recent change to the core interacted badly with the release process and killed 2.123. The fix is made and 2.124 was subsequently released. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41319) Not compatible with Pipeline restart feature
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41319 Re: Not compatible with Pipeline restart feature I talked to Nicolas De Loof and he's making good progress, but still more work to do. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41319) Not compatible with Pipeline restart feature
Title: Message Title Kohsuke Kawaguchi reopened an issue Jenkins / JENKINS-41319 Not compatible with Pipeline restart feature Change By: Kohsuke Kawaguchi Resolution: Won't Fix Status: Closed Reopened Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41319) Not compatible with Pipeline restart feature
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41319 Re: Not compatible with Pipeline restart feature Met with Nicolas De Loof and Jesse Glick today to discuss the way forward. During the meeting, we discussed relevant part of the code and a possible way to fix this. I think that gave Nicolas some directions and ideas and he is going to give it some more shot. The current plan is for me to check back in with Nicolas later this week, and if it doesn't work out, put this to the OSS team's queue and ask Jesse to look into this. Jesse is more optimistic that this is fixable, just that he currently lacks the context of one-shot-executor. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-41770) CPS serialization failure doesn't provide useful information
Title: Message Title Kohsuke Kawaguchi updated an issue Jenkins / JENKINS-41770 CPS serialization failure doesn't provide useful information Change By: Kohsuke Kawaguchi Labels: kohsuke-plane-project 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-26137) Mysterious serialization errors
Title: Message Title Kohsuke Kawaguchi updated an issue Jenkins / JENKINS-26137 Mysterious serialization errors Change By: Kohsuke Kawaguchi Labels: kohsuke-plane-project robustness 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-41196) Pluggable core component
Title: Message Title Kohsuke Kawaguchi updated an issue Jenkins / JENKINS-41196 Pluggable core component Change By: Kohsuke Kawaguchi h1. ProblemsThere are quite a few libraries that core bundles. Some of them, such as remoting, stapler, and so on, are heavily used by plugins and systems we build on top of Jenkins core, such as Blue Ocean.This situation creates a class of pain for those plugins; when they need a newer feature or a bug fix in those libraries, they have to wait for multiple months before the change propagates to a version of LTS.h1. SolutionIf we can modify Jenkins core such that it allows any of its libraries to be shipped as plugins, then this would eliminate this class of pain altogether. h1. Requirements* In plugin manifest, BO can specify the minimum core version that bundles one version of stapler, then the version of stapler it requires separately, and the latter is newer than the former* Jenkins admin can install a new remoting plugin in order to deploy a security fix without upgrading the whole Jenkins.* From users’ & administrators’ perspective, “stapler plugin” and “remoting” plugin looks no different from “git plugin” and “promoted builds plugin.”* In a running Jenkins JVM, there’s only one version of stapler or remoting active at any given moment.* Spend a reasonable engineering effort to make Jenkins robust in the face of administrators installing wrong set of plugins, old plugins, and other such situations that arise from our weak plugin manager, incompetent users, and so on.h1. Engineering DesignToday, jenkins.war puts core and all its dependencies in WEB-INF/lib and let servlet container classloader load them all. This results in a fully populated classloader by the time Jenkins core boots up, and it makes it impossible for Jenkins to programmatically control versions of libraries to use.We can change this if Jenkins creates its own classloader during bootstraps, and uses its own logic to decide what jar files to put in there; mix and match from jenkins.war and $JENKINS_HOME.More specifically, we move everything from WEB-INF/lib to WEB-INF/jars, so that core and its dependencies are not loaded by servlet container automatically. Then place small bootstrap code in WEB-INF/lib instead, which creates a classloader that loads core, then passes on execution to hudson.WebAppMain.In order to allow newer versions of components to be delivered as plugins, this bootstrap process will also pick up some files from $JENKINS_HOME/plugins. The likes of remoting/stapler plugins need to have a flag in them, so that the bootstrap process can put them in the main classloader, while others like git & promoted builds are treated the same as today.Bootstrap code needs to be small and with as little dependencies as possible, so core component plugins need to be different enough from regular plugins. At the same time, they need to look similar enough so that our update center and plugin manager can treat them equally. A boolean entry in MANIFEST.MF would be one example that meets
[JIRA] (JENKINS-41196) Pluggable core component
Title: Message Title Kohsuke Kawaguchi updated an issue Jenkins / JENKINS-41196 Pluggable core component Change By: Kohsuke Kawaguchi h1. ProblemsThere are quite a few libraries that core bundles. Some of them, such as remoting, stapler, and so on, are heavily used by plugins and systems we build on top of Jenkins core, such as Blue Ocean.This situation creates a class of pain for those plugins; when they need a newer feature or a bug fix in those libraries, they have to wait for multiple months before the change propagates to a version of LTS.h1. SolutionIf we can modify Jenkins core such that it allows any of its libraries to be shipped as plugins, then this would eliminate this class of pain altogether. h1. Requirements* In plugin manifest, BO can specify the minimum core version that bundles one version of stapler, then the version of stapler it requires separately, and the latter is newer than the former* Jenkins admin can install a new remoting plugin in order to deploy a security fix without upgrading the whole Jenkins.* From users’ & administrators’ perspective, “stapler plugin” and “remoting” plugin looks no different from “git plugin” and “promoted builds plugin.”* In a running Jenkins JVM, there’s only one version of stapler or remoting active at any given moment.* Spend a reasonable engineering effort to make Jenkins robust in the face of administrators installing wrong set of plugins, old plugins, and other such situations that arise from our weak plugin manager, incompetent users, and so on.h1. Engineering DesignToday, jenkins.war puts core and all its dependencies in WEB-INF/lib and let servlet container classloader load them all. This results in a fully populated classloader by the time Jenkins core boots up, and it makes it impossible for Jenkins to programmatically control versions of libraries to use.We can change this if Jenkins creates its own classloader during bootstraps, and uses its own logic to decide what jar files to put in there; mix and match from jenkins.war and $JENKINS_HOME.More specifically, we move everything from WEB-INF/lib to WEB-INF/jars, so that core and its dependencies are not loaded by servlet container automatically. Then place small bootstrap code in WEB-INF/lib instead, which creates a classloader that loads core, then passes on execution to hudson.WebAppMain.In order to allow newer versions of components to be delivered as plugins, this bootstrap process will also pick up some files from $JENKINS_HOME/plugins. The likes of remoting/stapler plugins need to have a flag in them, so that the bootstrap process can put them in the main classloader, while others like git & promoted builds are treated the same as today.Bootstrap code needs to be small and with as little dependencies as possible, so core component plugins need to be different enough from regular plugins. At the same time, they need to look similar enough so that our update center and plugin manager can treat them equally. A boolean entry in MANIFEST.MF would be one example that meets
[JIRA] (JENKINS-41196) Pluggable core component
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41196 Re: Pluggable core component My latest airplane project arrives 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-42159) Winstone doesn't exit when boot catastrophically fails
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-42159 Winstone doesn't exit when boot catastrophically fails Issue Type: Improvement Assignee: Kohsuke Kawaguchi Components: winstone-jetty Created: 2017/Feb/17 7:13 PM Priority: Minor Reporter: Kohsuke Kawaguchi When java -jar jenkins.war catastrophically fails, such as when ServletContextListener fails and the webapp fails to boot, Winstone keeps running without serving anything. If the sole webapp fails to deploy, it should terminate with an error message instead. Add Comment
[JIRA] (JENKINS-42159) Winstone doesn't exit when boot catastrophically fails
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-42159 Re: Winstone doesn't exit when boot catastrophically fails I found this while working on JENKINS-41196. 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-41770) CPS serialization failure doesn't provide useful information
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41770 Re: CPS serialization failure doesn't provide useful information Note to myself. At the end of the stack trace, the object graph traversal is buggy because it only records fields and not instances that are visited. 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-41755) Background 'sh' invocation
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41755 Re: Background 'sh' invocation Posted the PR 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-41755) Background 'sh' invocation
Title: Message Title
Kohsuke Kawaguchi created an issue
Jenkins / JENKINS-41755
Background 'sh' invocation
Issue Type:
Improvement
Assignee:
Kohsuke Kawaguchi
Components:
workflow-durable-task-step-plugin
Created:
2017/Feb/06 11:30 AM
Priority:
Major
Reporter:
Kohsuke Kawaguchi
In an attempt to make Android emulator plugin pipeline-enabled, Christopher Orr and I felt it would be nice if the sh step supports background task invocation. That is, {{sh} step returns immediately with some object that represents the process, with some methods on it to interact with it. This would be used to run Android emulator in the background in such a way that its lifespan is tied to a pipeline build and not affected by a loss of master/agent/communication.
Add Comment
[JIRA] (JENKINS-41349) Post-FOSDEM 2017 Hackathon
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41349 Re: Post-FOSDEM 2017 Hackathon Hackathon live doc is http://bit.ly/2kcvceb 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-41743) Gitlab org folder support
Title: Message Title Kohsuke Kawaguchi assigned an issue to Kohsuke Kawaguchi Jenkins / JENKINS-41743 Gitlab org folder support Change By: Kohsuke Kawaguchi Assignee: Robin Müller Kohsuke Kawaguchi 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-41743) Gitlab org folder support
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-41743 Gitlab org folder support Issue Type: Improvement Assignee: Robin Müller Components: gitlab-plugin Created: 2017/Feb/06 8:35 AM Priority: Major Reporter: Kohsuke Kawaguchi During FOSDEM, a number of people walked up to us and wanted to see the org folder support for GitLab. Internally, this means we need to write gitlab branch source, either as a separate plugin or in the existing plugin Add Comment This message
[JIRA] (JENKINS-41413) no downloads for Windows
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41413 Re: no downloads for Windows I'm recreating 2.42 installer. 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-41413) no downloads for Windows
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41413 Re: no downloads for Windows The root cause of the problem was cygwin failing to fork a process, resulting in a failed installer build: rm -rf tmp 490 [main] bash 4848 child_info_fork::abort: c:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x185) != child(0x176) build.sh: fork: retry: No child processes 229 [main] bash 4780 child_info_fork::abort: c:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x185) != child(0x181) build.sh: fork: retry: No child processes 207 [main] bash 4188 child_info_fork::abort: c:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x185) != child(0x17E) build.sh: fork: retry: No child processes 0 [main] bash 6028 child_info_fork::abort: c:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x185) != child(0x73) build.sh: fork: retry: No child processes 295 [main] bash 2384 child_info_fork::abort: c:\cygwin\bin\cygiconv-2.dll: Loaded to different address: parent(0x185) != child(0x170) build.sh: fork: Resource temporarily unavailable This problem was masked by a script that skipped MSI build upon a manual retry. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are
[JIRA] (JENKINS-41413) no downloads for Windows
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41413 Re: no downloads for Windows Also in https://github.com/jenkinsci/packaging/pull/90 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-41413) no downloads for Windows
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41413 Re: no downloads for Windows Fix in https://github.com/jenkinsci/distfork-plugin/pull/6 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-41196) Pluggable core component
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-41196 Pluggable core component Issue Type: Improvement Assignee: Unassigned Components: core Created: 2017/Jan/19 1:55 AM Priority: Major Reporter: Kohsuke Kawaguchi Problems There are quite a few libraries that core bundles. Some of them, such as remoting, stapler, and so on, are heavily used by plugins and systems we build on top of Jenkins core, such as Blue Ocean. This situation creates a class of pain for those plugins; when they need a newer feature or a bug fix in those libraries, they have to wait for multiple months before the change propagates to a version of LTS. Solution If we can modify Jenkins core such that it allows any of its libraries to be shipped as plugins, then this would eliminate this class of pain altogether. Add Comment
[JIRA] (JENKINS-41196) Pluggable core component
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41196 Re: Pluggable core component For my internal tracking purpose, the original document is here 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-37987) Image.inside fails for images specifying ENTRYPOINT
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-37987 Re: Image.inside fails for images specifying ENTRYPOINT Since Jesse is rather terse in his comment, what he really means is that the regression people reported is currently tracked as JENKINS-39748, so if you are affected by this, please follow that issue. 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-41121) GitHub Branch Source upgrade can cause a lot of rebuilds
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-41121 Re: GitHub Branch Source upgrade can cause a lot of rebuilds Current status: new metadata got generated, and waiting for mirrors to pick them up 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-39951) "java -jar jenkins.war --httpPort 8080" fails with a stack trace
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-39951 "java -jar jenkins.war --httpPort 8080" fails with a stack trace Issue Type: Bug Assignee: Unassigned Components: winstone-jetty Created: 2016/Nov/23 12:06 AM Priority: Minor Reporter: Kohsuke Kawaguchi User error like this shouldn't result in a stack trace, yet this is the output you get: % java -jar jenkins.war --httpPort 8080 Running from: /home/kohsuke/ws/jenkins/jenkins/war/target/jenkins.war webroot: $user.home/.jenkins Nov 22, 2016 4:06:19 PM Main deleteWinstoneTempContents WARNING: Failed to delete the temporary Winstone file /tmp/winstone/jenkins.war Exception in thread "main" java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at Main._main(Main.java:264) at Main.main(Main.java:112) Caused by: java.lang.IllegalArgumentException: Expecting httpPort=VALUE but found no value at winstone.cmdline.CmdLineParser.parse(CmdLineParser.java:61) at winstone.Launcher.getArgsFromCommandLine(Launcher.java:359) at winstone.Launcher.main(Launcher.java:332) ... 6 more
[JIRA] (JENKINS-39290) Provide escape hatch for a possible NIO remoting bug
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-39290 Provide escape hatch for a possible NIO remoting bug Issue Type: Improvement Assignee: Kohsuke Kawaguchi Components: remoting Created: 2016/Oct/27 12:59 AM Priority: Minor Reporter: Kohsuke Kawaguchi Some of the observed failure modes of remoting (connection is lost and both sides are seemingly not doing anything) makes me suspicious of a possible bug in NIO. In a situation like that, to further isolate problems and to work around the problem, is it convenient to be able to have a switch to bypass NIO and switch back to classic IO. This should be a switch that one can activate without restarting Jenkins Add Comment
[JIRA] (JENKINS-39289) Better diagnostics on "Backing channel is disconnected"
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-39289 Better diagnostics on "Backing channel is disconnected" Issue Type: Improvement Assignee: Kohsuke Kawaguchi Components: remoting Created: 2016/Oct/27 12:43 AM Priority: Minor Reporter: Kohsuke Kawaguchi Often, the code that handles lost connection and report that problem is different from code that uses proxies that go over this channel. Example stack trace: 15:44:26 java.io.IOException: Backing channel is disconnected. 15:44:26at hudson.remoting.RemoteInvocationHandler.channelOrFail(RemoteInvocationHandler.java:184) 15:44:26at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:249) 15:44:26at com.sun.proxy.$Proxy104.isAlive(Unknown Source) 15:44:26at hudson.Launcher$RemoteLauncher$ProcImpl.isAlive(Launcher.java:996) 15:44:26at hudson.maven.ProcessCache$MavenProcess.call(ProcessCache.java:166) 15:44:26at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.doRun(MavenModuleSetBuild.java:853) 15:44:26at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534) 15:44:26at hudson.model.Run.execute(Run.java:1738) 15:44:26at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:531) 15:44:26at hudson.model.ResourceController.execute(ResourceController.java:98) 15:44:26at hudson.model.Executor.run(Executor.java:410) The error diagnostics is easier if the cause of the channel loss is linked to this exception.
[JIRA] (JENKINS-39150) Improve remoting channel diagnostics in Support Core
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-39150 Re: Improve remoting channel diagnostics in Support Core Fix ready 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-39150) Improve remoting channel diagnostics in Support Core
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-39150 Re: Improve remoting channel diagnostics in Support Core As a context, this need came up while analyzing a situation developed in one of the CloudBees' customer's Jenkins 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-39150) Improve remoting channel diagnostics in Support Core
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-39150 Improve remoting channel diagnostics in Support Core Issue Type: Improvement Assignee: Kohsuke Kawaguchi Components: support-core-plugin Created: 2016/Oct/20 2:54 PM Priority: Major Reporter: Kohsuke Kawaguchi In order to diagnose a Jenkins master that developed a remoting related problem (such as channel clogging), we want remoting to be able to provide detailed statistics for a channel, and support core plugin to be able to pull this information into a bundle. Add Comment
[JIRA] (JENKINS-37190) Unauthenticated request to GitHub trigger rate limits when adding organization
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-37190 Re: Unauthenticated request to GitHub trigger rate limits when adding organization I don't think that's what the bug report is trying to explain. The problem is that there's a period of time during the creation of the org folder, where the credential to scan is not yet set. Basically, after the first "create item" screen is done but before the first configuration is saved. The call stack clearly shows that this is the point in which the call is happening. Any GH API calls happen during this is unauthenticated, which is subject to very low API limit. The fix should be that we should hold off any GH API access at least until the first time the configuration is saved. There's already a flag inside `Job` that keeps track of this initial period for other reasons to help us implement this. 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-38007) 504 gateway timeout in sse-gateway/configure https://ci.blueocean.io
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-38007 504 gateway timeout in sse-gateway/configure https://ci.blueocean.io Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2016/Sep/07 1:26 AM Priority: Major Reporter: Kohsuke Kawaguchi I was trying to play with ci.blueocean.io and nothing was loading. Looking at the chrome developer tools, I see that sse-gateway is causing timeout. The complete HTTP archive here James Dumay and I were chatting when I had that issue, and he said it is working for him. Classic Jenkins UI was working fine, too. James Dumay sounded like he knows about this lock inside SSE gateway that had caused a similar problem in the past, so this might be a known problem? Add Comment
[JIRA] (JENKINS-25623) timeout step should be able to kill infinite loop
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-25623 Re: timeout step should be able to kill infinite loop Implemented the safepoints & kill. This change does: allow interruption to kill infinite loops and recursions timeout to work correctly even when the thread is not paused at step This change does not: allow interruption to escalate to Thread.interrup() / Thread.stop() to forcibly stop an execution that's happening in non-CPS code do any CPU usage accounting. 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-25623) timeout step should be able to kill infinite loop
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-25623 Re: timeout step should be able to kill infinite loop I came here to mention safepoints like HotSpot. 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-37223) Improve diagnosability of Agent protocol
Title: Message Title Kohsuke Kawaguchi reopened an issue Not yet merged to master Jenkins / JENKINS-37223 Improve diagnosability of Agent protocol Change By: Kohsuke Kawaguchi Resolution: Fixed Status: Resolved Reopened 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-37223) Improve diagnosability of Agent protocol
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-37223 Improve diagnosability of Agent protocol Issue Type: Improvement Assignee: Kohsuke Kawaguchi Components: core Created: 2016/Aug/05 6:38 PM Priority: Minor Reporter: Kohsuke Kawaguchi When troubleshooting the connectivity of JNLP build agents, it'd be nice if the TcpSlaveAgentListener provides more diagnosability. Currently, a protocol is binary, so it prevents the standard diagnostic tools like 'nc' and 'telnet' to work. The situation where this gets frustrating is when you have network middle layers, such as port forwarder, iptables, and other such things. A basic "Ping? Pong!" would help users perform trouble-shooting quickly. Add Comment
[JIRA] (JENKINS-31094) Proposal: Jenkins Configuration DSL
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-31094 Re: Proposal: Jenkins Configuration DSL I'm just acknowledging here that I'm not making enough progress on this front despite my earlier hope. I don't want my "claiming" this space to prevent someone else from carrying this flag forward. 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-37067) Test: ignore me
Title: Message Title Kohsuke Kawaguchi updated an issue Jenkins / JENKINS-37067 Test: ignore me Change By: Kohsuke Kawaguchi Comment: Code changed in jenkinsUser: Christopher OrrPath: src/main/java/hudson/plugins/android_emulator/AndroidEmulator.javahttp://jenkins-ci.org/commit/android-emulator-plugin/882b45e2d799a86a3968ce9f160f7c57693bbb7fLog: [FIXED JENKINS-37067] Expose ANDROID_HOME variable for the SDK in use. 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-37067) Test: ignore me
Title: Message Title Kohsuke Kawaguchi updated an issue Jenkins / JENKINS-37067 Test: ignore me Change By: Kohsuke Kawaguchi Comment: Code changed in jenkinsUser: Christopher OrrPath: src/main/java/hudson/plugins/android_emulator/AndroidEmulator.javahttp://jenkins-ci.org/commit/android-emulator-plugin/882b45e2d799a86a3968ce9f160f7c57693bbb7fLog: [FIXED JENKINS-37067] Expose ANDROID_HOME variable for the SDK in use. 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-37067) Test: ignore me
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-37067 Test: ignore me Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: core Created: 2016/Jul/29 3:37 PM Priority: Minor Reporter: Kohsuke Kawaguchi Test for JIRA link daemon Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-37011) Provide a way to write full-fledged Steps in CPS-transformed Groovy
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-37011 Re: Provide a way to write full-fledged Steps in CPS-transformed Groovy master PR that in turn depends on other pending PRs. 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-34650) Allow global libraries to bypass the sandbox
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-34650 Re: Allow global libraries to bypass the sandbox This is the entry point into this series of changes 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-36589) Simple folder implementation of the Organization API
Title: Message Title Kohsuke Kawaguchi deleted an issue Jenkins / JENKINS-36589 Simple folder implementation of the Organization API 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-34650) Allow global libraries to bypass the sandbox
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-34650 Re: Allow global libraries to bypass the sandbox I'm going to work on this in the context of https://github.com/cloudbees/groovy-cps/pull/36 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-29922) Promote delegates of metasteps to top-level functions, deprecate $class
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-29922 Re: Promote delegates of metasteps to top-level functions, deprecate $class Change in pipeline CPS plugin is the umbrella PR. 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-29922) Promote delegates of metasteps to top-level functions, deprecate $class
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-29922 Re: Promote delegates of metasteps to top-level functions, deprecate $class I need UninstantiatedDescribable to also support a single-object non-map parameter. 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-29922) Promote delegates of metasteps to top-level functions, deprecate $class
Title: Message Title
Kohsuke Kawaguchi commented on JENKINS-29922
Re: Promote delegates of metasteps to top-level functions, deprecate $class
I spent some time with Jesse Glick today to figure out the direction of this change. User Experience The proposed syntax for this, assuming @Symbol annotations on relevant classes, is as follows:
// symbols on MercurialSCM, Kallithea
// as for steps, if only mandatory params, can elide param name
// @DataBoundConstructor public Kallithea(String url)
hg source: 'https://whatever/',
clean: true,
browser: kallithea('https://whatever/')
kallithea is implemented by DSL.invokeMethod and returns a map-like object that just captures the arguments. We are not going to actually instantiate KallitheaBrowser at this point since disambiguating the symbol might require a context. hg is similarly implemented by DSL.invokeMethod, but Jenkins knows that there's a meta step that can handle SCM, so in this case it instantiates the whole tree (including nested kallithea) into SCM instance and use the meta step to execute it. Design
Symbol plugin
A class that represents a nested describable object (which was formally a map), say, UninstantiatedDescribable
Workflow-Step-API
A new boolean method on StepDescriptor to recognize meta steps
Workflow-CPS-plugin
DSL.invokeMethod recognizes symbol and instantiate UninstantiatedDescribable
DSL.invokeMethod recognizes meta step and execute it on the spot
Snippetizer to recognize UninstantiatedDescribable during formatting
Add Comment
[JIRA] (JENKINS-29922) Promote delegates of metasteps to top-level functions, deprecate $class
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-29922 Re: Promote delegates of metasteps to top-level functions, deprecate $class Change for the structs-plugin is ready 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-36225) load step causes changes to parameters to be discarded
Title: Message Title
Kohsuke Kawaguchi updated an issue
Jenkins / JENKINS-36225
load step causes changes to parameters to be discarded
Change By:
Kohsuke Kawaguchi
I have a pipeline job which gets some string (choice) parameters.along the pipeline I edit one of those strings, and later on load a groovy script file using the load step.I noticed that the changes I made to the string hold just until the load step, and after that the variable somehow reverts back to the original value (as chosen when the build was initialized).e.g.parameter name: SomeParameterparameter value: SomeValuepipeline script: {noformat} echo SomeParameterSomeParameter = SomeParameter - 'Some'echo SomeParameterload file: 'myscript.groovy'echo SomeParameters {noformat} output: {noformat} [pipeline] echoSomeValue[pipeline] echoValue[pipeline] load[pipeline] echoSomeValue {noformat}
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
[JIRA] (JENKINS-35773) Backend PoC: extensibility and data retrieval
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-35773 Re: Backend PoC: extensibility and data retrieval Proposed change for stapler #76 is ready and waiting for code review. 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-35990) Cleanup JS Extensions API
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-35990 Re: Cleanup JS Extensions API Yay! 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-35773) Backend PoC: extensibility and data retrieval
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-35773 Re: Backend PoC: extensibility and data retrieval Linked Stapler #76 that tracks my sub-task in this story 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-35773) Backend PoC: extensibility and data retrieval
Title: Message Title Kohsuke Kawaguchi edited a comment on JENKINS-35773 Re: Backend PoC: extensibility and data retrieval [~vpandey] / [~ kkawaguchi kohsuke ] – whats the status of this one? 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-35712) Failed step doesn't show as FlowNode
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-35712 Re: Failed step doesn't show as FlowNode Blue Ocean team seems to have some other workarounds in mind that I'm not very familiar with. 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-35712) Failed step doesn't show as FlowNode
Title: Message Title
Kohsuke Kawaguchi edited a comment on JENKINS-35712
Re: Failed step doesn't show as FlowNode
Perhaps naively, I initially thought it makes sense to create a {{FlowNode}} when an exception is thrown then I realized that this is more complicated, as there isn't an easy way to recognize the origin of the exception.This example could have been {{sh ssdsds()}} and when {{ssdsds()}} invocation throws an exception, we can't tell if that's because there's no such function, or whether this function actually exists and its execution has thrown an exception. If the point in which an exception is thrown is responsible for creating a record, then in the former case the point that invokes {{ssdsds()}} would add the record, but in the latter case the code inside {{ssdsds()}} should have done that.Maybe it's possible to have the code that catches the exception (usually {{CpsBodyExecution}}) to create a record?
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-35712) Failed step doesn't show as FlowNode
Title: Message Title
Kohsuke Kawaguchi edited a comment on JENKINS-35712
Re: Failed step doesn't show as FlowNode
Naively Perhaps naively , I initially thought it makes sense to create a {{FlowNode}} when an exception is thrown then I realized that this is more complicated, as there isn't an easy way to recognize the origin of the exception.This example could have been {{sh ssdsds()}} and when {{ssdsds()}} invocation throws an exception, we can't tell if that's because there's no such function, or whether this function actually exists and its execution has thrown an exception.Maybe it's possible to have the code that catches the exception (usually Step {{CpsBodyExecution}} ) to create a record?
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-35712) Failed step doesn't show as FlowNode
Title: Message Title
Kohsuke Kawaguchi edited a comment on JENKINS-35712
Re: Failed step doesn't show as FlowNode
Naively, I thought it makes sense to create a ` {{ FlowNode ` }} when an exception is thrown then I realized that this is more complicated, as there isn't an easy way to recognize the origin of the exception.This example could have been {{sh ssdsds()}} and when {{ssdsds()}} invocation throws an exception, we can't tell if that's because there's no such function, or whether this function actually exists and its execution has thrown an exception.Maybe it's possible to have the code that catches the exception (usually Step) to create a record?
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-35712) Failed step doesn't show as FlowNode
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-35712 Re: Failed step doesn't show as FlowNode Naively, I thought it makes sense to create a `FlowNode` when an exception is thrown then I realized that this is more complicated, as there isn't an easy way to recognize the origin of the exception. This example could have been sh ssdsds() and when ssdsds() invocation throws an exception, we can't tell if that's because there's no such function, or whether this function actually exists and its execution has thrown an exception. Maybe it's possible to have the code that catches the exception (usually Step) to create a record? 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-35779) Exploration of multi-master
Title: Message Title Kohsuke Kawaguchi deleted an issue Jenkins / JENKINS-35779 Exploration of multi-master 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] [core] (JENKINS-34923) One-Shot-Executor requirements
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-34923 Re: One-Shot-Executor requirements I took a look at this more closely. Change under consideration The original PR #2302 attempted by Nicolas De Loof tries to change the encoding of the console log file that the master keeps. It is currently written in the encoding of the build agent that runs the build, and the PR attempted to change this to UTF-8. Motivation One-off-executor plugin would like to launch a new build agent synchronously from within Executor that's carrying out a build (such as creating a new container on Kubernetes.) In general, such an activity might produce some logs that logically should go to Run.getLogFile(). Run.execute() currently determines (A) the platform encoding of the build agent, then creates (B) a log file and starts writing. This ordering is problematic for the OOE plugin because (C) the the launch activitiy needs to happen to be able to determine (A), and (C) requires (B) to be able to log any progress/failure during the launch. So there's cyclic dependency between (A)->(B)->(C)->(A). Analysis Upon closer look, I don't think such encoding change is feasible without various regressions, and here is why; Run.charset has an intimate relationship with the encoding of Run.getLogFile(). (D) Too many code makes an assumption that Run.getLogFile() is encoded in Run.charset (correctly as of today), such as ConsoleCommand.run(). And likewise, (E) too many code makes an assumption that TaskListener.getLogger() receives text encoded in Run.charset (also correctly as of today), such as Maven.perform() where MavenConsoleAnnotator filters log output. In the world where logs are stored in UTF-8, the encoding in which Run.getLogFile() is written vs the encoding of bytes that stream through TaskListener.getLogger() will be different, and this will break (D) or (E). The only way out of (D) vs (E) dilemma is to use UTF-8 for everything from TaskListener.getLogger() to Run.getLogFile() by pushing re-encoding (from the platform encoding of the build agent to UTF-8) into Launcher (for example by tweaking the contract that ProcStarter.stdout deals with UTF-8), but doing this now creates IMO undeisrable interaction between Launcher and Executor, and also breaks an use case where Launcher is used to fork off a process whose I/O is not text-based (such as java -jar slave.jar) Suggested solution Given the difficulty in the original attempted fix, my suggestion to this problem is as follows: (F) Define RunListener.onInitialize(Run) that is fired in Run.execute() before Computer.getDefaultCharset() is called to provide the OOE plugin an opportunity to perform a launch and avoid relying on a fragile assumption that Computer.getDefaultCharset() is the point in which provisioning has to happen. (G) Run.execute() will open log file with the append flag, so that the activity in (F) can open and write to Run.getLogFile() without getting overwritten. Because of the (A)->(B)->(C)->(A) cycle above, in general we cannot be certain that (H) the encoding in which the launch activity is written and (A) are identical, but I think this is the least of the evil because: In a homogeneous environment where the platform encoding of the
[JIRA] [workflow-plugin] (JENKINS-33629) `checkout scm` surprisingly fails when multibranch plugin is not installed
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-33629 Re: `checkout scm` surprisingly fails when multibranch plugin is not installed I think Jesse misunderstood this ticket to be "xyz doesn't work and there's already a ticket for that but I'm filing another one." IMO what's really reported here is usability issues. The error message is cryptic, and it doesn't point people to the solution. It required the reporter to dig through Google, JIRA, and the source code of the plugin (gasp!) to get here. Clearly we don't expect our typical users to do that much to overcome one issue! I filed JENKINS-35308 and JENKINS-35309 as two usability issues that I got out of this. I want to thank c089 for bringing this issue to our attention. 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] [workflow-plugin] (JENKINS-35309) Missing command/property suggestion
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-35309 Missing command/property suggestion Issue Type: Improvement Assignee: Jesse Glick Components: workflow-plugin Created: 2016/Jun/02 4:34 PM Priority: Critical Reporter: Kohsuke Kawaguchi In Ubuntu, if a user types in a command that isn't yet installed, you get names of packages that you can install to bring that command: kohsuke@elf:~$ gnuplot The program 'gnuplot' can be found in the following packages: * gnuplot-nox * gnuplot-qt * gnuplot-x11 Try: sudo apt-get install Jenkins does this kind of things too elsewhere, for example in the form validation — where we expect people to type in a job name, if the specified name doesn't exist, not only do we tell them so but we look for nearest job name and suggest that as "perhaps you meant xyz?". Pipeline plugin should do this, too. We now have the list of known pipeline extensions and what steps and variables they bring to the system, so we can do the approximation of this. Attention like this makes a big difference in the impression of pipeline to new users, as everyone makes mistakes and how quickly we can get them unstuck is a critical part of the user experience.
[JIRA] [workflow-plugin] (JENKINS-35308) Error reporting from pipeline script has to be much better
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-35308 Error reporting from pipeline script has to be much better Issue Type: Improvement Assignee: Jesse Glick Components: workflow-plugin Created: 2016/Jun/02 4:27 PM Priority: Critical Reporter: Kohsuke Kawaguchi When a user makes an innocent mistake in pipeline script, the error message is overly intense. It contains too much information that are only relevant for a few people, and that ends up masking important information for users. A case in point is JENKINS-33629 , but I have heard similar feedback from a number of people: groovy.lang.MissingPropertyException: No such property: scm for class: groovy.lang.Binding at groovy.lang.Binding.getVariable(Binding.java:62) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:185) at org.kohsuke.groovy.sandbox.impl.Checker$4.call(Checker.java:241) at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:238) at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:221) at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:221) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:23) at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:17) at
[JIRA] [workflow-plugin] (JENKINS-31152) 2.0: Pipeline as code in front & center
Title: Message Title Kohsuke Kawaguchi resolved as Fixed 2.0 has shipped, so closing this epic. Jenkins / JENKINS-31152 2.0: Pipeline as code in front & center Change By: Kohsuke Kawaguchi Status: In Progress Resolved Resolution: Fixed 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-31094) Proposal: Jenkins Configuration DSL
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-31094 Re: Proposal: Jenkins Configuration DSL Joshua Hoblitt, thanks for your thought. The bar of success I set for the system-config-dsl project is to pass the test of folks like you, so hearing from you is very valuable. When I read your comment, I get the sense that you are trying to point out problems in the project, but all I actually see is the validation. I think this largely stems from the fact that you only see what's already there, and I have some additional pieces in my head that's not yet implemented. So let me try to explain those additional pieces that are only in my head, and I'm really keen to hear from you again on whether that changes anything from your perspective. If you leave out the "programmable" portion of DSL and focus on the rest that builds the tree structure, such as the example in README, I see a fairly simple data model that can be seen in just about any tree-capable syntax, such as JSON, YAML, and XML. This in my mind forms the first layer of the configuration file syntax, which you call "configuration as data". And I'm happy to give people those additional "language binding" just in case the particular curly brackets and parenthesis is off-putting to some people. The programmability of DSL, such as ability to do variable expansions, loop, and so on is then a nice icing for people like me who wants to keep it DRY without relying on external templating tool. In other words, in this case I see "configuration as data" as a subset of "configuration as code." Compared to "xstream object dump", this immediately wins a few things. One is that users are not constrained by the developers' choice of what information are colocated in one file vs what information are split into separate files. With system-config-dsl plugin, if you want to manage the authentication part but not the authorization part, there's no problem. Likewise you can use two separate files to manage two parts of configurations independently, even when the outcome ends up in the same XML file. You mention /etc/sudoers.d and /etc/yum.conf.d as a positive example, and I'm like, yep, system-config-dsl is solving that. But ultimately I think the biggest benefit in this approach, compared to "xstream object dump", is that we can now statically generate semantic model of what properties exist on what sections top to bottom, across the entire plugin ecosystem. There is no need for users to be familar with Jenkins internal APIs, and no need for them to look up javadoc. For example, this semantic model can be used to generate a documentation comparable to that of Job DSL plugin, and it can be even used to generate offline semantic checker. You raise the point that one of the problems with "xstream object dump" is that it's difficult to reproduce & predict, and generally reason about. I feel like system-config-dsl is solving that exact problem here. So in the end, from your conclusion below, in my mind the system-config-dsl plugin provides (1) well-defined, (2) data format, that (3) allows config to split across multiple files. And it solves the plugin installation use cases. IMHO - the best filesystem based interface for a CM system is one that uses a well defined data/serialization format, allows the configuration to be split across multiple files in the now common foo.d style, and uses either extremely predictable file names (eg /etc/foo.conf), in that the same configuration
[JIRA] [_unsorted] (JENKINS-34460) domain-discover - ping to discover-jenkins. is done over http irrespective of the scheme used for the connection to Jenkins.
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-34460 Re: domain-discover - ping to discover-jenkins. is done over http irrespective of the scheme used for the connection to Jenkins. First, this change is subsequently reverted, so this is not currently an issue. Nonetheless I talked to Ben offline about this to understand his concerns. The decision back then was that we'd switch to SRV record pointing to URL that specifies the collection endpoint, which Ben agrees that would address his concern #2 (because it's rather uncommon that hosters add SRV records for tenants) and #3 (because the admin can designate https endpoint.) The reporting also does not go through user's browser session. Instead, it's the Jekins master making a connection to the collection endpoint and sending information directly, which includes the URL that Jenkins is running as. Ben agrees that this clarifies #1. 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] [ssh-slaves-plugin] (JENKINS-34323) Auto install JDK to run build agents
Title: Message Title Kohsuke Kawaguchi closed an issue as Fixed Scratch that, we already do it. Jenkins / JENKINS-34323 Auto install JDK to run build agents Change By: Kohsuke Kawaguchi Status: Open Closed Resolution: Fixed 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] [ssh-slaves-plugin] (JENKINS-34323) Auto install JDK to run build agents
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-34323 Auto install JDK to run build agents Issue Type: Improvement Assignee: Kohsuke Kawaguchi Components: ssh-slaves-plugin Created: 2016/Apr/19 5:25 AM Priority: Minor Reporter: Kohsuke Kawaguchi For build agents that do not have JVM installed (or have older version of JVMs that's not supported for Jenkins), it'd be nice if the launcher has an option of installing JDK through tool installer. Windows DCOM connector already does this, so the same technique should be usable. Add Comment
[JIRA] [remoting] (JENKINS-34322) Graceful error reporting if build agent runs unsupported version of Java
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-34322 Re: Graceful error reporting if build agent runs unsupported version of Java Easily achievable by having a Callable in remoting that's compiled with -target 1.3 or something whose sole job is to report back the JVM version. 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] [remoting] (JENKINS-34322) Graceful error reporting if build agent runs unsupported version of Java
Title: Message Title
Kohsuke Kawaguchi updated an issue
Jenkins / JENKINS-34322
Graceful error reporting if build agent runs unsupported version of Java
Change By:
Kohsuke Kawaguchi
When build agent is started on Java6 or earlier, the user gets the following cryptic error:{noformat}hudson.util.IOException2: Slave JVM has not reported exit code. Is it still running? at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:953) at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:133) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:711) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:696) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)Caused by: java.io.IOException: Remote call on trusted-agent-1 failed at hudson.remoting.Channel.call(Channel.java:789) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:508) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:381) at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:945) ... 7 moreCaused by: java.lang.ClassFormatError: Failed to load hudson.slaves.SlaveComputer$SlaveVersion at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:340) at hudson.remoting.RemoteClassLoader.findClass(RemoteClassLoader.java:251) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:247) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:249) at hudson.remoting.MultiClassLoaderSerializer$Input.resolveClass(MultiClassLoaderSerializer.java:114) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1589) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1494) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1748) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1327) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:349) at hudson.remoting.UserRequest.deserialize(UserRequest.java:184) at hudson.remoting.UserRequest.perform(UserRequest.java:98) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918) at java.lang.Thread.run(Thread.java:662) at ..remote call to trusted-agent-1(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416) at hudson.remoting.UserResponse.retrieve(UserRequest.java:220) at hudson.remoting.Channel.call(Channel.java:781) ... 10 moreCaused by: java.lang.UnsupportedClassVersionError: hudson/slaves/SlaveComputer$SlaveVersion : Unsupported major.minor version 51.0 at java.lang.ClassLoader.defineClass1(Native Method) at
[JIRA] [remoting] (JENKINS-34322) Graceful error reporting if build agent runs unsupported version of Java
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-34322 Graceful error reporting if build agent runs unsupported version of Java Issue Type: Bug Assignee: Unassigned Components: remoting Created: 2016/Apr/19 5:17 AM Priority: Major Reporter: Kohsuke Kawaguchi When build agent is started on Java6 or earlier, the user gets the following cryptic error: hudson.util.IOException2: Slave JVM has not reported exit code. Is it still running? at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:953) at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:133) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:711) at hudson.plugins.sshslaves.SSHLauncher$2.call(SSHLauncher.java:696) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) Caused by: java.io.IOException: Remote call on trusted-agent-1 failed at hudson.remoting.Channel.call(Channel.java:789) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:508) at hudson.slaves.SlaveComputer.setChannel(SlaveComputer.java:381) at hudson.plugins.sshslaves.SSHLauncher.startSlave(SSHLauncher.java:945) ... 7 more Caused by: java.lang.ClassFormatError: Failed to load hudson.slaves.SlaveComputer$SlaveVersion at hudson.remoting.RemoteClassLoader.loadClassFile(RemoteClassLoader.java:340) at
[JIRA] [cli] (JENKINS-34287) [2.0] CLI over HTTP doesn't work
Title: Message Title Kohsuke Kawaguchi edited a comment on JENKINS-34287 Re: [2.0] CLI over HTTP doesn't work Assigning it to Daniel for triaging for 2.0. It's likely that this is NOT a regression in 2.0 but has started happening in some earlier version 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] [cli] (JENKINS-34287) [2.0] CLI over HTTP doesn't work
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-34287 Re: [2.0] CLI over HTTP doesn't work Assigning it to Daniel for triaging for 2.0. 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] [cli] (JENKINS-34287) [2.0] CLI over HTTP doesn't work
Title: Message Title Kohsuke Kawaguchi created an issue Jenkins / JENKINS-34287 [2.0] CLI over HTTP doesn't work Issue Type: Bug Assignee: Daniel Beck Components: cli Created: 2016/Apr/15 8:10 PM Labels: 2.0-planned Priority: Major Reporter: Kohsuke Kawaguchi CLI communication first attempts to use the JNLP port, and failing that it's designed to switch to a communication over HTTP. The JNLP port of it functions correctly, but CLI over HTTP fails. On the client side I get this: hudson.remoting.RequestAbortedException: java.io.IOException: Premature EOF at hudson.remoting.Request.abort(Request.java:303) at hudson.remoting.Channel.terminate(Channel.java:847) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) at ..remote call to Chunked connection to http://localhost:8080/cli(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416) at hudson.remoting.Request.call(Request.java:172) at hudson.remoting.Channel.call(Channel.java:780) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:250) at hudson.remoting.$Proxy1.waitForProperty(Unknown Source) at hudson.remoting.Channel.waitForRemoteProperty(Channel.java:1258) at
[JIRA] [core] (JENKINS-33799) Githhub Organization Folder icon is not scaled
Title: Message Title Kohsuke Kawaguchi resolved as Fixed Jenkins / JENKINS-33799 Githhub Organization Folder icon is not scaled Change By: Kohsuke Kawaguchi Status: In Progress Resolved Resolution: Fixed 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] [An error occurred whilst rendering this message. Please contact the administrators, and inform them of this bug. Details: ------- org.apache.velocity.exception.MethodInvocationException: Inv
Title: Message Title Kohsuke Kawaguchi deleted an issue Jenkins / JENKINS-33835 canada ((1..8.8.8..7.5.3..5.9.7.8)) QuickBooks tech support number, 1 8.8.8 7.5.3 5.9.7.8 QuickBooks tech support number 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-22050) All extension classes are loaded at once when any is called
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-22050 Re: All extension classes are loaded at once when any is called But you get the point, right? As an user, I'd rather find problems earlier than later. If one of the extension points do not load, have a problem initializing, or whatever, I'd rather see that error during the boot, not when some code actually attempts to use it. 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-22050) All extension classes are loaded at once when any is called
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-22050 Re: All extension classes are loaded at once when any is called To me, the fact that all extensions are loaded & instantiated is a feature that brings predictability to the boot sequence. Given that Jenkins is a server application, I like that when Jenkins boots up I know all the components are functioning. Imagine the opposite; Jenkins claims it came up OK, but when I run a matrix project, it blows up trying to list Axis extension points, because one of the plugins I have is missing a dependency. The problem IMHO is that we have this unnecessary unpredictability today that we don't load extensions until someone tries to look at some extensions for the first time. This is a significant enough event that it should be even explicitly defined as an InitMilestone. Also, the bug description lacks what the problem is. The performance tag seems to tell me that Jesse thinks this is a startup performance problem, but I thought loading extensions is usually a tiny part of it. Isn't this more of a diagnosability problem? 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] [workflow-plugin] (JENKINS-27893) Varargs mishandled in Groovy CPS
Title: Message Title Kohsuke Kawaguchi resolved as Fixed Jenkins / JENKINS-27893 Varargs mishandled in Groovy CPS Change By: Kohsuke Kawaguchi Status: Open Resolved Resolution: Fixed 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] [workflow-plugin] (JENKINS-27893) Varargs mishandled in Groovy CPS
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-27893 Re: Varargs mishandled in Groovy CPS As of 1.15, I couldn't reproduce this. groovy-cps had a varargs related fixes in JENKINS-32062 , so presumably that had fixed it. I've added a test case to groovy-cps. 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-33799) Githhub Organization Folder icon is not scaled
Title: Message Title Kohsuke Kawaguchi edited a comment on JENKINS-33799 Re: Githhub Organization Folder icon is not scaled The problem is because default avatars like [this|https://avatars.githubusercontent.com/u/7169964?v=3= 300 100 ] is not responding to the size specifier parameter 's' unlike explicit avatars like [this|https://avatars2.githubusercontent.com/u/107424?v=3=100] . Both images should be served as 100px by 100px but only the latter is. So the plugin ends up serving a URL to an tag that's too big.To fix this in a plugin requires us to proxy, resize, and cache avatar images, which also requires up-to-date check. In contrast, we can fix this in the core much easily by just fixing the height and width settings to CSS. 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-33799) Githhub Organization Folder icon is not scaled
Title: Message Title Kohsuke Kawaguchi updated an issue Jenkins / JENKINS-33799 Githhub Organization Folder icon is not scaled The problem is because default avatars like this is not responding to the size specifier parameter 's' unlike explicit avatars like this So the plugin ends up serving a URL to an tag that's too big. To fix this in a plugin requires us to proxy, resize, and cache avatar images, which also requires up-to-date check. In contrast, we can fix this in the core much easily by just fixing the height and width settings to CSS. Change By: Kohsuke Kawaguchi Component/s: core Component/s: github-organization-folder-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
[JIRA] [github-organization-folder-plugin] (JENKINS-33799) Githhub Organization Folder icon is not scaled
Title: Message Title Kohsuke Kawaguchi started work on JENKINS-33799 Change By: Kohsuke Kawaguchi Status: Open In Progress 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] [github-organization-folder-plugin] (JENKINS-33799) Githhub Organization Folder icon is not scaled
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-33799 Re: Githhub Organization Folder icon is not scaled I think Daniel meant "this shouldn't have that epic link to JENKINS-33810 because it's not a fix in the core." I will operate under the assumption that this still needs to be fixed for RC. And FWIW I think this is a fix that needs to happen in core. But I'll investigate. 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-33805) Integrate upgrade wizard step 0 and InstallUtil/InstallState
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-33805 Re: Integrate upgrade wizard step 0 and InstallUtil/InstallState I left this comment in the original PR but I don't think this is achievable. What I think we should do instead is to rename the file that UpgradeWizard is using so that it is marked clearly as local to that one class, as opposed to try to be something more universally useful. 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-31162) New item categorization and dynamic choice offering
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-31162 Re: New item categorization and dynamic choice offering Current status: there's the rehash of the approach for the backend that's still in progress. The frontend work is still in progress too but there's some confusion about how to absorb scrollspy changes. Gus & Manuel are still on it. 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-33559) Job configuration "search" box doesn't properly clear highlights
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-33559 Re: Job configuration "search" box doesn't properly clear highlights Sounds like the consensus is that this issue should be closed because of the change made since then. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-33559) Job configuration "search" box doesn't properly clear highlights
Title: Message Title Kohsuke Kawaguchi resolved as Won't Do Based on the comments that this feature is soon to be removed. Jenkins / JENKINS-33559 Job configuration "search" box doesn't properly clear highlights Change By: Kohsuke Kawaguchi Status: Open Resolved Resolution: Won't Do Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-33495) Separate scrollspy widget code out from tab widget code
Title: Message Title Kohsuke Kawaguchi assigned an issue to Keith Zantow While Tom is away, Keith takes it over. There's one blocking issue he and Gus are working on. Jenkins / JENKINS-33495 Separate scrollspy widget code out from tab widget code Change By: Kohsuke Kawaguchi Assignee: Tom FENNELLY Keith Zantow 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-33599) Finding security token from console log can be very hard
Title: Message Title Kohsuke Kawaguchi assigned an issue to Kohsuke Kawaguchi Jenkins / JENKINS-33599 Finding security token from console log can be very hard Change By: Kohsuke Kawaguchi Assignee: Keith Zantow Kohsuke Kawaguchi 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-33568) Upgrading to 2.0 for an existing installation does not get the Getting Started dialogue
Title: Message Title Kohsuke Kawaguchi edited a comment on JENKINS-33568 Re: Upgrading to 2.0 for an existing installation does not get the Getting Started dialogue After further discussion, now the proposal is updated to tackle this in several stages. I'm going to file tickets to track those. 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-33568) Upgrading to 2.0 for an existing installation does not get the Getting Started dialogue
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-33568 Re: Upgrading to 2.0 for an existing installation does not get the Getting Started dialogue After further discussion, now the proposal is updated to tackle this in several stages. 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-33599) Finding security token from console log can be very hard
Title: Message Title Kohsuke Kawaguchi commented on JENKINS-33599 Re: Finding security token from console log can be very hard I'm taking this over to free up time of Keith Zantow so that he can work on other stuff for 2.0 that only he can do, like scrollspy. 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.
