[JIRA] (JENKINS-40279) Disabling of Jenkins setup wizard not working as expected
Title: Message Title
Craig Ringer edited a comment on JENKINS-40279
Re: Disabling of Jenkins setup wizard not working as expected
I've also been utterly stumped by this, trying incantations with derivative Docker images of the official {{jenkins/jenkins:lts}} image like{{RUN echo $JENKINS_VERSION | tee \/usr/share/jenkins/ref/jenkins.install.UpgradeWizard.state \/usr/share/jenkins/ref/jenkins.install.InstallUtil.lastExecVersion}}and{{ENV JAVA_OPTS "-Djenkins.install.runSetupWizard=false ${JAVA_OPTS:-}"}}But for some reason passing `--env JAVA_OPTS="-Djenkins.install.runSetupWizard=false"` to `docker run` did work.See also https://github.com/jenkinsci/docker/issues/310 and https://github.com/jenkinsci/docker/pull/833
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.176933.1481117876000.22388.1559805900237%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-40279) Disabling of Jenkins setup wizard not working as expected
Title: Message Title
Craig Ringer commented on JENKINS-40279
Re: Disabling of Jenkins setup wizard not working as expected
I've also been utterly stumped by this, trying incantations with derivative Docker images of the official jenkins/jenkins:lts image like {{RUN echo $JENKINS_VERSION | tee \ /usr/share/jenkins/ref/jenkins.install.UpgradeWizard.state \ /usr/share/jenkins/ref/jenkins.install.InstallUtil.lastExecVersion}} and ENV JAVA_OPTS "Djenkins.install.runSetupWizard=false ${JAVA_OPTS:}" But for some reason passing `--env JAVA_OPTS="-Djenkins.install.runSetupWizard=false"` to `docker run` did work.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.176933.1481117876000.22380.1559805840234%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-47279) Full-duplex HTTP(S) transport with plain CLI protocol does not work with Apache reverse proxy in Jenkins >= 2.54
Title: Message Title
Craig Ringer edited a comment on JENKINS-47279
Re: Full-duplex HTTP(S) transport with plain CLI protocol does not work with Apache reverse proxy in Jenkins >= 2.54
I've seen reports this also affects nginx with ` {{ proxy_request_buffering ` }} and/or ` {{ proxy_buffering ` }} . This makes me wonder if changes to {{mod_proxy}}'s [ProxyIOBufferSize|https://httpd.apache.org/docs/current/mod/mod_proxy.html#ProxyIOBufferSize] and/or [ProxyReceiveBufferSize|https://httpd.apache.org/docs/current/mod/mod_proxy.html#ProxyReceiveBufferSize] may address this, perhaps in combination with ensuring {{jenkins-cli}} sends a certain minimum size request/response.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.185699.1507146144000.21545.1559711820292%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-47279) Full-duplex HTTP(S) transport with plain CLI protocol does not work with Apache reverse proxy in Jenkins >= 2.54
Title: Message Title Craig Ringer commented on JENKINS-47279 Re: Full-duplex HTTP(S) transport with plain CLI protocol does not work with Apache reverse proxy in Jenkins >= 2.54 I've seen reports this also affects nginx with `proxy_request_buffering` and/or `proxy_buffering`. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.185699.1507146144000.21518.1559710560332%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56890) IOException: "cannot find current thread"
Title: Message Title Craig Ringer commented on JENKINS-56890 Re: IOException: "cannot find current thread" FWIW, I found a possibly-related crash that turned out to be in my own code. I was using a groovy `Map` that was modified by multiple closures run within a `parallel` step. This caused similar exceptions as well as odd incorrect map entries etc. So keep an eye out for that. Posting here for people who see this later. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.198561.1554419267000.20291.1559613300752%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-16108) Option to use "last unstable" as fallback for "Upstream build which trigger" instead of only "last successful"
Title: Message Title Craig Ringer commented on JENKINS-16108 Re: Option to use "last unstable" as fallback for "Upstream build which trigger" instead of only "last successful" This is possible with the copyArtifacts plugin now, it's just less than clear in the docs. copyArtifacts( projectName: "blah" selector: lastSuccessful(stable: false), ... ) Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.146912.1355318803000.9703.1558592820307%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57382) Documentation advises use of legacy container link feature
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-57382
Documentation advises use of legacy container link feature
Change By:
Craig Ringer
h3. Docs recommend deprecated / legacy docker featuresThe [docker-workflow-plugin documentation for scripted pipeline multiple/sidecar container use|https://jenkins.io/doc/book/pipeline/docker/#running-sidecar-containers] advises users to use the container link ("--link") feature in Docker and links to [https://docs.docker.com/network/links/].But the Docker documentation warns that this is a legacy feature that's not recommended. It recommends user defined networks. Where that's not possible the default "bridge" network, while considered legacy, is preferred to using container links.The docs should not use the --link argument.h3. Simplify use of correct Docker inter-container connections in JenkinsCode enhancements are not necessary to use the default bridge, but a {{container.getIpAddress()}} accessor in {{org/jenkinsci/plugins/docker/workflow/Docker.groovy}}'s {{Container}} inner class would be very helpful. Without it the user's code must use {{docker inspect}} to get the container IP to connect to, as Docker doesn't do container-name resolving for the default {{bridge}} network:{noformat}docker.image("postgres:11").withRun("- e p :5432") { -> pgcontainer def postgres_ip = sh(script: "docker inspect -f {{.NetworkSettings.IPAddress}} ${ c pgcontainer .id}",returnStdout: true)docker.image("myapp:latest").inside {sh("runMyApp --postgres-host ${postgres_ip} --postgres-port ") }}{noformat}h3. Natively support user defined networksEven better we could natively support user-defined Docker networks with relatively small changes:* a {{docker.withNetwork(...)}} DSL call that creates a user defined network with arbitrary name and passes a {{Network}} object with {{getName()}} accessor to the inner closure, then cleans it up on closure exit. Like {{withRun}} etc. Name is generated if not provided. * All context-nested {{docker.withRun}} and {{docker.inside}} calls will use this network by default by automatically passing the {{--network}} argument to {{docker run}} * A {{Container.getName(...)}} accessor in {{org/jenkinsci/plugins/docker/workflow/Docker.groovy}}'s {{Container}} inner class, for easy referencing containers by name whether generated or otherwise. (unless the resolver works with container-id, need to check}} When using user-defined networks Docker creates a custom {{/etc/resolv.conf}} that points to its proxy nameserver, allowing other containers to be resolved by name. So you could then write the following code - which *does not currently work and is not implemented*:{noformat}docker.withNetwork { docker.image("postgres:11").withRun { -> pgcontainer docker.image("myapp:latest").inside { sh("runMyApp --postgres-host ${pgcontainer.name} --postgres-port 5432")} }}{noformat}... and the Docker resolver will resolve {{pgcontainer.name}} to the right IP on the bridge network. It'd be
[JIRA] (JENKINS-57382) Documentation advises use of legacy container link feature
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-57382
Documentation advises use of legacy container link feature
Change By:
Craig Ringer
h3. Docs recommend deprecated / legacy docker featuresThe [ docker-workflow-plugin documentation for scripted pipeline multiple/sidecar container use|https://jenkins.io/doc/book/pipeline/docker/#running-sidecar-containers] advises users to use the container link ("--link") feature in Docker and links to [https://docs.docker.com/network/links/].But the Docker documentation warns that this is a legacy feature that's not recommended. It recommends user defined networks. Where that's not possible the default "bridge" network, while considered legacy, is preferred to using container links.The docs should not use the --link argument.h3. Simplify use of correct Docker inter-container connections in JenkinsCode enhancements are not necessary to use the default bridge, but a {{container.getIpAddress()}} accessor would be very helpful. Without it the user's code must use {{docker inspect}} to get the container IP to connect to, as Docker doesn't do container-name resolving for the default {{bridge}} network:{noformat}docker.image("postgres:11").withRun("-e :5432") { def postgres_ip = sh(script: "docker inspect -f {{.NetworkSettings.IPAddress}} ${c.id}",returnStdout: true)docker.image("myapp:latest").inside {sh("runMyApp --postgres-host ${postgres_ip} --postgres-port ") }}{noformat}h3. Natively support user defined networksEven better we could natively support user-defined Docker networks with relatively small changes:* a {{docker.withNetwork(...)}} DSL call that creates a user defined network with arbitrary name and passes a {{Network}} object with {{getName()}} accessor to the inner closure, then cleans it up on closure exit. Like {{withRun}} etc.* All context-nested {{docker.withRun}} and {{docker.inside}} calls will use this network by default by automatically passing the {{--network}} argument to {{docker run}}It'd be further improved by supporting these features:* A different network can be selected even within a {{withNetwork}} closure by passing a new {{network}} keyword argument to {{docker.withRun}} or {{docker.inside}}. This may be a string network name or a {{Network}} wrapper object.* {{docker.createNetwork(...)}}, {{docker.rmNetwork(...)}} and {{docker.getNetwork}} wrappers for more complex use cases return and destroy {{Network}} objects. {{getNetwork}} can take a {{create}} bool arg to get create-if-not-exists semantics, and can be used to load existing user defined networks.* (maybe as sugar): A {{publish}} argument to {{withRun}} and {{inside}} so you don't have to fiddle with the docker argument list to expose port ranges.
[JIRA] (JENKINS-57382) Documentation advises use of legacy container link feature
Title: Message Title
Craig Ringer created an issue
Jenkins / JENKINS-57382
Documentation advises use of legacy container link feature
Issue Type:
Bug
Assignee:
Unassigned
Components:
docker-workflow-plugin
Created:
2019-05-09 04:55
Priority:
Minor
Reporter:
Craig Ringer
Docs recommend deprecated / legacy docker features The docker-workflow-plugin documentation advises users to use the container link ("--link") feature in Docker and links to https://docs.docker.com/network/links/. But the Docker documentation warns that this is a legacy feature that's not recommended. It recommends user defined networks. Where that's not possible the default "bridge" network, while considered legacy, is preferred to using container links. The docs should not use the --link argument. Simplify use of correct Docker inter-container connections in Jenkins Code enhancements are not necessary to use the default bridge, but a container.getIpAddress() accessor would be very helpful. Without it the user's code must use docker inspect to get the container IP to connect to, as Docker doesn't do container-name resolving for the default bridge network:
docker.image("postgres:11").withRun("-e :5432") {
def postgres_ip = sh(
script: "docker inspect -f {{.NetworkSettings.IPAddress}} ${c.id}",
returnStdout: true)
docker.image("myapp:latest").inside {
sh("runMyApp --postgres-host ${postgres_ip} --postgres-port ")
}
}
Natively support user defined networks Even better we could natively support user-defined Docker networks with relatively small changes:
a
[JIRA] (JENKINS-55702) Missing ellipsis or other indication of abbreviation on artifacts shortlist
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-55702
Missing ellipsis or other indication of abbreviation on artifacts shortlist
Change By:
Craig Ringer
*If Jenkins abbreviates an artifact path on the main job page where it shows the artifacts summary, it should add an ellipsis to the start of the path to make it less confusing.*e.g. if the real path is foo/bar/baz/bop/myfile.so, Jenkins may currently display "bop/myfile.so" in the abbreviated list, and in the full list may display just the path "foo/bar/baz/bop" to browse. Instead it should use the path "*…*/bop/myfile.so" in the abbreviated list, and preferably tooltip-display the full path on hover over the file link.*Example/rationale:*When displaying a job's results, the artifacts summary shown directly on the build results page under the "Build Artifacts" header collapses and hides common subdirectories. That is useful, but it's misleading because there's no indication the abbreviation was performed on the paths.So a user will see e.g.!artifacts-abbrev.png!when viewing a job, then when they go to the /artifact/ page they'll see !artifacts.png! Note that different paths were abbreviated at different depths in the first output. The true listing is{ \ {$ unzip -L archive.zip }}{{Archive: archive.zip}} \ {{ inflating: archive/tpa-bdr-simple/tpa-test/bdr-simple/results/tpaexec-test.log }} \ {{ inflating: archive/tpa-bdr-simple/tpa-test/bdr-simple/results/tpaexec-test/1548066249/kinkier/package-list.txt }} \ {{ inflating: archive/tpa-bdr-simple/tpa-test/bdr-simple/results/tpaexec-test/1548066249/kinkier/pg_controldata.txt }} \ {{ inflating: archive/tpa-bdr-simple/tpa-test/bdr-simple/results/tpaexec-test/1548066249/kinkier/pgbench.txt }} \ {{ inflating: archive/tpa-bdr-simple/tpa-test/bdr-simple/results/tpaexec-test/1548066249/kismet/package-list.txt }} \ {{ inflating: archive/tpa-bdr-simple/tpa-test/bdr-simple/results/tpaexec-test/1548066249/kismet/pg_controldata.txt }} \ {{ inflating: archive/tpa-bdr-simple/tpa-test/bdr-simple/results/tpaexec-test/1548066249/kismet/pgbench-init.txt }} \ {{ inflating: archive/tpa-bdr-simple/tpa-test/bdr-simple/results/tpaexec-test/1548066249/kismet/pgbench.txt }} \ {{ inflating: archive/tpa-camo-2x2/tpa-test/camo2x2/results/tpaexec-test.log }} \ {{ inflating: archive/tpa-camo-2x2/tpa-test/camo2x2/results/tpaexec-test/1548066249/killjoy/package-list.txt }} \ {{ inflating: archive/tpa-camo-2x2/tpa-test/camo2x2/results/tpaexec-test/1548066249/killjoy/pg_controldata.txt }} \ {{ inflating: archive/tpa-camo-2x2/tpa-test/camo2x2/results/tpaexec-test/1548066249/killjoy/pgbench.txt }} \ {{ inflating: archive/tpa-camo-2x2/tpa-test/camo2x2/results/tpaexec-test/1548066249/quahaug/package-list.txt }} \ {{ inflating: archive/tpa-camo-2x2/tpa-test/camo2x2/results/tpaexec-test/1548066249/quahaug/pg_controldata.txt }} \ {{ inflating: archive/tpa-camo-2x2/tpa-test/camo2x2/results/tpaexec-test/1548066249/quahaug/pgbench-init.txt }} \ {{ inflating:
[JIRA] (JENKINS-55702) Missing ellipsis or other indication of abbreviation on artifacts shortlist
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-55702
Missing ellipsis or other indication of abbreviation on artifacts shortlist
Change By:
Craig Ringer
*If Jenkins abbreviates an artifact path on the main job page where it shows the artifacts summary, it should add an ellipsis to the start of the path to make it less confusing.*e.g. if the real path is foo/bar/baz/bop/myfile.so, Jenkins may currently display "bop/myfile.so" in the abbreviated list, and in the full list may display just the path "foo/bar/baz/bop" to browse. Instead it should use the path "*…*/bop/myfile.so" in the abbreviated list, and preferably tooltip-display the full path on hover over the file link.*Example/rationale:*When displaying a job's results, the artifacts summary shown directly on the build results page under the "Build Artifacts" header collapses and hides common subdirectories. That is useful, but it's misleading because there's no indication the abbreviation was performed on the paths.So a user will see e.g.!artifacts-abbrev.png!when viewing a job, then when they go to the /artifact/ page they'll see !artifacts.png! Note that different paths were abbreviated at different depths in the first output. The true listing is{{$ unzip - l ~/Downloads/ L archive.zip }}{{Archive: /home/craig/Downloads/ archive.zip}}{{ Length Date Time Name}}{{- -- - }}{{ 11194 01-21-2019 11 inflating : 28 archive/tpa- BDR bdr - Simple simple /tpa-test/bdr-simple/results/tpaexec-test.log}}{{ 1906124 01-21-2019 11 inflating : 28 archive/tpa- BDR bdr - Simple simple /tpa-test/bdr-simple/results/tpaexec-test/1548066249/kinkier/package-list.txt}}{{ 2281 01-21-2019 11 inflating : 28 archive/tpa- BDR bdr - Simple simple /tpa-test/bdr-simple/results/tpaexec-test/1548066249/kinkier/pg_controldata.txt}}{{ 329 01-21-2019 11 inflating : 28 archive/tpa- BDR bdr - Simple simple /tpa-test/bdr-simple/results/tpaexec-test/1548066249/kinkier/pgbench.txt}}{{ 1906131 01-21-2019 11 inflating : 28 archive/tpa- BDR bdr - Simple simple /tpa-test/bdr-simple/results/tpaexec-test/1548066249/kismet/package-list.txt}}{{ 2281 01-21-2019 11 inflating : 28 archive/tpa- BDR bdr - Simple simple /tpa-test/bdr-simple/results/tpaexec-test/1548066249/kismet/pg_controldata.txt}}{{ 1 01-21-2019 11 inflating : 28 archive/tpa- BDR bdr - Simple simple /tpa-test/bdr-simple/results/tpaexec-test/1548066249/kismet/pgbench-init.txt}}{{ 329 01-21-2019 11 inflating : 28 archive/tpa- BDR bdr - Simple simple /tpa-test/bdr-simple/results/tpaexec-test/1548066249/kismet/pgbench.txt}}{{ 11265 01-21-2019 11 inflating : 28 archive/tpa- CAMO camo -2x2/tpa-test/camo2x2/results/tpaexec-test.log}}{{ 1906129 01-21-2019 11 inflating : 28 archive/tpa- CAMO camo -2x2/tpa-test/camo2x2/results/tpaexec-test/1548066249/killjoy/package-list.txt}}{{ 2281 01-21-2019 11 inflating : 28 archive/tpa- CAMO camo -2x2/tpa-test/camo2x2/results/tpaexec-test/1548066249/killjoy/pg_controldata.txt}}{{ 329 01-21-2019 11 inflating : 28
[JIRA] (JENKINS-55702) Missing ellipsis or other indication of abbreviation on artifacts shortlist
Title: Message Title Craig Ringer created an issue Jenkins / JENKINS-55702 Missing ellipsis or other indication of abbreviation on artifacts shortlist Issue Type: Bug Assignee: Unassigned Attachments: artifacts-abbrev.png, artifacts.png Components: core Created: 2019-01-21 13:41 Environment: 2.150.2 Labels: usability user-experience UI Priority: Trivial Reporter: Craig Ringer If Jenkins abbreviates an artifact path on the main job page where it shows the artifacts summary, it should add an ellipsis to the start of the path to make it less confusing. e.g. if the real path is foo/bar/baz/bop/myfile.so, Jenkins may currently display "bop/myfile.so" in the abbreviated list, and in the full list may display just the path "foo/bar/baz/bop" to browse. Instead it should use the path "…/bop/myfile.so" in the abbreviated list, and preferably tooltip-display the full path on hover over the file link. Example/rationale: When displaying a job's results, the artifacts summary shown directly on the build results page under the "Build Artifacts" header collapses and hides common subdirectories. That is useful, but it's misleading because there's no indication the abbreviation was performed on the paths. So a user will see e.g. when viewing a job, then when they go to the /artifact/ page they'll see Note that different paths were abbreviated at different depths in the
[JIRA] (JENKINS-28119) Link to log of failed step
Title: Message Title Craig Ringer commented on JENKINS-28119 Re: Link to log of failed step This becomes even more relevant when working with Blue Ocean etc. The URLs are something like `jobname/6/pipeline/79` where the /79 is a node in the graph of steps and parallel tasks. It doesn't seem to be predictable, so it's not clear how you can generate a URL that points to exactly one parallel step, for example. 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-54930) withEnv should accept Map as well as List
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-54930
withEnv should accept Map as well as List
Change By:
Craig Ringer
The {{withEnv}} step should accept a {{ java.util.{{Map}} }} , which is the natural form of an environment variable list. It expects a {{java.util.List}}, and dies with{code:java}java.lang.UnsupportedOperationException: must specify $class with an implementation of interface java.util.List at org.jenkinsci.plugins.structs.describable.DescribableModel.resolveClass(DescribableModel.java:503) ...Caused: java.lang.IllegalArgumentException: Could not instantiate {overrides={}} for EnvStep(overrides: String[]) ...{code}if a {{Map}} is passed.
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-54930) withEnv should accept Map as well as List
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-54930
withEnv should accept Map as well as List
Change By:
Craig Ringer
The ` {{ withEnv ` }} step should accept a java.util.{{ Map }} , which is the natural form of an environment variable list. It expects a ` {{ java.util.List ` }} , and dies with {code :java }java.lang.UnsupportedOperationException: must specify $class with an implementation of interface java.util.List at org.jenkinsci.plugins.structs.describable.DescribableModel.resolveClass(DescribableModel.java:503) ...Caused: java.lang.IllegalArgumentException: Could not instantiate {overrides={}} for EnvStep(overrides: String[]) ...{code} if a {{ Map }} is passed.
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-54930) withEnv should accept Map as well as List
Title: Message Title
Craig Ringer created an issue
Jenkins / JENKINS-54930
withEnv should accept Map as well as List
Issue Type:
New Feature
Assignee:
Unassigned
Components:
workflow-basic-steps-plugin
Created:
2018-11-29 05:43
Priority:
Minor
Reporter:
Craig Ringer
The `withEnv` step should accept a Map, which is the natural form of an environment variable list. It expects a `java.util.List`, and dies with
java.lang.UnsupportedOperationException: must specify $class with an implementation of interface java.util.List
at org.jenkinsci.plugins.structs.describable.DescribableModel.resolveClass(DescribableModel.java:503)
...
Caused: java.lang.IllegalArgumentException: Could not instantiate {overrides={}} for EnvStep(overrides: String[])
...
if a Map is passed.
Add Comment
[JIRA] (JENKINS-38005) Using archiveArtifacts with a non-matching pattern silently fails the build
Title: Message Title Craig Ringer commented on JENKINS-38005 Re: Using archiveArtifacts with a non-matching pattern silently fails the build The comments here about "silently" failing the build make me think it'd be very good to capture the hudson.Abort exception and its stack. Then when the pipeline aborts, print "Pipeline aborted. (See stack)", with "(See stack)" as a ConsoleAnnotation that lets you view the stack that led to the abort. Even "Pipeline aborted in 'build' step at line '42'" would be a massive help though. 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-48489) ability to specify a path prefix to archiveArtifacts
Title: Message Title Craig Ringer commented on JENKINS-48489 Re: ability to specify a path prefix to archiveArtifacts I'm really surprised not to see more interest in this issue, I ran into it as soon as I started doing any archiving in parallel jobs. The shell workaround is ugly. I'll try to find time to patch this, but it looks like it requires changes to Jenkins and to pipeline, which is likely why it hasn't been picked up yet. 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-54535) Expose build parameters in RunWrapper
Title: Message Title Craig Ringer commented on JENKINS-54535 Re: Expose build parameters in RunWrapper Right. I replied by email, but there's apparently no email gateway to the notifications just a highly delayed bounce (sigh). I submitted a pull with a proposed implementation, any concerns with it? 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-54535) Expose build parameters in RunWrapper
Title: Message Title Craig Ringer commented on JENKINS-54535 Re: Expose build parameters in RunWrapper PR https://github.com/jenkinsci/workflow-support-plugin/pull/81 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-54535) Expose build parameters in RunWrapper
Title: Message Title Craig Ringer created an issue Jenkins / JENKINS-54535 Expose build parameters in RunWrapper Issue Type: Patch Assignee: Unassigned Components: workflow-support-plugin Created: 2018-11-08 04:34 Priority: Minor Reporter: Craig Ringer RunWrapper doesn't offer any way to access a run's build parameters. To address that, this patch adds new getBuildParameters() and getBuildParametersAsStrings() methods to RunWrapper. The former getBuildParameters method returns a parameter-type specific Object. It auto-wraps run parameters in a RunWrapper, returns string and boolean parameters as their base type, and otherwise returns whatever the parameter value is. Parameters marked sensitive are returned as their ParameterValue object with no unwrapping. This means scripts can't interact with all parameter types without extra approvals, but they can get the true parameter values and work with the common ones. The getBuildParametersAsStrings() method instead returns stringified forms of the parameters. These may be less useful for script logic, e.g. when a run name is returned instead of a RunWrapper. But it's much easier to use and more useful for diagnostic output and reporting to the user. Add Comment
[JIRA] (JENKINS-54532) Document how to get parameters from a Run
Title: Message Title Craig Ringer commented on JENKINS-54532 Re: Document how to get parameters from a Run Pull https://github.com/jenkinsci/jenkins/pull/3724 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-54532) Document how to get parameters from a Run
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-54532
Document how to get parameters from a Run
Change By:
Craig Ringer
It's very hard for someone new to Jenkins' internal structure (perhaps a Pipeline script author) to figure out how to get build parameters, environment variables, etc from a{{ Run }} .Address this with a documentation change that directs the reader to the {{ Actionable }} {{ superclass's getAction(Class) , }} and {{ getAllActions() }} methods, and to {{ ParametersAction }} as an example.
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-54532) Document how to get parameters from a Run
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-54532
Document how to get parameters from a Run
Change By:
Craig Ringer
It's very hard for someone new to Jenkins' internal structure (perhaps a Pipeline script author) to figure out how to get build parameters, environment variables, etc from a {{Run}}.Address this with a documentation change that directs the reader to the {{Actionable}} {{ superclass's {{ getAction(Class)}} and {{getAllActions() }} methods, and to {{ParametersAction}} as an example.
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-54532) Document how to get parameters from a Run
Title: Message Title Craig Ringer created an issue Jenkins / JENKINS-54532 Document how to get parameters from a Run Issue Type: Patch Assignee: Unassigned Components: core Created: 2018-11-08 02:59 Priority: Minor Reporter: Craig Ringer It's very hard for someone new to Jenkins' internal structure (perhaps a Pipeline script author) to figure out how to get build parameters, environment variables, etc from a Run. Address this with a documentation change that directs the reader to the Actionable superclass's getAction(Class), getAllActions() methods, and to ParametersAction as an example. Add Comment
[JIRA] (JENKINS-54531) Document that buildVariables is the child environment, not parameters
Title: Message Title Craig Ringer commented on JENKINS-54531 Re: Document that buildVariables is the child environment, not parameters Pull request 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-54531) Document that buildVariables is the child environment, not parameters
Title: Message Title Craig Ringer edited a comment on JENKINS-54531 Re: Document that buildVariables is the child environment, not parameters Pull request : https://github.com/jenkinsci/workflow-support-plugin/pull/80 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-54531) Document that buildVariables is the child environment, not parameters
Title: Message Title Craig Ringer updated an issue Jenkins / JENKINS-54531 Document that buildVariables is the child environment, not parameters Change By: Craig Ringer I found the description of RunWrapper.getBuildVariables a bit incomplete/confusing:> buildVariables>> for a non-Pipeline downstream build, offers access to a map of defined build variables; for a > Pipeline downstream build, any variables set globally on envso I suggest changing it, appending:> Child Pipeline jobs can use this to report additional information to the parent job by setting environment variables in env . Build Note that build parameters are not shown in buildVariables. 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-54531) Document that buildVariables is the child environment, not parameters
Title: Message Title Craig Ringer created an issue Jenkins / JENKINS-54531 Document that buildVariables is the child environment, not parameters Issue Type: Patch Assignee: Unassigned Components: workflow-support-plugin Created: 2018-11-08 02:31 Priority: Minor Reporter: Craig Ringer I found the description of RunWrapper.getBuildVariables a bit incomplete/confusing: > buildVariables > > for a non-Pipeline downstream build, offers access to a map of defined build variables; for a >Pipeline downstream build, any variables set globally on env so I suggest changing it, appending: > Child jobs can use this to report additional information to the parent job by setting environment variables. Build parameters are not shown in buildVariables. Add Comment
[JIRA] (JENKINS-41275) Add way to easily test currentBuild result is better/worse than some value (isBetterOrEqualTo)
Title: Message Title Craig Ringer commented on JENKINS-41275 Re: Add way to easily test currentBuild result is better/worse than some value (isBetterOrEqualTo) The specific fix proposed here doesn't give pipelines a way to test the result of a `RunWrapper` from a child build returned by a `build` step with `propagate: false`. I whitelisted: staticMethod hudson.model.Result fromString java.lang.String method hudson.model.Result isWorseThan hudson.model.Result 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-54361) Plugin name doesn't match UI, docs stale
Title: Message Title Craig Ringer updated an issue Jenkins / JENKINS-54361 Plugin name doesn't match UI, docs stale Change By: Craig Ringer Issue Type: Improvement Patch 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-54361) Plugin name doesn't match UI, docs stale
Title: Message Title Craig Ringer updated an issue Jenkins / JENKINS-54361 Plugin name doesn't match UI, docs stale Change By: Craig Ringer Issue Type: Bug Improvement 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-26033) Document and test return value for parallel
Title: Message Title Craig Ringer edited a comment on JENKINS-26033 Re: Document and test return value for parallel I created JENKINS-54514 with proposed documentation changes to address this and related matters. See https://github.com/jenkinsci/workflow-cps-plugin/pull/260 for the patch. Per this issue, I suggested the return value be ignored. But if it's not considered deprecated I'll tweak that. 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-26033) Document and test return value for parallel
Title: Message Title Craig Ringer commented on JENKINS-26033 Re: Document and test return value for parallel I created JENKINS-54514 with proposed documentation changes to address this and related matters. Per this issue, I suggested the return value be ignored. But if it's not considered deprecated I'll tweak that. 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-54514) Document parallel step failure logic
Title: Message Title Craig Ringer updated an issue Jenkins / JENKINS-54514 Document parallel step failure logic Change By: Craig Ringer The documentation for the parallel pipeline step is excessively brief. This pull request addresses that by documenting:* What the criteria for failure and success are* The (lack of) meaning of the closure return value* Why some failures are "silent" in that they report no exception (hudson.AbortException)* How to get results out of the branches if desired* "Failed in branch" message* A short practical example* The return value of the parallel step, and why it should be ignored per JENKINS-26033 See https://github.com/jenkinsci/workflow-cps-plugin/pull/260 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-54514) Document parallel step failure logic
Title: Message Title Craig Ringer created an issue Jenkins / JENKINS-54514 Document parallel step failure logic Issue Type: Patch Assignee: Unassigned Components: workflow-cps-plugin Created: 2018-11-07 13:38 Environment: Jenkins ver. 2.138.2 ; workflow-cps-plugin 2.6 Priority: Minor Reporter: Craig Ringer The documentation for the parallel pipeline step is excessively brief. This pull request addresses that by documenting: What the criteria for failure and success are The (lack of) meaning of the closure return value Why some failures are "silent" in that they report no exception (hudson.AbortException) How to get results out of the branches if desired "Failed in branch" message A short practical example The return value of the parallel step, and why it should be ignored per JENKINS-26033
[JIRA] (JENKINS-26033) Document and test return value for parallel
Title: Message Title Craig Ringer commented on JENKINS-26033 Re: Document and test return value for parallel It's not clear how this is done to me; it seems to still have the undocumented behaviour. If the retval isn't going to be blessed as a documented feature, it should be explicitly deprecated. "The parallel step's return value should be ignored, and is subject to change in future versions." Then an example of how results should be reported instead. 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-54490) Mention postbuild plugin in 'manager' Globals description
Title: Message Title Craig Ringer created an issue Jenkins / JENKINS-54490 Mention postbuild plugin in 'manager' Globals description Issue Type: New Feature Assignee: Stefan Wolf Components: groovy-postbuild-plugin Created: 2018-11-06 13:17 Priority: Minor Reporter: Craig Ringer When reading the docs generated by JOBNAME/pipeline-syntax/globals#manager, it's awfully unclear that "manager" is part of the postbuild plugin. It'd be good to mention in the description that it's from the postbuild plugin, and the validity rules around when you can use it. I got quite lost for some time trying to figure out why `manager.listener.logger.println` in one of my global library `vars/` methods wasn't seeming to do anything at all. (JENKINS-54442 relates to the broder issue) Add Comment
[JIRA] (JENKINS-26565) Show both 'names' of plugins
Title: Message Title Craig Ringer commented on JENKINS-26565 Re: Show both 'names' of plugins It looks like Jenkins keeps all the needed metadata for this. The same MarkupFormatterDescriptor that's used to get the name can also report the plugin name, implementing class name, etc. So it looks like it needs some Jelly changes to use that info. I had a go at sketching out how it might look on another related issue here: https://issues.jenkins-ci.org/browse/JENKINS-54441?focusedCommentId=353018=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-353018 (JENKINS-54441) but lack the Jenkins-fu to test it out yet. Help would be greatly welcomed. 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-54441) Display class and plugin for workflow steps
Title: Message Title
Craig Ringer commented on JENKINS-54441
Re: Display class and plugin for workflow steps
It looks like the Descriptor abstract base that StepDescriptor extends exposes a getPlugin() method that would be ideal. AFAICS in src/main/resources/org/jenkinsci/plugins/workflow/cps/Snippetizer/index.jelly. I think it needs to inject getPlugin().getDisplayName() hyperlinked to its getPlugin().getUrl(), and probably the step class's getSimpleName() too. I haven't figured out how to do that in jelly (I used JSF2 in a prior life, but I've never done jelly) and don't have a local Jenkins for testing yet. But hopefully this is a useful starting point. My wild guess is: In the block, maybe after the end of the block, something like
var="plugin" value="${descriptor.plugin}"/>
"3">
Provided by class ${descriptor.simpleName}
if test="${plugin != null}">
var="pluginUrl" value="${plugin.url}"/>
var="pluginName" value="${plugin.displayName}"/>
if test="${pluginUrl == null}>
in plugin ${pluginName}.
if>
if test="${pluginUrl != null}>
in plugin "${pluginUrl}">${pluginName}.
if>
if>
I'd love a hand as I'm a bit stuck about how to get from this to testing it and sending a pull request.
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-54361) Plugin name doesn't match UI, docs stale
Title: Message Title Craig Ringer commented on JENKINS-54361 Re: Plugin name doesn't match UI, docs stale Created pull for the github repo : https://github.com/jenkinsci/antisamy-markup-formatter-plugin/pull/8 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-54441) Display class and plugin for workflow steps
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-54441
Display class and plugin for workflow steps
Change By:
Craig Ringer
The "/pipeline-syntax/ ("Pipeline Syntax Snippet Generator") view exposed by workflow-cps-plugin, and the related "/pipeline-syntax/html" ("Steps Reference") don't expose any information about where a step comes from - the plugin, class, etc.This makes it awfully hard to track things down when trying to debug an issue.It'd be a big improvement if steps were annotated in the help with their implementing class in both places. So in the snippet generator when you choose a "Sample Step" it loads the step descriptor and shows: * Step description if any * Implementing class * "Friendly name" of plugin containing implementing class and its actual plugin-id too, with a link to the plugins wikiI've spent *way* too long trying to find a step's implementation in a sub-sub-sub plugin of a plugin, which has two different display names, a different internal plugin name, and a different-again git repo name.For the bigger picture of "how do I identify where X came from in Jenkins" see JENKINS-26565. See also JENKINS-54442 for the related issue with globals. ~~~For Google: this issue is about workflow-cps-plugin a.k.a workflow-cps a.k.a. "Pipeline: Groovy" a.k.a "Pipeline Groovy Plugin", i.e. the "/pipeline-syntax/" page, the "Pipeline Syntax: Snippet Generator".
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
[JIRA] (JENKINS-54441) Display class and plugin for workflow steps
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-54441
Display class and plugin for workflow steps
Change By:
Craig Ringer
The "/pipeline-syntax/ ("Pipeline Syntax Snippet Generator") view exposed by workflow-cps-plugin, and the related "/pipeline-syntax/html" ("Steps Reference") don't expose any information about where a step comes from - the plugin, class, etc.This makes it awfully hard to track things down when trying to debug an issue.It'd be a big improvement if steps were annotated in the help with their implementing class in both places. So in the snippet generator when you choose a "Sample Step" it loads the step descriptor and shows: * Step description if any * Implementing class * "Friendly name" of plugin containing implementing class and its actual plugin-id too, with a link to the plugins wikiI've spent *way* too long trying to find a step's implementation in a sub-sub-sub plugin of a plugin, which has two different display names, a different internal plugin name, and a different-again git repo name. For the bigger picture of "how do I identify where X came from in Jenkins" see JENKINS-26565. ~~~For Google: this issue is about workflow-cps-plugin a.k.a workflow-cps a.k.a. "Pipeline: Groovy" a.k.a "Pipeline Groovy Plugin", i.e. the "/pipeline-syntax/" page, the "Pipeline Syntax: Snippet Generator".
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
[JIRA] (JENKINS-7887) Inconsistency regarding plugin names inside pluginManger pages
Title: Message Title Craig Ringer commented on JENKINS-7887 Re: Inconsistency regarding plugin names inside pluginManger pages See also JENKINS-26565 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-26565) Show both 'names' of plugins
Title: Message Title Craig Ringer commented on JENKINS-26565 Re: Show both 'names' of plugins I find it utterly bewildering, and it slows me down a lot with Jenkins. The "Safe HTML" formatter is probably the worst culprit, as noted above. It is: "Safe HTML" - name in Global Security configuration, "OWASP Markup Formatter Plugin" - name in "Plugin Manager" UI antisamy-markup-formatter - name in "Plugins" list in "/jenkins/systemInfo", i.e. Maven artifact name ... and none of these are remotely connected. In something that's security-sensitive that's pretty significant. There's no indication at all in the global security UI that the formatter is from a plugin at all (that's kinda bad from a security PoV), let alone which one. The plugin's display name doesn't mention "HTML" or "Safe". The plugin's internal name is unrelated again. Clicking the plugin's name in the Plugin Manager takes you to a a wiki page that (until I edited it) didn't mention "Safe HTML" at all, and its "plugin site" link takes you to https://plugins.jenkins.io/antisamy-markup-formatter but has the title "OWASP Markup Formatter 1.5". If you click the plugin's version in plugin manager you get taken to a confusingly named "thirdPartyLicenses" URL that is really a dependency map. The first "dependency" is actually the plugin itself, but that's not clearly indicated at all. What should happen is: The "Plugin Manager" UI should have a less prominent suffix on the plugin name with the maven artifact name or full co-ordinates, labeled something like "plugin id" The "systemInfo" view should list plugin display-names too The "systemInfo" view should probably also list the contained package(s) or offer a class browser, since they often differ again ... and in the case of formatters, the formatter selector should show the plugin info there. Another example is pretty much any plugin in the Pipeline / Workflow suite. For example, we have: Pipeline: Groovy (jenkins "Plugin Manager" UI) workflow-cps (name in "Plugins" list in "/jenkins/systemInfo", i.e. Maven artifact name) jenkinsci/workflow-cps-plugin (git repo name, note -plugin suffix absent from artifact name) Pipeline Groovy Plugin (github README) org.jenkins-ci.plugins.workflow:workflow-cps:2.60 (full Maven co-ordinates) org.jenkinsci.plugins.workflow.cps.* (package name) Finding things is very hard.
[JIRA] (JENKINS-54442) Show origin class, repository, plugin of globals
Title: Message Title
Craig Ringer created an issue
Jenkins / JENKINS-54442
Show origin class, repository, plugin of globals
Issue Type:
New Feature
Assignee:
Unassigned
Components:
workflow-cps-global-lib-plugin, workflow-cps-plugin
Created:
2018-11-05 04:49
Environment:
Jenkins ver. 2.138.2, org.jenkins-ci.plugins.workflow:workflow-cps:2.60
Priority:
Minor
Reporter:
Craig Ringer
The "/pipeline-syntax/globals" ("Global Variable Reference") view exposed by workflow-cps-plugin as part of the snippet generator doesn't offer any information about where a global came from. This makes it hard for users and even admins to figure out a source location when there's a problem. Is it a pipeline builtin, and if so, which pipeline plugin? Is it part of another plugin? Is it from a global pipeline library? etc. Like for steps in JENKINS-54441 it'd be great to identify the variable more clearly, using its class name, originating plugin if any, originating global library if any, etc.
Add Comment
[JIRA] (JENKINS-54441) Display class and plugin for workflow steps
Title: Message Title
Craig Ringer created an issue
Jenkins / JENKINS-54441
Display class and plugin for workflow steps
Issue Type:
New Feature
Assignee:
Unassigned
Components:
workflow-cps-plugin
Created:
2018-11-05 04:45
Environment:
Jenkins ver. 2.138.2, org.jenkins-ci.plugins.workflow:workflow-cps:2.60
Priority:
Minor
Reporter:
Craig Ringer
The "/pipeline-syntax/ ("Pipeline Syntax Snippet Generator") view exposed by workflow-cps-plugin, and the related "/pipeline-syntax/html" ("Steps Reference") don't expose any information about where a step comes from - the plugin, class, etc. This makes it awfully hard to track things down when trying to debug an issue. It'd be a big improvement if steps were annotated in the help with their implementing class in both places. So in the snippet generator when you choose a "Sample Step" it loads the step descriptor and shows:
Step description if any
Implementing class
"Friendly name" of plugin containing implementing class and its actual plugin-id too, with a link to the plugins wiki
I've spent way too long trying to find a step's implementation in a sub-sub-sub plugin of a plugin, which has two different display names, a different internal plugin name, and a different-again git repo name. ~~~ For Google: this issue is about workflow-cps-plugin a.k.a workflow-cps a.k.a. "Pipeline: Groovy" a.k.a "Pipeline Groovy Plugin", i.e. the "/pipeline-syntax/" page, the "Pipeline Syntax: Snippet Generator".
[JIRA] (JENKINS-54361) Plugin name doesn't match UI, docs stale
Title: Message Title Craig Ringer commented on JENKINS-54361 Re: Plugin name doesn't match UI, docs stale I updated the wiki page. I don't have the access to update the plugins page, or the github repository's descriptive text. Both should really be changed to mention the three names it gets referred to, and the fact it's not configurable (anymore?). 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-54361) Plugin name doesn't match UI, docs stale
Title: Message Title
Craig Ringer updated an issue
Jenkins / JENKINS-54361
Plugin name doesn't match UI, docs stale
Change By:
Craig Ringer
The Jenkins UI and docs refer to the "Safe HTML" markup formatter. But there is really no such thing.It is implemented by the ["OWASP Markup Formatter Plugin"|http://wiki.jenkins-ci.org/display/JENKINS/OWASP+Markup+Formatter+Plugin] (which links to ["plugins.jenkins.io/antisamy-markup-formatter"|https://plugins.jenkins.io/antisamy-markup-formatter]).The ["jenkinsci/antisamy-markup-formatter project has a 1.5 tag"|https://github.com/jenkinsci/antisamy-markup-formatter-plugin/tree/antisamy-markup-formatter-1.5], and appears to be what Jenkins bundles.The plugin site mentions that policies are configurable, but there's no UI to configure policies. The ["file with the extension in it, confusingly named RawHtmlMarkupFormatter"|https://github.com/jenkinsci/antisamy-markup-formatter-plugin/blob/antisamy-markup-formatter-1.5/src/main/java/hudson/markup/RawHtmlMarkupFormatter.java] appears to have had any pluggability cut out, but the comment still reflects the old support: {{ // Use the policy defined above to sanitize the HTML. }} {{ HtmlSanitizer.sanitize(markup, MyspacePolicy.POLICY_DEFINITION.apply(renderer)); }}so in practice it looks like you can only use the copy of the MyspacePolicy embedded in the plugin code.Hopefully this helps the next person who is utterly confused by this, when trying to figure out how to configure the "Safe HTML" formatter policy, allow additional tags in the "Safe HTML" markup formatter in Jenkins, etc.
Add Comment
[JIRA] (JENKINS-54361) Plugin name doesn't match UI, docs stale
Title: Message Title
Craig Ringer created an issue
Jenkins / JENKINS-54361
Plugin name doesn't match UI, docs stale
Issue Type:
Bug
Assignee:
Unassigned
Components:
antisamy-markup-formatter-plugin
Created:
2018-10-31 08:20
Environment:
Jenkins 2.138.2, OWASP Markup Formatter Plugin 1.5
Priority:
Minor
Reporter:
Craig Ringer
The Jenkins UI and docs refer to the "Safe HTML" markup formatter. But there is really no such thing. It is implemented by the "OWASP Markup Formatter Plugin" (which links to "plugins.jenkins.io/antisamy-markup-formatter"). The "jenkinsci/antisamy-markup-formatter project has a 1.5 tag", and appears to be what Jenkins bundles. The plugin site mentions that policies are configurable, but there's no UI to configure policies. The "file with the extension in it, confusingly named RawHtmlMarkupFormatter" appears to have had any pluggability cut out, but the comment still reflects the old support: {{ // Use the policy defined above to sanitize the HTML. HtmlSanitizer.sanitize(markup, MyspacePolicy.POLICY_DEFINITION.apply(renderer)); }} so in practice it looks like you can only use the copy of the MyspacePolicy embedded in the plugin code. Hopefully this helps the next person who is utterly confused by this, when trying to figure out how to configure the "Safe HTML" formatter policy, allow additional tags in the "Safe HTML" markup formatter in Jenkins, etc.
[JIRA] (JENKINS-22865) buildWithParameters doesn't redirect to the build page
Title: Message Title Craig Ringer edited a comment on JENKINS-22865 Re: buildWithParameters doesn't redirect to the build page This is puzzling - in `ParametersDefinitionProperty.java` I see the `buildWithParameters` method emitting a redirect to the job if `Queue.schedule2` produces an item. Which AFAICS it should unless there's one already present.https://github.com/jenkinsci/jenkins/blob/0795e89b308ec7fcbda097858d58763d8531be8c/core/src/main/java/hudson/model/ParametersDefinitionProperty.java#L179Nonetheless, it doesn't seem to, even if I pass `delay` of `0sec`. It looks like that's because the HTTP status code is SC_CREATED, which is a 200-series code, not a 300-series redirect. Sensible for an xmlhttprequest-style _javascript_ submit, not helpful for a form submit.The json-blob approach has other issues. You need to produce a suitable runId. You need to deal with the XSRF protection crumbs. It looks messy.Seems to me that /build should just accept a POST with the same format as buildWithParameters and an optional "useAsDefaults" that displays the UI and lets the user confirm. Either way, redirecting to the submitted job after. I'll see if I can hack together a patch for that but I'm still having a hard time getting my head around the inner workings of Jenkins. See also https://wiki.jenkins.io/display/JENKINS/Structured+Form+Submission for an explanation of why Jenkins does things this way, and see hudson-behaviour.js buildFormTree(). 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-22865) buildWithParameters doesn't redirect to the build page
Title: Message Title Craig Ringer edited a comment on JENKINS-22865 Re: buildWithParameters doesn't redirect to the build page This is puzzling - in `ParametersDefinitionProperty.java` I see the `buildWithParameters` method emitting a redirect to the job if `Queue.schedule2` produces an item. Which AFAICS it should unless there's one already present.https://github.com/jenkinsci/jenkins/blob/0795e89b308ec7fcbda097858d58763d8531be8c/core/src/main/java/hudson/model/ParametersDefinitionProperty.java#L179 Nonetheless, it doesn't seem to, even if I pass `delay` of `0sec`. It looks like that's because the HTTP status code is SC_CREATED, which is a 200-series code, not a 300-series redirect. Sensible for an xmlhttprequest-style _javascript_ submit, not helpful for a form submit.The json-blob approach has other issues. You need to produce a suitable runId. You need to deal with the XSRF protection crumbs. It looks messy.Seems to me that /build should just accept a POST with the same format as buildWithParameters and an optional "useAsDefaults" that displays the UI and lets the user confirm. Either way, redirecting to the submitted job after. I'll see if I can hack together a patch for that but I'm still having a hard time getting my head around the inner workings of Jenkins. 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-22865) buildWithParameters doesn't redirect to the build page
Title: Message Title Craig Ringer commented on JENKINS-22865 Re: buildWithParameters doesn't redirect to the build page This is puzzling - in `ParametersDefinitionProperty.java` I see the `buildWithParameters` method emitting a redirect to the job if `Queue.schedule2` produces an item. Which AFAICS it should unless there's one already present. https://github.com/jenkinsci/jenkins/blob/0795e89b308ec7fcbda097858d58763d8531be8c/core/src/main/java/hudson/model/ParametersDefinitionProperty.java#L179 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-22865) buildWithParameters doesn't redirect to the build page
Title: Message Title Craig Ringer commented on JENKINS-22865 Re: buildWithParameters doesn't redirect to the build page That's useful, but doesn't negate the original concern at all. You can't easily form a dynamic json string for submitting to /build by accepting user input from form fields. It's a usable workaround when everything you want is known at job-completion time. But sometimes you want to prefill most parameters, but allow some to be adjusted. That doesn't seem to be possible with your approach unless you're able to enable _javascript_ and build some json on the fly from the form input fields. Allowing buildWithParameters to redirect to the job afterwards seems like a low-cost solution, perhaps with a redirectToJob=1 param you can make a hidden input. So you can still have your nice custom form, prefilled with most of the params you want to forward to the new job, and you can let the user modify some params before submit. AFAICS to work around this you need _javascript_ to submit without navigating to the empty result page, then to redirect to the new job after a delay. 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-35308) Improve display of non-AbortException stack traces such as MissingPropertyException
Title: Message Title
Craig Ringer commented on JENKINS-35308
Re: Improve display of non-AbortException stack traces such as MissingPropertyException
People who get stuck here, check for WorkflowScript in your stack traces. That's your Jenkinsfile. This has caused me a lot of difficulty as I learn to work with pipelines, though knowing the above makes life much easier. So a big +1 for improving it. *I worked around it in my pipelines; see below for code*. The simplest improvement would be to use [StackTraceUtils](http://docs.groovy-lang.org/latest/html/api/org/codehaus/groovy/runtime/StackTraceUtils.html) to sanitize the Groovy stuff. It could also use `StackTraceUtils.addClassTest(...)` to filter out some limited Jenkins and pipeline internals, though some care is needed not to remove important info "above" the application failure. Can't Jenkins potentially just walk the stack trace and transform `WorkflowScript` to the `${pipeline-script}` name, or annotate the name with the script-name? That alone would be a huge help, and pretty simple. Bonus points for abbreviating stack traces at `WorkflowScript.run`with a `...` - the rest of the stack isn't really that interesting if you know you got to the point of successful pipeline execution. I tried to work around it in my Groovy scripts with an outer try/catch block in which I ran:
try {
// pipeline here
} catch (e) {
currentBuild.result = 'FAILURE'
StackTraceUtils.sanitize(e)
throw e
}
... but it doesn't seem to remove anything much. Even when I add my own class filters (see below). Using `StackTraceUtils.printSanitizedStackTrace(e)` has the same effect. Note that the docs for StackTraceUtils.sanitize appear to be wrong. It doesn't return the exception - it returns null. Attempting to
// this is wrong, do not do this
throw StackTraceUtils.sanitize(e)
will yield the amazingly uninformative exception:
java.lang.NullPointerException
at com.cloudbees.groovy.cps.impl.ThrowBlock$1.receive(ThrowBlock.java:42)
when you try to throw null. I also wrote a filter to cut some of the crud out:
StackTraceUtils.addClassTest({
def result
switch (it) {
/* The Jenkinsfile itself */
case 'WorkflowScript':
result = true
break
/* Innards we don't care about */
case ~/^org.jenkinsci.plugins.workflow/:
result = false
break
case ~/^org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox/:
result = false
break
case ~/^hudson.remoting/:
result = false
break
case
[JIRA] (JENKINS-47131) Jenkinsfile errors shows Java stacktrace without Jenkinsfile line number
Title: Message Title
Craig Ringer commented on JENKINS-47131
Re: Jenkinsfile errors shows Java stacktrace without Jenkinsfile line number
It'd be a massive help to transform `WorkflowScript` in traces to the value of `${pipeline-script}` or annotate it with the same. Even better to also abbreviate the trace after `WorkflowScript.run`. See related JENKINS-35308 .
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] [s3-plugin] (JENKINS-29582) S3 artifact download fails due to null selector
Title: Message Title Craig Ringer commented on JENKINS-29582 Re: S3 artifact download fails due to null selector Same here - no workspace cleanup plugin, same failure. In my case it's not even necessary to save the job configuration. Existing jobs stopped working when I upgraded Jenkins to 1.637. 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] [s3-plugin] (JENKINS-29582) S3 artifact download fails due to null selector
Title: Message Title Craig Ringer edited a comment on JENKINS-29582 Re: S3 artifact download fails due to null selector Same here - no workspace cleanup plugin, same failure. In my case it's not even necessary to save the job configuration. Existing jobs stopped working when I upgraded Jenkins to 1.637. Possibly unrelated. 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] [matrix-project-plugin] (JENKINS-29380) Skip building on offline nodes
Title: Message Title Craig Ringer commented on JENKINS-29380 Re: Skip building on offline nodes This came from http://stackoverflow.com/q/7891709/398670 which describes a workaround for it with some Groovy, too. An option like this would be a real plus. It's frustrating to have one offline node block a matrix build completely, and I'd love to be able to make them skippable instead. Yes, that means the ppc64 RPMs won't get built, but ... oh well, I'd rather have the x86_64 ones completed so the test jobs can fire. The alternative seems to be to use generated template builds instead of matrix builds. So each chain of build tasks is independent, and runs only if the relevant build worker is available. ppc64 test => ppc64 test => ppc64 package => ppc64 packagetest => ppc64 packagepublish, etc. Rather than parameterizing each build. That works, but largely prevents the use of the Jenkins UI instead of a yaml build plugin and scripting. 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] [s3-plugin] (JENKINS-23897) S3 plugin's signed URL expiry is extremely sensitive to clock drift
Craig Ringer resolved JENKINS-23897 as Fixed S3 plugins signed URL expiry is extremely sensitive to clock drift Change By: Craig Ringer (26/Mar/15 3:36 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [s3-plugin] (JENKINS-23897) S3 plugin's signed URL expiry is extremely sensitive to clock drift
Craig Ringer commented on JENKINS-23897 S3 plugins signed URL expiry is extremely sensitive to clock drift This fix has been merged. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [s3-plugin] (JENKINS-14611) S3 plugin credentials lost after service restart, must be re-entered / saved
Craig Ringer commented on JENKINS-14611 S3 plugin credentials lost after service restart, must be re-entered / saved I haven't seen this issue. Can you still reproduce it in a current release? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [envinject-plugin] (JENKINS-27611) NPE when disabling envinject on a project, can't disable envinject
Craig Ringer created JENKINS-27611 NPE when disabling envinject on a project, cant disable envinject Issue Type: Bug Assignee: Gregory Boissinot Attachments: support.zip Components: envinject-plugin Created: 26/Mar/15 4:07 AM Description: Created a normal (non-matrix) job and enabled envinject by checking: "Prepare an environment for the run" Saved the build. Later, went to disable envinject by unchecking "Prepare an environment for the run". Saved the build. Saving the job config caused an NPE in the envinject plugin: javax.servlet.ServletException: java.lang.NullPointerException at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:796) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:123) at com.cloudbees.jenkins.support.slowrequest.SlowRequestFilter.doFilter(SlowRequestFilter.java:37) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at jenkins.metrics.impl.MetricsFilter.doFilter(MetricsFilter.java:117) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:120) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:114) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at
[JIRA] [matrix-project-plugin] (JENKINS-25783) very long build directory paths are created by Matrix project, and difficult directcory names
Craig Ringer commented on JENKINS-25783 very long build directory paths are created by Matrix project, and difficult directcory names Some Windows kernels have bugs relating to deep paths (well short of the official path limit). I've had to abbreviate all my labels to get things to work, and even then it's troublesome. On *nix, label expressions containing shell metacharacters are "fun". Yes, everything should be carefully quoted. It's a pain when you're working with things like third party shell script snippets in configure scripts though. Some form of mapping would be very helpful. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [matrix-project-plugin] (JENKINS-25783) very long build directory paths are created by Matrix project, and difficult directcory names
Craig Ringer edited a comment on JENKINS-25783 very long build directory paths are created by Matrix project, and difficult directcory names Some Windows kernels have bugs relating to deep paths (well short of the official path limit). I've had to abbreviate all my labels to get things to work, and even then it's troublesome. On *nix, label expressions containing shell metacharacters are "fun". Yes, everything should be carefully quoted. It's a pain when you're working with things like third party shell script snippets in configure scripts though. Some form of mapping would be very helpful. Or at least exposing this as an advanced matrix build option instead of a system property. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [matrix-project-plugin] (JENKINS-25783) very long build directory paths are created by Matrix project, and difficult directcory names
Craig Ringer edited a comment on JENKINS-25783 very long build directory paths are created by Matrix project, and difficult directcory names Daniel, very useful hint. Thankyou. The applicability of that property sure isn't limited to Cygwin. Some Windows kernels have bugs relating to deep paths (well short of the official path limit). I've had to abbreviate all my labels to get things to work, and even then it's troublesome. On *nix, label expressions containing shell metacharacters are "fun". Yes, everything should be carefully quoted. It's a pain when you're working with things like third party shell script snippets in configure scripts though. Some form of mapping would be very helpful. Or at least exposing this as an advanced matrix build option instead of a system property. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23971) NumberFormatException when tailing node log (ssh unix slave, ec2)
Craig Ringer commented on JENKINS-23971 NumberFormatException when tailing node log (ssh unix slave, ec2) Thanks for the tip Daniel. I'm using Chrome 35.0.1916.27 at the moment. I'll keep an eye on the dev console. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23971) NumberFormatException when tailing node log (ssh unix slave, ec2)
Craig Ringer created JENKINS-23971 NumberFormatException when tailing node log (ssh unix slave, ec2) Issue Type: Bug Assignee: Francis Upton Components: core, ec2 Created: 24/Jul/14 5:22 PM Description: When tailing the log of a newly launched ssh unix slave, Jenkins suddenly stopped showing the log and instead reported: javax.servlet.ServletException: java.lang.NumberFormatException: For input string: "5584start=208664" at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:778) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:210) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:390) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:210) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:728) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:858) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:631) at org.kohsuke.stapler.Stapler.service(Stapler.java:225) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:96) at com.cloudbees.jenkins.support.slowrequest.SlowRequestFilter.doFilter(SlowRequestFilter.java:37) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at jenkins.metrics.impl.MetricsFilter.doFilter(MetricsFilter.java:117) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:99) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:88) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:48) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:174) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:79) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at
[JIRA] [core] (JENKINS-23971) NumberFormatException when tailing node log (ssh unix slave, ec2)
Craig Ringer commented on JENKINS-23971 NumberFormatException when tailing node log (ssh unix slave, ec2) This doesn't seem to disrupt the ssh communication channel; slave/master communication continues and logs are captured as normal. Re-entering the node's page and opening the log again shows the rest of the log. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2] (JENKINS-23972) EC2: support new General Purpose EBS storage
Craig Ringer created JENKINS-23972 EC2: support new General Purpose EBS storage Issue Type: New Feature Assignee: Francis Upton Components: ec2 Created: 24/Jul/14 5:50 PM Description: It'd be handy to support the new "General Purpose" (gp2) EBS storage type for nodes launched via the ec2-plugin. It's a lot faster and only slightly more expensive. I hope to get the chance to implement this soon. Project: Jenkins Labels: slave ec2 ebs Priority: Minor Reporter: Craig Ringer This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 With -text, log shown for the node on the master when it dies: ===[JENKINS REMOTING CAPACITY]==[HUDSON TRANSMISSION BEGINS]===channel started Slave.jar version: 2.43 This is a Unix slave Slave successfully connected and online Jul 23, 2014 5:57:48 AM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.io.StreamCorruptedException: invalid stream header: AC64736F at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:800) at java.io.ObjectInputStream.init(ObjectInputStream.java:297) at hudson.remoting.ObjectInputStreamEx.init(ObjectInputStreamEx.java:40) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) channel stopped ERROR: Connection terminated java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2323) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2792) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:800) at java.io.ObjectInputStream.init(ObjectInputStream.java:298) at hudson.remoting.ObjectInputStreamEx.init(ObjectInputStreamEx.java:40) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) [07/23/14 05:57:49] [SSH] Connection closed. ERROR: [07/23/14 05:57:49] slave agent was terminated java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2323) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2792) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:800) at java.io.ObjectInputStream.init(ObjectInputStream.java:298) at hudson.remoting.ObjectInputStreamEx.init(ObjectInputStreamEx.java:40) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) and from the slave its self: channel startedchannel started Jul 23, 2014 5:57:48 AM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.io.StreamCorruptedException: invalid stream header: AC64736F at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:800) at java.io.ObjectInputStream.init(ObjectInputStream.java:297) at hudson.remoting.ObjectInputStreamEx.init(ObjectInputStreamEx.java:40) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Jul 23, 2014 5:57:48 AM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.io.StreamCorruptedException: invalid stream header: AC64736F at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:800) at java.io.ObjectInputStream.init(ObjectInputStream.java:297) at hudson.remoting.ObjectInputStreamEx.init(ObjectInputStreamEx.java:40) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) channel stoppedchannel stopped This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see:
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 I can't for the life of me figure out how to use the -tcp option to make the slave passively accept a tcp connection from the master. In any case, -text still fails, so it seems unlikely to be an issue with SSH mangling binary. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23937) No user interface for -tcp PORT slave jar option
Craig Ringer created JENKINS-23937 No user interface for -tcp PORT slave jar option Issue Type: Bug Assignee: Unassigned Components: core Created: 23/Jul/14 6:25 AM Description: While debugging JENKINS-23917 I noticed that the slave option: -tcp FILE : instead of talking to the master via stdin/stdout, listens to a random local port, write that port number to the given file, then wait for the master to connect to that port. doesn't seem to have any UI in Jenkins node configuration to actually use it, at least for ssh or jnlp slaves. You can specify it as a command line suffix, but there's no way to tell Jenkins that it should make a connection to the agent. Minor, as it's not super useful for an ssh slave, and for a jnlp slave it's already using JNLP by connecting to the Jenkins master. I only noticed it while debugging. Perhaps it's best to just remove it from the help output or note that it's for future use? Environment: Jenkins ver. 1.574-SNAPSHOT Project: Jenkins Priority: Trivial Reporter: Craig Ringer This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 When I switch the node to JNLP (so it uses direct TCP/IP as a transport, rather than SSH) I can no longer reproduce this despite repeated test runs. So, so far: Only observed on ppc64 Only observed for ssh slaves Using -text protocol does not help This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2] (JENKINS-23938) New nodes are launched when labels changed in EC2 configuration
Craig Ringer created JENKINS-23938 New nodes are launched when labels changed in EC2 configuration Issue Type: Bug Assignee: Francis Upton Components: ec2 Created: 23/Jul/14 7:15 AM Description: When the set of labels is changed for a configured slave in the EC2 plugin's global config (under "Configure Jenkins"), it forgets about existing nodes and launches new ones. It should instead relabel existing nodes with the new labels on first launch. Or at least terminate the old nodes. As it is, you land up with a bunch of duplicate nodes. Observed with idle timeout enabled, and stop on idle enabled, with nodes idled down at the time of configuration change. Environment: EC2-plugin 1.23 Project: Jenkins Labels: slave labels ec2 Priority: Major Reporter: Craig Ringer This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 I've left a JNLP worker running for some hours, running the same job with 1mb and 10mb artifact sizes that caused intermittent problems over the ssh transport. No problems. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-8900) allow time limit to be specified for build step
Craig Ringer commented on JENKINS-8900 allow time limit to be specified for build step Domas, generally features get implemented when someone puts in the time to implement them, or funds their implementation. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23914) Invalid null/ element added to triggers/ in job causing NPE on job load
Craig Ringer commented on JENKINS-23914 Invalid null/ element added to triggers/ in job causing NPE on job load Looking at the git history for the job, I see that whenever this happened the git configuration for the job was also lost, e.g. - scm class="hudson.plugins.git.GitSCM" plugin="git@2.2.2" -configVersion2/configVersion - - /scm + scm class="hudson.scm.NullSCM"/ This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23914) Invalid null/ element added to triggers/ in job causing NPE on job load
Craig Ringer commented on JENKINS-23914 Invalid null/ element added to triggers/ in job causing NPE on job load I wonder if this is related to the way the matrix plugin sets NullSCM for all child projects? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer updated JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 Change By: Craig Ringer (22/Jul/14 7:18 AM) Summary: Protocoldeadlockwhileuploadingartifacts fromppc64 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts
Craig Ringer created JENKINS-23917 Protocol deadlock while uploading artifacts Issue Type: Bug Assignee: Unassigned Components: core Created: 22/Jul/14 7:17 AM Description: I've encountered an ssh2 channel protocol issue when a ppc64 slave communicates with an x64 master. Most operations, like sending build logs, work fine. When the time comes to upload artifacts at the end of the build the build stalls indefinitely at: Archiving artifacts If I get stack dumps of slave and master using jstack, I see the master waiting to read from the slave: "Channel reader thread: Fedora16-ppc64-Power7-osuosl-karman" prio=10 tid=0x038c2800 nid=0x6de7 in Object.wait() [0x7f825ef8b000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on 0xbf5802e0 (a com.trilead.ssh2.channel.Channel) at java.lang.Object.wait(Object.java:502) at com.trilead.ssh2.channel.FifoBuffer.read(FifoBuffer.java:212) - locked 0xbf5802e0 (a com.trilead.ssh2.channel.Channel) at com.trilead.ssh2.channel.Channel$Output.read(Channel.java:127) at com.trilead.ssh2.channel.ChannelManager.getChannelData(ChannelManager.java:946) - locked 0xbf5802e0 (a com.trilead.ssh2.channel.Channel) at com.trilead.ssh2.channel.ChannelInputStream.read(ChannelInputStream.java:58) at com.trilead.ssh2.channel.ChannelInputStream.read(ChannelInputStream.java:79) at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:82) at hudson.remoting.ChunkedInputStream.readHeader(ChunkedInputStream.java:67) at hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:93) at hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:33) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) and the slave is waiting for data from the master: "Channel reader thread: channel" prio=10 tid=0x0fff940fedd0 nid=0x558e runnable [0x0fff6dc6d000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:236) at java.io.BufferedInputStream.fill(BufferedInputStream.java:235) at java.io.BufferedInputStream.read(BufferedInputStream.java:254) - locked 0x0fff78ba9f98 (a java.io.BufferedInputStream) at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:82) at hudson.remoting.ChunkedInputStream.readHeader(ChunkedInputStream.java:67) at hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:93) at hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:33) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) of course I can't get those dumps at exactly the same moment, even if that were meaningful with network latencies and buffering, but repeated runs never show any other state for either thread. tshark shows that there's some SSH chatter going on: 0.00 SLAVE - MASTER SSH 126 Encrypted response packet len=60 0.176121 MASTER - SLAVE SSH 94 Encrypted request packet len=28 0.176151 SLAVE - MASTER TCP 66 ssh 37501 [ACK] Seq=61 Ack=29 Win=707 Len=0 TSval=4141397874 TSecr=2808266826 but it should well be low level ssh keepalives or similar, as it's at precise 5 second intervals with nothing much else happening. There are three master-slave ssh connections, so it's not guaranteed that it's even the one associated with the stuck channel. My first thought is endianness. I don't really know how to begin debugging this issue, though.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 I'm going to re-test with a simplified build and a single executor configured. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 Interestingly, archiving worked with a trivial configuration - a dd command to create a dummy file and a trivial archiving command to copy it. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [s3] (JENKINS-23918) S3 plugin: Storage class and bucket region selection disabled, GovCloud selected by default
Craig Ringer created JENKINS-23918 S3 plugin: Storage class and bucket region selection disabled, GovCloud selected by default Issue Type: Bug Assignee: Michael Watt Components: s3 Created: 22/Jul/14 7:37 AM Description: Since s3-plugin 0.6, I've noticed that when adding a new "Archive artifacts to S3" post-build task the new "Storage Class" and "Bucket Region" pulldowns are initially empty. When the job configuration is saved then re-opened, the pulldowns are populated. Storage Class has defaulted to "Standard" and "Bucket Region" has defaulted to "GovCloud". This will result in errors about the access key being unknown because GovCloud has a completely isolated authentication setup with different IAM, keys, etc. This is a regression since 0.5. Environment: s3-plugin 0.7-SNAPSHOT; also observed in 0.6. Jenkins 1.574-snapshot, also observed in 1.572. Google Chrome. Project: Jenkins Labels: regression Priority: Major Reporter: Craig Ringer This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [s3] (JENKINS-23918) S3 plugin: Storage class and bucket region selection disabled, GovCloud selected by default
Craig Ringer updated JENKINS-23918 S3 plugin: Storage class and bucket region selection disabled, GovCloud selected by default Change By: Craig Ringer (22/Jul/14 7:41 AM) Description: Sinces3-plugin0.6,IvenoticedthatwhenaddinganewArchiveartifactstoS3post-buildtaskthenewStorageClassandBucketRegionpulldownsareinitiallyempty.Whenthejobconfigurationissavedthenre-opened,thepulldownsarepopulated.StorageClasshasdefaultedtoStandardandBucketRegionhasdefaultedtoGovCloud.ThiswillresultinerrorsabouttheaccesskeybeingunknownbecauseGovCloudhasacompletelyisolatedauthenticationsetupwithdifferentIAM,keys,etc. Aftereditingasecondtimetocorrecttheconfigthepluginworksasnormal.Theproblemalsoaffectsconfigurationsupgradedfrom0.5. Thisisaregressionsince0.5. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23914) Invalid null/ element added to triggers/ in job causing NPE on job load
Craig Ringer updated JENKINS-23914 Invalid null/ element added to triggers/ in job causing NPE on job load bdr_linux_config.xml: config file for current working build. See prior comment for details. bdr_linux_broken_config.xml: config file last time I noticed it break. Change By: Craig Ringer (22/Jul/14 2:24 PM) Attachment: bdr_linux_config.xml Attachment: bdr_linux_broken_config.xml This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23914) Invalid null/ element added to triggers/ in job causing NPE on job load
Craig Ringer commented on JENKINS-23914 Invalid null/ element added to triggers/ in job causing NPE on job load Daniel, I've only edited them via the web UI, with the exception of repairing the null/ breakage the two times it's occurred. The job I've observed the issue with gets edited quite frequently. I've only noticed this problem a couple of times. Until recently I've always been in a rush when working on it so unfortunately I didn't note all the details. I'll attach the current config.xml . The version attached, the latest working version, has the build-timeout plugin enabled, but I only just installed that so it can be ignored for this purpose. Similarly, the s3-plugin in the config.xml is version s3@0.7-SNAPSHOT (because I've fixed a couple of bugs since 0.6), but I've seen the issue with 0.6 too. The config.xml is unedited. There's nothing secret in there, it's for an open source project anyway. I'll also attach the config.xml from the most recent time I noticed it break. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23915) When Jenkins can't read a job, it vanishes from the job-list instead of being replaced with an error marker
Craig Ringer commented on JENKINS-23915 When Jenkins cant read a job, it vanishes from the job-list instead of being replaced with an error marker Good point. In the mean time, hopefully people searching for "jenkins job vanished" will find this and know to look in the jenkins error log. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23914) Invalid null/ element added to triggers/ in job causing NPE on job load
Craig Ringer commented on JENKINS-23914 Invalid null/ element added to triggers/ in job causing NPE on job load I know this is frustratingly vague, by the way. I've cranked the log levels up and will be watching for it happening again. I'm pretty sure it's occurred as a result of exceptions being thrown during configuration save, but beyond that can't be too sure. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 I've been able to reproduce this with a trivial job and after limiting the node to a single executor. It is not consistently reproducible, it's somewhat random. I suspect it's dependent on the input being archived (10MB of randomly generated data), but it could also be just plain random. I'll attach the config.xml and thread dumps. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 If it is helpful, I can provision access to the build worker for anyone interested in this issue. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer updated JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 Build log is: Started by user Craig Ringer [EnvInject] - Loading node environment variables. Building remotely on fedora16-ppc64-Power7-osuosl-karman (ppc64 fedora16 ppc linux fedora) in workspace /home/jenkins/workspace/ppctest [ppctest] $ /bin/sh -xe /tmp/hudson9160124340407748260.sh + dd if=/dev/urandom of=dummy.out bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (10 MB) copied, 0.604488 s, 17.3 MB/s Archiving artifacts At the time the master stack was taken there was another build running. I'll see if I can capture another once it's idle. Change By: Craig Ringer (22/Jul/14 3:53 PM) Attachment: config.xml Attachment: jenkins-master-stack.txt Attachment: jenkins-slave-stack.txt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer updated JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 Master at idle Change By: Craig Ringer (22/Jul/14 4:32 PM) Attachment: jenkins-master-idle-stack.txt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ec2] (JENKINS-23935) Allow tags for all instances in an EC2 cloud configuration
Craig Ringer created JENKINS-23935 Allow tags for all instances in an EC2 cloud configuration Issue Type: New Feature Assignee: Francis Upton Components: ec2 Created: 23/Jul/14 12:09 AM Description: For cost and instance management it would be extremely useful to be able to configure a set of tags that apply to all instances. Right now, if you want to add, say, a BillingCategory tag, you have to add it to each individual instance type. With lots of instance types that adds up. Time permitting I'll have a go at implementing this, I just wanted to put the idea out there. Project: Jenkins Labels: ec2 tags Priority: Minor Reporter: Craig Ringer This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23915) When Jenkins can't read a job, it vanishes from the job-list instead of being replaced with an error marker
Craig Ringer commented on JENKINS-23915 When Jenkins cant read a job, it vanishes from the job-list instead of being replaced with an error marker I looked in there when getting the exception above from the logs. I don't recall the red-highlighted message about old/unreadable data appearing then. If I get the chance to restart the node I'll try intentionally breaking a build XML and seeing if it shows up. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer edited a comment on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 Attached a jstack for the master at idle except for the stuck connection. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 I cancelled the job after 12 hours. Console output was: Archiving artifacts ERROR: Failed to archive artifacts: **/dummy.out java.io.IOException: java.io.IOException: Failed to extract /home/jenkins/workspace/ppctest/transfer of 1 files at hudson.FilePath.readFromTar(FilePath.java:2119) at hudson.FilePath.copyRecursiveTo(FilePath.java:2031) at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:183) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:772) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:736) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:685) at hudson.model.Run.execute(Run.java:1757) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: java.io.IOException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:177) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) at com.jcraft.jzlib.InflaterInputStream.fill(InflaterInputStream.java:175) at com.jcraft.jzlib.InflaterInputStream.read(InflaterInputStream.java:106) at org.apache.tools.tar.TarBuffer.readBlock(TarBuffer.java:257) at org.apache.tools.tar.TarBuffer.readRecord(TarBuffer.java:223) at hudson.org.apache.tools.tar.TarInputStream.read(TarInputStream.java:345) at java.io.FilterInputStream.read(FilterInputStream.java:107) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1792) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1769) at org.apache.commons.io.IOUtils.copy(IOUtils.java:1744) at hudson.util.IOUtils.copy(IOUtils.java:40) at hudson.FilePath.readFromTar(FilePath.java:2109) ... 12 more at hudson.FilePath.copyRecursiveTo(FilePath.java:2038) at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:183) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:772) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:736) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:685) at hudson.model.Run.execute(Run.java:1757) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:234) Caused by: java.util.concurrent.ExecutionException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request$1.get(Request.java:278) at hudson.remoting.Request$1.get(Request.java:210) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59) at hudson.FilePath.copyRecursiveTo(FilePath.java:2034) ... 11 more Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:802) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2323) at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2792) at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:800) at java.io.ObjectInputStream.init(ObjectInputStream.java:298) at hudson.remoting.ObjectInputStreamEx.init(ObjectInputStreamEx.java:40) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Build step 'Archive
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 A re-run with the exact same data to archive succeeded. So this looks like an intermittent fault. Timing, threading, memory, etc. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer edited a comment on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 A re-run with the exact same data to archive succeeded. So this looks like an intermittent fault. Timing, threading, memory, etc. A second re-run got stuck. Fun. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-23917) Protocol deadlock while uploading artifacts from ppc64
Craig Ringer commented on JENKINS-23917 Protocol deadlock while uploading artifacts from ppc64 I've progressively reduced the archive file size. It has got stuck with files as small as 128k. So far tests with 16k files haven't failed. I'm trying to narrow down whether it can occur with v.small archive files (and is just less likely) or if it's size related. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
