[JIRA] (JENKINS-41468) JobDSL of ArtifactoryRedeployPublisher failing due to missing customBuildName
Title: Message Title
Ed Randall created an issue
Jenkins / JENKINS-41468
JobDSL of ArtifactoryRedeployPublisher failing due to missing customBuildName
Issue Type:
Bug
Assignee:
Eyal Ben Moshe
Components:
artifactory-plugin
Created:
2017/Jan/26 8:56 AM
Environment:
Jenkins 2.32.1 Artifactory-Plugin 2.9.0
Priority:
Major
Reporter:
Ed Randall
Since updating from 2.8.1 to 2.9.0 the JobDSL for many of our jobs has begin failing with the following error: ERROR: (XXXscript.groovy, line 88) the following options are required and must be specified: customBuildName, overrideBuildName By definition these fields are optional, this is not expected; To work around this we have had to update a number of job configurations as follows, since the upgrade: artifactoryRedeployPublisher { customBuildName(null) overrideBuildName(false) ... }
Add Comment
[JIRA] (JENKINS-8028) Plugin update installer downloads "302 redirect" response as the .hpi file, then reports success.
Title: Message Title Ed Randall assigned an issue to Unassigned Jenkins / JENKINS-8028 Plugin update installer downloads "302 redirect" response as the .hpi file, then reports success. Change By: Ed Randall Assignee: Ed Randall Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ant-plugin] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
Title: Message Title Ed Randall edited a comment on JENKINS-13044 Re: Ant multiple properties delimited by spaces parsed as a single property You can argue technical points 'til the cows come home, but bad user experience is bad user experience . , it tripped up at least 2 people who could be bothered to come here and look for it, I wonder how many others Don't even fix the help text? It would have taken someone who knows the system less time than writing a comment here - certainly less than 4 years since I raised this in good faith. Just add the words "each on a new line"Why not, just leave it. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ant-plugin] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
Title: Message Title Ed Randall edited a comment on JENKINS-13044 Re: Ant multiple properties delimited by spaces parsed as a single property You can argue technical points 'til the cows come home, but bad user experience is bad user experience.Don't even fix the help text? It would have taken someone who knows the system less time than writing a comment here - certainly less than 4 years since I raised this in good faith . Just add the words "each on a new line" Why not, just leave it. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ant-plugin] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
Title: Message Title Ed Randall edited a comment on JENKINS-13044 Re: Ant multiple properties delimited by spaces parsed as a single property You can argue technical points 'til the cows come home, but bad user experience is bad user experience.Don't even fix the help text? It wpuld have taken somepone who knows the system, less time than writing a comment here - certainly less than 4 years. Why not, just leave it. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ant-plugin] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
Title: Message Title Ed Randall edited a comment on JENKINS-13044 Re: Ant multiple properties delimited by spaces parsed as a single property You can argue technical points 'til the cows come home, but bad user experience is bad user experience.Don't even fix the help text? It wpuld would have taken somepone someone who knows the system , less time than writing a comment here - certainly less than 4 years. Why not, just leave it. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ant-plugin] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
Title: Message Title Ed Randall commented on JENKINS-13044 Re: Ant multiple properties delimited by spaces parsed as a single property You can argue technical points 'til the cows come home, but bad user experience is bad user experience. Don't even fix the help text? Why not, just leave it. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [ant-plugin] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
Title: Message Title Ed Randall commented on JENKINS-13044 Re: Ant multiple properties delimited by spaces parsed as a single property Whatever the standard java prioperties file format says, this is a user interface element and should follow the principal of least surprise. The behaviour was not what the documentation described and not what the user expected. As a minimum the documentation should be fixed, ideally the box should be more than one line line high by default. Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-7695) archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Title: Message Title
Ed Randall edited a comment on JENKINS-7695
Re: archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Am also experiencing similar, in 1.596.2{code}17:13:41 GMT+01:00 Archiving artifacts17:13:43 GMT+01:00 ERROR: Failed to archive artifacts: LOGS/,target/**/LOGS/,target/robotframework/17:13:43 GMT+01:00 java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2213)17:13:43 GMT+01:00 at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)17:13:43 GMT+01:00 at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218)17:13:43 GMT+01:00 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.builder.FailFastBuilder.perform(FailFastBuilder.java:102)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.strategy.FailFastExecutionStrategy.perform(FailFastExecutionStrategy.java:63)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:206)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:124)17:13:43 GMT+01:00 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)17:13:43 GMT+01:00 at hudson.model.Build$BuildExecution.post2(Build.java:183)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)17:13:43 GMT+01:00 at hudson.model.Run.execute(Run.java:1784)17:13:43 GMT+01:00 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)17:13:43 GMT+01:00 at hudson.model.ResourceController.execute(ResourceController.java:89)17:13:43 GMT+01:00 at hudson.model.Executor.run(Executor.java:240)17:13:43 GMT+01:00 Caused by: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:784)17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:779)17:13:43 GMT+01:00 at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55)17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2211)17:13:43 GMT+01:00 ... 19 more17:13:43 GMT+01:00 Caused by: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.org.apache.tools.tar.TarOutputStream.write(TarOutputStream.java:284)17:13:43 GMT+01:00 at hudson.util.io.TarArchiver.visit(TarArchiver.java:114)17:13:43 GMT+01:00 at hudson.util.DirScanner.scanSingle(DirScanner.java:49)17:13:43 GMT+01:00 at hudson.FilePath$ExplicitlySpecifiedDirScanner.scan(FilePath.java:2764)17:13:43 GMT+01:00 at hudson.FilePath.writeToTar(FilePath.java:2249)17:13:43 GMT+01:00 at hudson.FilePath.access$2100(FilePath.java:191)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2190)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2186)17:13:43 GMT+01:00
[JIRA] [core] (JENKINS-7695) archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Title: Message Title
Ed Randall edited a comment on JENKINS-7695
Re: archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Am also experiencing similar, in 1.596.2{code}17:13:41 GMT+01:00 Archiving artifacts17:13:43 GMT+01:00 ERROR: Failed to archive artifacts: LOGS/,target/**/LOGS/,target/robotframework/17:13:43 GMT+01:00 java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2213)17:13:43 GMT+01:00 at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)17:13:43 GMT+01:00 at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218)17:13:43 GMT+01:00 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.builder.FailFastBuilder.perform(FailFastBuilder.java:102)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.strategy.FailFastExecutionStrategy.perform(FailFastExecutionStrategy.java:63)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:206)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:124)17:13:43 GMT+01:00 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)17:13:43 GMT+01:00 at hudson.model.Build$BuildExecution.post2(Build.java:183)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)17:13:43 GMT+01:00 at hudson.model.Run.execute(Run.java:1784)17:13:43 GMT+01:00 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)17:13:43 GMT+01:00 at hudson.model.ResourceController.execute(ResourceController.java:89)17:13:43 GMT+01:00 at hudson.model.Executor.run(Executor.java:240)17:13:43 GMT+01:00 Caused by: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:784)17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:779)17:13:43 GMT+01:00 at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55)17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2211)17:13:43 GMT+01:00 ... 19 more17:13:43 GMT+01:00 Caused by: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.org.apache.tools.tar.TarOutputStream.write(TarOutputStream.java:284)17:13:43 GMT+01:00 at hudson.util.io.TarArchiver.visit(TarArchiver.java:114)17:13:43 GMT+01:00 at hudson.util.DirScanner.scanSingle(DirScanner.java:49)17:13:43 GMT+01:00 at hudson.FilePath$ExplicitlySpecifiedDirScanner.scan(FilePath.java:2764)17:13:43 GMT+01:00 at hudson.FilePath.writeToTar(FilePath.java:2249)17:13:43 GMT+01:00 at hudson.FilePath.access$2100(FilePath.java:191)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2190)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2186)17:13:43 GMT+01:00
[JIRA] [core] (JENKINS-7695) archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Title: Message Title
Ed Randall edited a comment on JENKINS-7695
Re: archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Am also experiencing similar, in 1.596.2{code}17:13:41 GMT+01:00 Archiving artifacts17:13:43 GMT+01:00 ERROR: Failed to archive artifacts: LOGS/,target/**/LOGS/,target/robotframework/17:13:43 GMT+01:00 java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2213)17:13:43 GMT+01:00 at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)17:13:43 GMT+01:00 at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218)17:13:43 GMT+01:00 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.builder.FailFastBuilder.perform(FailFastBuilder.java:102)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.strategy.FailFastExecutionStrategy.perform(FailFastExecutionStrategy.java:63)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:206)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:124)17:13:43 GMT+01:00 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)17:13:43 GMT+01:00 at hudson.model.Build$BuildExecution.post2(Build.java:183)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)17:13:43 GMT+01:00 at hudson.model.Run.execute(Run.java:1784)17:13:43 GMT+01:00 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)17:13:43 GMT+01:00 at hudson.model.ResourceController.execute(ResourceController.java:89)17:13:43 GMT+01:00 at hudson.model.Executor.run(Executor.java:240)17:13:43 GMT+01:00 Caused by: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:784)17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:779)17:13:43 GMT+01:00 at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55)17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2211)17:13:43 GMT+01:00 ... 19 more17:13:43 GMT+01:00 Caused by: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.org.apache.tools.tar.TarOutputStream.write(TarOutputStream.java:284)17:13:43 GMT+01:00 at hudson.util.io.TarArchiver.visit(TarArchiver.java:114)17:13:43 GMT+01:00 at hudson.util.DirScanner.scanSingle(DirScanner.java:49)17:13:43 GMT+01:00 at hudson.FilePath$ExplicitlySpecifiedDirScanner.scan(FilePath.java:2764)17:13:43 GMT+01:00 at hudson.FilePath.writeToTar(FilePath.java:2249)17:13:43 GMT+01:00 at hudson.FilePath.access$2100(FilePath.java:191)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2190)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2186)17:13:43 GMT+01:00
[JIRA] [core] (JENKINS-7695) archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Title: Message Title
Ed Randall edited a comment on JENKINS-7695
Re: archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Am also experiencing similar, in 1.596.2{ quote code } 17:13:41 GMT+01:00 Archiving artifacts17:13:43 GMT+01:00 ERROR: Failed to archive artifacts: LOGS/,target/**/LOGS/,target/robotframework/17:13:43 GMT+01:00 java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2213)17:13:43 GMT+01:00 at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)17:13:43 GMT+01:00 at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218)17:13:43 GMT+01:00 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.builder.FailFastBuilder.perform(FailFastBuilder.java:102)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.strategy.FailFastExecutionStrategy.perform(FailFastExecutionStrategy.java:63)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:206)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:124)17:13:43 GMT+01:00 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)17:13:43 GMT+01:00 at hudson.model.Build$BuildExecution.post2(Build.java:183)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)17:13:43 GMT+01:00 at hudson.model.Run.execute(Run.java:1784)17:13:43 GMT+01:00 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)17:13:43 GMT+01:00 at hudson.model.ResourceController.execute(ResourceController.java:89)17:13:43 GMT+01:00 at hudson.model.Executor.run(Executor.java:240)17:13:43 GMT+01:00 Caused by: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:784)17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:779)17:13:43 GMT+01:00 at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55)17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2211)17:13:43 GMT+01:00 ... 19 more17:13:43 GMT+01:00 Caused by: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.org.apache.tools.tar.TarOutputStream.write(TarOutputStream.java:284)17:13:43 GMT+01:00 at hudson.util.io.TarArchiver.visit(TarArchiver.java:114)17:13:43 GMT+01:00 at hudson.util.DirScanner.scanSingle(DirScanner.java:49)17:13:43 GMT+01:00 at hudson.FilePath$ExplicitlySpecifiedDirScanner.scan(FilePath.java:2764)17:13:43 GMT+01:00 at hudson.FilePath.writeToTar(FilePath.java:2249)17:13:43 GMT+01:00 at hudson.FilePath.access$2100(FilePath.java:191)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2190)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2186)17:13:43
[JIRA] [core] (JENKINS-7695) archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Title: Message Title
Ed Randall edited a comment on JENKINS-7695
Re: archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Am also experiencing similar, in 1.596.2{ { quote} 17:13:41 GMT+01:00 Archiving artifacts17:13:43 GMT+01:00 ERROR: Failed to archive artifacts: LOGS/,target/**/LOGS/,target/robotframework/17:13:43 GMT+01:00 java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2213)17:13:43 GMT+01:00 at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61)17:13:43 GMT+01:00 at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218)17:13:43 GMT+01:00 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.builder.FailFastBuilder.perform(FailFastBuilder.java:102)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.strategy.FailFastExecutionStrategy.perform(FailFastExecutionStrategy.java:63)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:206)17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:124)17:13:43 GMT+01:00 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734)17:13:43 GMT+01:00 at hudson.model.Build$BuildExecution.post2(Build.java:183)17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683)17:13:43 GMT+01:00 at hudson.model.Run.execute(Run.java:1784)17:13:43 GMT+01:00 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)17:13:43 GMT+01:00 at hudson.model.ResourceController.execute(ResourceController.java:89)17:13:43 GMT+01:00 at hudson.model.Executor.run(Executor.java:240)17:13:43 GMT+01:00 Caused by: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:784)17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:779)17:13:43 GMT+01:00 at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55)17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2211)17:13:43 GMT+01:00 ... 19 more17:13:43 GMT+01:00 Caused by: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log'17:13:43 GMT+01:00 at hudson.org.apache.tools.tar.TarOutputStream.write(TarOutputStream.java:284)17:13:43 GMT+01:00 at hudson.util.io.TarArchiver.visit(TarArchiver.java:114)17:13:43 GMT+01:00 at hudson.util.DirScanner.scanSingle(DirScanner.java:49)17:13:43 GMT+01:00 at hudson.FilePath$ExplicitlySpecifiedDirScanner.scan(FilePath.java:2764)17:13:43 GMT+01:00 at hudson.FilePath.writeToTar(FilePath.java:2249)17:13:43 GMT+01:00 at hudson.FilePath.access$2100(FilePath.java:191)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2190)17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2186)17:13:43 GMT+0
[JIRA] [core] (JENKINS-7695) archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Title: Message Title
Ed Randall commented on JENKINS-7695
Re: archiving throws hudson.util.IOException2: java.io.IOException: request to write '3977' bytes exceeds size in header of '41955006'
Am also experiencing similar, in 1.596.2
{{17:13:41 GMT+01:00 Archiving artifacts 17:13:43 GMT+01:00 ERROR: Failed to archive artifacts: LOGS/,target/**/LOGS/,target/robotframework/ 17:13:43 GMT+01:00 java.io.IOException: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log' 17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2213) 17:13:43 GMT+01:00 at jenkins.model.StandardArtifactManager.archive(StandardArtifactManager.java:61) 17:13:43 GMT+01:00 at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:218) 17:13:43 GMT+01:00 at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:74) 17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.builder.FailFastBuilder.perform(FailFastBuilder.java:102) 17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$2.run(BuildStepRunner.java:110) 17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail.conditionalRun(BuildStepRunner.java:154) 17:13:43 GMT+01:00 at org.jenkins_ci.plugins.run_condition.BuildStepRunner.perform(BuildStepRunner.java:105) 17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.strategy.FailFastExecutionStrategy.perform(FailFastExecutionStrategy.java:63) 17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.ConditionalPublisher.perform(ConditionalPublisher.java:206) 17:13:43 GMT+01:00 at org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.perform(FlexiblePublisher.java:124) 17:13:43 GMT+01:00 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) 17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) 17:13:43 GMT+01:00 at hudson.model.Build$BuildExecution.post2(Build.java:183) 17:13:43 GMT+01:00 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) 17:13:43 GMT+01:00 at hudson.model.Run.execute(Run.java:1784) 17:13:43 GMT+01:00 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 17:13:43 GMT+01:00 at hudson.model.ResourceController.execute(ResourceController.java:89) 17:13:43 GMT+01:00 at hudson.model.Executor.run(Executor.java:240) 17:13:43 GMT+01:00 Caused by: java.util.concurrent.ExecutionException: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log' 17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:784) 17:13:43 GMT+01:00 at hudson.remoting.Channel$3.adapt(Channel.java:779) 17:13:43 GMT+01:00 at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55) 17:13:43 GMT+01:00 at hudson.FilePath.copyRecursiveTo(FilePath.java:2211) 17:13:43 GMT+01:00 ... 19 more 17:13:43 GMT+01:00 Caused by: java.io.IOException: request to write '3085' bytes exceeds size in header of '2581956' bytes for entry 'target/path/to/file_20_05_2015.log' 17:13:43 GMT+01:00 at hudson.org.apache.tools.tar.TarOutputStream.write(TarOutputStream.java:284) 17:13:43 GMT+01:00 at hudson.util.io.TarArchiver.visit(TarArchiver.java:114) 17:13:43 GMT+01:00 at hudson.util.DirScanner.scanSingle(DirScanner.java:49) 17:13:43 GMT+01:00 at hudson.FilePath$ExplicitlySpecifiedDirScanner.scan(FilePath.java:2764) 17:13:43 GMT+01:00 at hudson.FilePath.writeToTar(FilePath.java:2249) 17:13:43 GMT+01:00 at hudson.FilePath.access$2100(FilePath.java:191) 17:13:43 GMT+01:00 at hudson.FilePath$45.invoke(FilePath.java:2190) 17
[JIRA] [xshell-plugin] (JENKINS-28038) xshell should make itself available in "conditional build step" and "post-build actions" lists
Ed Randall edited a comment on JENKINS-28038 xshell should make itself available in "conditional build step" and "post-build actions" lists From the Conditional BuildStep plugin wiki page: Missing builder If you're not able to add the builder of your choice within a conditional build step (because it's not available within the dropdown), then this is likely because the builder does not provide a @DataBoundConstructor constructor and/or the Descriptor does not extend hudson.tasks.BuildStepDescriptor. For non programmers: the plugin you would like to use does not yet follow the newest Jenkins coding guidelines. Without this, the conditional buildstep plugin is not able to work with 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] [xshell-plugin] (JENKINS-28038) xshell should make itself available in "conditional build step" and "post-build actions" lists
Ed Randall commented on JENKINS-28038 xshell should make itself available in "conditional build step" and "post-build actions" lists From the "Conditional BuildStep plugin" wiki page: Missing builder If you're not able to add the builder of your choice within a conditional build step (because it's not available within the dropdown), then this is ikely because the builder does not provide a @DataBoundConstructor constructor and/or the Descriptor does not extend hudson.tasks.BuildStepDescriptor. For non programmers: the plugin you would like to use does not yet follow the newest Jenkins coding guidelines. Without this, the conditional buildstep plugin is not able to work with 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] [heavy-job-plugin] (JENKINS-28061) Heavy-job-plugin to consistently use first executor on a node
Ed Randall created JENKINS-28061 Heavy-job-plugin to consistently use first executor on a node Issue Type: Improvement Assignee: Unassigned Components: heavy-job-plugin Created: 23/Apr/15 9:46 AM Description: heavy-job-plugin randomly picks an executor on the slave node to actually run the job and marks the other "n-1" executors as unavailable. We use a maven repository-per-executor and this behaviour means that all the repositories eventually get very large. If the executor picked was consistently the lowest-numbered one (ie. #1 on a slave where all are allocated to the heavy job) this would help. Perhaps this could be configured via a checkbox "Use first available executor on the slave". Environment: heavy-job-plugin 1.1 jenkins 1.596.2 Project: Jenkins Labels: heavy-job Priority: Minor Reporter: Ed Randall 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] [xshell-plugin] (JENKINS-28038) xshell should make itself available in "conditional build step" and "post-build actions" lists
Ed Randall created JENKINS-28038 xshell should make itself available in "conditional build step" and "post-build actions" lists Issue Type: Improvement Assignee: Unassigned Components: xshell-plugin Created: 22/Apr/15 12:13 PM Description: xshell-plugin appears only in the drop-down list of normal build steps. I want to run a script via xshell-plugin as a conditional build step but it doesn't register itself with conditional-buildstep so isn't available in the list there; Likewise I want to run an xshell script as a post-build action (so it doesn't affect the build status) but it isn't available in the list of available Post-Build Actions; Also I want to run it as a conditional post-build action (via flexible-publish-plugin) but it doesn't appear in the list of available actions there either. Environment: Jenkins-1.596.2 Xshell-0.10 Conditional-buildstep-1.3.3 Flexible-publish-plugin-0.14.1 Project: Jenkins Labels: xshell post-build flexible-publish conditional-buildstep Priority: Major Reporter: Ed Randall 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-26862) Jenkins should set a SecurityManager (prevent rogue scripts exiting)
Ed Randall created JENKINS-26862 Jenkins should set a SecurityManager (prevent rogue scripts exiting) Issue Type: Improvement Assignee: vjuranek Components: core, groovy-plugin Created: 09/Feb/15 5:02 PM Description: Jenkins should set a SecurityManager and explicity trap out calls to System.exit from plugins. This would prevent eg. the following script from taking out the whole web container: System.exit(0) Groovy even provides a NoExitSecurityManager for this purpose. Environment: Any Project: Jenkins Priority: Major Reporter: Ed Randall 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] [groovy-plugin] (JENKINS-14023) System.exit (13) in a groovy script causes Jenkins shutdown
Ed Randall commented on JENKINS-14023 System.exit (13) in a groovy script causes Jenkins shutdown This behaviour could probably be fixed by setting a securitymanager. Groovy even provides NoExitSecurityManager for this exact purpose. See http://stackoverflow.com/questions/1429610/prevent-system-exit-in-a-groovy-web-console-without-security-policy-file This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-timeout] (JENKINS-21543) "Likely stuck" timed out the build after 0 minutes
Ed Randall commented on JENKINS-21543 "Likely stuck" timed out the build after 0 minutes Problem is that "build timeout" triggers against a build which is progressing normally, not stuck. It triggers almost immediately, which seems pointless. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-timeout] (JENKINS-21543) "Likely stuck" timed out the build after 0 minutes
Ed Randall edited a comment on JENKINS-21543 "Likely stuck" timed out the build after 0 minutes What is it that works correct? Our environment is given up the top of this JIRA, Expected behaviour is that Jenkins uses some heuristic to detect that a build is "likely stuck. But when we use this option it just aborts immediately, as shown. A build can't possibly be stuck after 0 minutes. We occasionally get builds that are genuinely stuck, we notice this after maybe 3 hours or more. It would be useful if this feature worked so we could use it to abort those. If the feature aborts every build after 0 minutes it's not much use though. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-timeout] (JENKINS-21543) "Likely stuck" timed out the build after 0 minutes
Ed Randall edited a comment on JENKINS-21543 "Likely stuck" timed out the build after 0 minutes What is it that works correct? Our environment is given up the top of this JIRA, Expected behaviour is that Jenkins uses some heuristic to detect that a build is "likely stuck. But when we use this option it just aborts immediately, as shown. A build can't possibly be stuck after 0 minutes. We occasionally get builds that are genuinely stuck, we notice this after maybe 3 hours or more. It would be useful if this feature worked so we could use it to abort those. If it aborts every build after 0 monutes it's not much use though. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-timeout] (JENKINS-21543) "Likely stuck" timed out the build after 0 minutes
Ed Randall commented on JENKINS-21543 "Likely stuck" timed out the build after 0 minutes What is it that works correct? Expected behaviour is that Jenkins uses some heuristic to detect that a build is "likely stuck. But when we use this option it just aborts immediately, as shown. A build can't possibly be stuck after 0 minutes. We occasionally get builds that are genuinely stuck, we notice this after maybe 3 hours or more. It would be useful if this feature worked so we could use it to abort those. If it aborts every build after 0 monutes it's not much use though. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-monitor] (JENKINS-23506) URLs in Build-Monitor-Plugin view are broken if Cloudbees-Folders-Plugin is in use
Ed Randall commented on JENKINS-23506 URLs in Build-Monitor-Plugin view are broken if Cloudbees-Folders-Plugin is in use A sub-folder URL containing some actual projects (jobs): http://hostname/view/Web.Projects/job/Web.Projects.XYZ.trunk/ Link to a monitor view created at that sub-folder level: http://hostname/view/Web.Projects/job/Web.Projects.XYZ.trunk/view/XYZMonitor/ Link from square on monitor view to a job: http://hostname/view/Web.Projects/job/Web.Projects.XYZ.trunk/view/XYZMonitor/job/Web.Projects.XYZ.trunk/job/xyz_server.checkin/ But that link should actually be: http://hostname/view/Web.Projects/job/Web.Projects.XYZ.trunk/job/xyz_server.checkin/ If I try to create and configure a view at the top level: http://hostname/view/XYZMonitor2/configure Only the folder "Web.Projects.XYZ.trunk" is offered as a "job", none of the real jobs are visible; Select it anyway and click OK; the view appears with text: It seems a bit empty here... Maybe you'd like to add some jobs to this monitor? The link takes you back to http://hostname/view/XYZMonitor2/configure This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-monitor] (JENKINS-23506) URLs in Build-Monitor-Plugin view are broken if Cloudbees-Folders-Plugin is in use
Ed Randall created JENKINS-23506 URLs in Build-Monitor-Plugin view are broken if Cloudbees-Folders-Plugin is in use Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: build-monitor Created: 20/Jun/14 10:15 AM Description: Using: Build Monitor Plugin version 1.4+build.102 Cloudbees Folders plugin 4.2.1 Jenkins 1.554.2 We have many jobs hence we categorize them using subfolders using Cloudbees Folders plugin. The Builc Monitor View, if created at the top level, can't be configured to see the jobs at all. You get a blank view. If created at the subfolder level where the jobs exist, it can see them, but the links to each project is incorrect. Project: Jenkins Labels: plugin build-monitor-plugin Priority: Major Reporter: Ed Randall 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-21550) cron trigger parsing is unfriendly (misleading error + stack trace)
Ed Randall edited a comment on JENKINS-21550 cron trigger parsing is unfriendly (misleading error + stack trace) The message could be friendlier if it printed the remainder of the offending line, rather than just the single character. With a proportional font it is not always possible to discern a single space between quotes. At the lime I raised the defect I don't think I appreciated that "line 1:10" meant "line 1 character 10". (Perhaps I was being stupid!) But if it were to print explicitly and clearly what's wrong rather than in a slightly technical format, it can only help a pressured user. 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-21550) cron trigger parsing is unfriendly (misleading error + stack trace)
Ed Randall edited a comment on JENKINS-21550 cron trigger parsing is unfriendly (misleading error + stack trace) The message could be friendlier if it printed the remainder of the offending line, rather than just the single character. At the lime I raised the defect I don't think I appreciated that "line 1:10" meant "line 1 character 10". (Perhaps I was being stupid!) But if you print explicitly and clearly what's wrong rather than in a slightly technical format, it can only help a pressured user. 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-21550) cron trigger parsing is unfriendly (misleading error + stack trace)
Ed Randall edited a comment on JENKINS-21550 cron trigger parsing is unfriendly (misleading error + stack trace) The message could be friendlier if it printed the remainder of the offending line, rather than just the single character. At the lime I raised the defect I don't think I appreciated that "line 1:10" meant "line 1 character 10". (Perhaps I was being stupid!) But if it were to print explicitly and clearly what's wrong rather than in a slightly technical format, it can only help a pressured user. 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-21550) cron trigger parsing is unfriendly (misleading error + stack trace)
Ed Randall commented on JENKINS-21550 cron trigger parsing is unfriendly (misleading error + stack trace) The message could be friendlier if it printed the remainder of the offending line, rather than just the single character. At the lime I raised the defect I don't think I appreciated that "line 1:10" meant line 1 character 10. (Perhaps I was being stupid!) But if you print explicitly and clearly what's wrong rather than in a slightly technical format, it can only help a pressured user. 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] [disk-usage] (JENKINS-21576) NPE NullPointerException in DiskUsagePlugin
Ed Randall created JENKINS-21576 NPE NullPointerException in DiskUsagePlugin Issue Type: Bug Affects Versions: current Assignee: Lucie Votypkova Components: disk-usage Created: 30/Jan/14 6:17 PM Description: [#|2014-01-30T18:07:17.158+|WARNING|glassfish3.1.2|hudson.plugins.disk_usage.DiskUsageBuildListener|_ThreadID=106;_ThreadName=Thread-2;|Disk usage plugin fails during build calculation disk space of job [trunk.overnight] account_master_client_functions java.lang.NullPointerException at hudson.plugins.disk_usage.DiskUsageUtil.controlorkspaceExceedSize(DiskUsageUtil.java:96) at hudson.plugins.disk_usage.DiskUsageBuildListener.onCompleted(DiskUsageBuildListener.java:63) at hudson.plugins.disk_usage.DiskUsageBuildListener.onCompleted(DiskUsageBuildListener.java:23) at hudson.model.listeners.RunListener.fireCompleted(RunListener.java:199) at hudson.model.Run.execute(Run.java:1715) at hudson.plugins.project_inheritance.projects.InheritanceBuild.run(InheritanceBuild.java:96) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:246) Environment: Jenkins LTS 1.532.1 Jenkins disk-usage plugin 0.23 Project: Jenkins Priority: Major Reporter: Ed Randall This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [core] (JENKINS-21550) cron trigger parsing is unfriendly (misleading error + stack trace)
Ed Randall
created JENKINS-21550
cron trigger parsing is unfriendly (misleading error + stack trace)
Issue Type:
Bug
Affects Versions:
current
Assignee:
Unassigned
Components:
core
Created:
29/Jan/14 3:29 PM
Description:
I entered a simple cron _expression_ accidentally adding an extra field:
H 0 * * * *
The error message was very misleading:
Invalid input: "H 0 * * * *": line 1:10: expecting EOF, found ' '
Hitting "Save" anyway gave:
Caused by: java.lang.IllegalArgumentException: Failed to instantiate class hudson.triggers.SCMTrigger from {"scmpoll_spec":"H 0 * * * *\n","ignorePostCommitHooks":false}
at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:597)
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:392)
at org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:388)
at hudson.model.Descriptor.newInstance(Descriptor.java:567)
... 88 more
Caused by: java.lang.IllegalArgumentException: antlr.ANTLRException: Invalid input: "H 0 * * * *": line 1:10: expecting EOF, found ' '
at org.kohsuke.stapler.RequestImpl.invokeConstructor(RequestImpl.java:454)
at org.kohsuke.stapler.RequestImpl.access$200(RequestImpl.java:77)
at org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:595)
... 91 more
Caused by: antlr.ANTLRException: Invalid input: "H 0 * * * *": line 1:10: expecting EOF, found ' '
at hudson.scheduler.CronTabList.create(CronTabList.java:87)
at hudson.scheduler.CronTabList.create(CronTabList.java:73)
at hudson.triggers.Trigger.(Trigger.java:161)
at hudson.triggers.SCMTrigger.(SCMTrigger.java:85)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at org.kohsuke.stapler.RequestImpl.invokeConstructor(RequestImpl.java:439)
... 93 more
Caused by: line 1:10: expecting EOF, found ' '
at antlr.Parser.match(Parser.java:211)
at hudson.scheduler.CrontabParser.startRule(CrontabParser.java:67)
at hudson.scheduler.CronTab.set(CronTab.java:93)
at hudson.scheduler.CronTab.(CronTab.java:83)
at hudson.scheduler.CronTabList.create(CronTabList.java:85)
... 101 more
Environment:
Jenkins LTS 1.532.1
Linux CentOS6.5
Project:
Jenkins
Priority:
Minor
Reporter:
Ed Randall
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [build-timeout] (JENKINS-21543) "Likely stuck" timed out the build after 0 minutes
Ed Randall created JENKINS-21543 "Likely stuck" timed out the build after 0 minutes Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: build-timeout Created: 29/Jan/14 10:08 AM Description: The job was set to: Abort the build if it's stuck Likely stuck 09:49:36 Started by user anonymous 09:49:36 [EnvInject] - Loading node environment variables. 09:49:36 Building remotely on slave-02 in workspace /home/jenkins/jenkins-slave/workspace/static_data_client_functions.checkin 09:49:36 Checking out a fresh workspace because there's no workspace at /home/jenkins/jenkins-slave/workspace/static_data_client_functions.checkin 09:49:36 Cleaning local Directory . 09:49:36 Checking out svn://host.../path/.../trunk at revision '2014-01-29T09:49:36.068 +' 09:49:37 A src 09:49:37 A src/test 09:49:37 A src/test/java ... etc ... 09:49:38 A src/main/resources 09:49:38 A pom.xml 09:49:38 U. 09:49:38 At revision 984 09:49:38 no revision recorded for svn://host.../path.../trunk in the previous build 09:49:38 [static_data_client_functions.checkin] $ /home/jenkins/tools/maven/bin/mvn clean install --update-snapshots --batch-mode 09:49:40 Build timed out (after 0 minutes). Marking the build as aborted. 09:49:40 Build was aborted 09:49:40 Build Aborted. Not looking for any TestNG results. 09:49:40 Finished: ABORTED Environment: Centos 6.5 Linux jenkins-master 2.6.32-431.3.1.el6.x86_64 #1 SMP Fri Jan 3 21:39:27 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux JDK 1.7.0_51 Jenkins 1.532.1 build timeout plugin 1.12.2 Jenkins master/slave configuration (all builds take place on slaves) Project: Jenkins Priority: Major Reporter: Ed Randall This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16140) Clock on this slave is out of sync with the master
Ed Randall edited a comment on JENKINS-16140 Clock on this slave is out of sync with the master Are you sure it is jenkins' responsibility to synchronize the clock (it is an operating system service after all). Can you not use the appropriate VM service or NTP to synchronize the clocks? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16140) Clock on this slave is out of sync with the master
Ed Randall commented on JENKINS-16140 Clock on this slave is out of sync with the master Are you sure it is jenkmins' responsibility to synchronize the clock (it is an operating system service after all). Can you not use the appropriate VM service or NTP to synchronize the clocks? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
[ https://issues.jenkins-ci.org/browse/JENKINS-13044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161678#comment-161678 ] Ed Randall edited comment on JENKINS-13044 at 4/17/12 9:31 AM: --- This bug is very specific to the conditions described, ie. it occurs only when multiple properties are entered on ONE line, delimited by a SPACE. There's nothing stopping you from entering multiple properties, if you drop down (expand) the box and enter your properties one-per-line (separated by a NEWLINE) then it works fine. But the documentation describes that it should be possible to enter them all on one line and that doesn't work. was (Author: edrandall): This bug is very specific to the conditions described, ie. it occurs only when multiple properties are entered on ONE line, delimited by a SPACE. There's nothing stopping you from entering multiple properties, if you drop down (expand) the box and enter your properties one-per-line then it works fine. But the documentation describes that it should be possible to enter them all on one line and that doesn't work. > Ant multiple properties delimited by spaces parsed as a single property > --- > > Key: JENKINS-13044 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13044 > Project: Jenkins > Issue Type: Bug > Components: ant >Affects Versions: current > Environment: SunOS ldnwebv10 5.10 Generic_120012-14 i86pc i386 i86pc > Solaris > Jenkins STABLE 1.424.3 >Reporter: Ed Randall > > Configuring an Ant task on a job with multiple properties on 1 line separated > by a space, ie.: > name1=value1 name2=value2 > Results at execution time in: > ant ... "-Dname1=value1 name2=value2" > This is not expected, what I would expect from the documentation is: > -Dname1=value1 -Dname2=value2 > etc. > eg. > Properties: offline=1 user.prefs.dir=/home/hudson/config/Bedrock-DEV-config > user.bedrock.properties=bedrock-quicktest.properties > console log: > [Bedrock-DEV-GF-EL-03-quick-test] $ > /home/hudson/tools/apache-ant-1.7.1/bin/ant > -DUPSTREAM_BUILD_TAG=jenkins-Bedrock-DEV-GF-EL-01-compile-2656 > -DP4_CHANGELIST_PARAM=322808 "-Doffline=1 > user.prefs.dir=/home/hudson/config/Bedrock-DEV-config > user.bedrock.properties=bedrock-quicktest.properties" hudson.quicktests > Buildfile: build.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
[ https://issues.jenkins-ci.org/browse/JENKINS-13044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=161678#comment-161678 ] Ed Randall commented on JENKINS-13044: -- This bug is very specific to the conditions described, ie. it occurs only when multiple properties are entered on ONE line, delimited by a SPACE. There's nothing stopping you from entering multiple properties, if you drop down (expand) the box and enter your properties one-per-line then it works fine. But the documentation describes that it should be possible to enter them all on one line and that doesn't work. > Ant multiple properties delimited by spaces parsed as a single property > --- > > Key: JENKINS-13044 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13044 > Project: Jenkins > Issue Type: Bug > Components: ant >Affects Versions: current > Environment: SunOS ldnwebv10 5.10 Generic_120012-14 i86pc i386 i86pc > Solaris > Jenkins STABLE 1.424.3 >Reporter: Ed Randall > > Configuring an Ant task on a job with multiple properties on 1 line separated > by a space, ie.: > name1=value1 name2=value2 > Results at execution time in: > ant ... "-Dname1=value1 name2=value2" > This is not expected, what I would expect from the documentation is: > -Dname1=value1 -Dname2=value2 > etc. > eg. > Properties: offline=1 user.prefs.dir=/home/hudson/config/Bedrock-DEV-config > user.bedrock.properties=bedrock-quicktest.properties > console log: > [Bedrock-DEV-GF-EL-03-quick-test] $ > /home/hudson/tools/apache-ant-1.7.1/bin/ant > -DUPSTREAM_BUILD_TAG=jenkins-Bedrock-DEV-GF-EL-01-compile-2656 > -DP4_CHANGELIST_PARAM=322808 "-Doffline=1 > user.prefs.dir=/home/hudson/config/Bedrock-DEV-config > user.bedrock.properties=bedrock-quicktest.properties" hudson.quicktests > Buildfile: build.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7444) Distributed builds: Scheduling strategy
[ https://issues.jenkins-ci.org/browse/JENKINS-7444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160405#comment-160405 ] Ed Randall commented on JENKINS-7444: - +1 for this. We have 4 slaves, all identical, all the same network distance from the master. Each slave is configured to have 2 executors. We've noticed that Jenkins always seems to favour one slave in particular, to the extent that it will run 2 jobs on it simultaneously even when all the other slaves are idle. This is not ideal so I reduced the executors on that node to 1. Now it does the same behaviour, but preferring a different node. I'd prefer if it took account of the current job situation (or recent average CPU load?) when allocating a new job as well. > Distributed builds: Scheduling strategy > --- > > Key: JENKINS-7444 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7444 > Project: Jenkins > Issue Type: Improvement > Components: master-slave >Affects Versions: current >Reporter: dbubovych >Priority: Minor > Fix For: current > > > It would be nice if Hudson could schedule build to the most free node, rather > then to the node where last build was taken. > For ex. I have projects A, B, C... configured with "roam=true" and nodes > Node1 and Node2 (number of jobs > then number of runners at one node). Last > build for A and B was made on Node1, because all executors were busy. Then, > if I force build for A and B at the same time, they will build together on > Node1, even if Node2 currently do not run any builds. So, build will finish > much faster if A would be scheduled to Node1 and B to Node2, or any other > free Node. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10520) clone-workspace-scm performance is poor
[
https://issues.jenkins-ci.org/browse/JENKINS-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160404#comment-160404
]
Ed Randall edited comment on JENKINS-10520 at 3/19/12 3:40 PM:
---
This is our build pipeline:
1) Compile - checks files out of Perforce, cleans, configures for the target
architecture and compiles. Archives the workspace for susequent steps in the
pipeline.
2) Zip - builds the .ear file, verifies it, builds a complete shippable .zip of
all project deliverables.
3) Quick test - runs a relatively short test suite.
2a) Zip is "promoted" if all tests in QuickTest pass. This delivers the Zip to
the System test team (outside of Jenkins).
Now we didn't want each step to sync the files down from Perforce and compile
afresh, the clone-workspace plugin seemed ideal for us. Unfortunately there are
a number of problems with it including:
a) Only the latest workspace from step(1) is maintained. So if another change
triggers a Compile whilst Zip is in progress, it could be that (3) Quick test
actually tests that subsequent build and not the one it is supposed to be
testing. This has regularly caused us considerable confusion as the jobs were
out-of-step.
b) It takes so long ... our project is somewhat monolithic, including all
binaries required within the workspace. The workspace.zip archive is about
1.5Gb and creating it takes around 50 minutes using clone-workspace-plugin vs.
only 10 minutes for the actual compile, that's unacceptable. Un-zipping at the
start of the steps (2) and (3) is not quite so bad but still 10-20 minutes. It
seems to be something to do with the way data is piped between master and slave.
The solution we now have working is to replace this plugin by a shell script.
This script takes 2 minutes to archive the workspace at the end of job (1) and
2 minutes at to un-archive it at the start of the other steps. It is attached
to this report to illustrate our use case which we would like this plugin to
support.
Use the script as follows:
At the end of job (1) invoke the script using "Execute Shell":
${JENKINS_BIN}/clone-workspace PACK "${BUILD_TAG}"
Optional INCLUDE= and EXCLUDE= filters can be used to limit the contents of the
archive. We actually create 2 archives, one is much smaller containing just
the information required for the "promote" step (2a) to work.
Also add a Post-Build action "Trigger parameterized build on other projects" to
start job (2) using the parameter:
UPSTREAM_BUILD_TAG=${BUILD_TAG}
Jobs (2) and (3) are parameterized, accepting UPSTREAM_BUILD_TAG. The first
task that each of these downstream jobs runs is:
Execute Shell
${JENKINS_BIN}/clone-workspace UNPACK "${UPSTREAM_BUILD_TAG}"
The archive dir must exist on the master node and be referenced by the
JOBS_ARCHIVE environment variable.
The last job in the pipeline removes the redundant archive by invoking:
${JENKINS_BIN}/clone-workspace CLEAN "${UPSTREAM_BUILD_TAG}"
We also purge all archives from it overnight using a "cron" job, just to be
sure.
Now the downstream jobs don't show the change history; that was solved by
re-instating the clone-workspace-plugin but configured to archive just one file.
was (Author: edrandall):
This is our build pipeline:
1) Compile - checks files out of Perforce, cleans, configures for the target
architecture and compiles. Archives the workspace for susequent steps in the
pipeline.
2) Zip - builds the .ear file, verifies it, builds a complete shippable .zip of
all project deliverables.
3) Quick test - runs a relatively short test suite.
2a) Zip is "promoted" if all tests in QuickTest pass. This delivers the Zip to
the System test team (outside of Jenkins).
Now we didn't want each step to sync the files down from Perforce and compile
afresh, the clone-workspace plugin seemed ideal for us. Unfortunately there are
a number of problems with it including:
a) Only the latest workspace from step(1) is maintained. So if another change
triggers a Compile whilst Zip is in progress, it could be that (3) Quick test
actually tests that subsequent build and not the one it is supposed to be
testing. This has regularly caused us considerable confusion as the jobs were
out-of-step.
b) It takes so long ... our project is somewhat monolithic, including all
binaries required within the workspace. The workspace.zip archive is about
1.5Gb and creating it takes around 50 minutes using clone-workspace-plugin vs.
only 10 minutes for the actual compile, that's unacceptable. Un-zipping at the
start of the steps (2) and (3) is not quite so bad but still 10-20 minutes. It
seems to be something to do with the way data is piped between master and slave.
The solution we now have working is to replace this plugin by a shell script.
This script takes 2 minutes to archive the workspace at th
[JIRA] (JENKINS-10520) clone-workspace-scm performance is poor
[
https://issues.jenkins-ci.org/browse/JENKINS-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160404#comment-160404
]
Ed Randall commented on JENKINS-10520:
--
This is our build pipeline:
1) Compile - checks files out of Perforce, cleans, configures for the target
architecture and compiles. Archives the workspace for susequent steps in the
pipeline.
2) Zip - builds the .ear file, verifies it, builds a complete shippable .zip of
all project deliverables.
3) Quick test - runs a relatively short test suite.
2a) Zip is "promoted" if all tests in QuickTest pass. This delivers the Zip to
the System test team (outside of Jenkins).
Now we didn't want each step to sync the files down from Perforce and compile
afresh, the clone-workspace plugin seemed ideal for us. Unfortunately there are
a number of problems with it including:
a) Only the latest workspace from step(1) is maintained. So if another change
triggers a Compile whilst Zip is in progress, it could be that (3) Quick test
actually tests that subsequent build and not the one it is supposed to be
testing. This has regularly caused us considerable confusion as the jobs were
out-of-step.
b) It takes so long ... our project is somewhat monolithic, including all
binaries required within the workspace. The workspace.zip archive is about
1.5Gb and creating it takes around 50 minutes using clone-workspace-plugin vs.
only 10 minutes for the actual compile, that's unacceptable. Un-zipping at the
start of the steps (2) and (3) is not quite so bad but still 10-20 minutes. It
seems to be something to do with the way data is piped between master and slave.
The solution we now have working is to replace this plugin by a shell script.
This script takes 2 minutes to archive the workspace at the end of job (1) and
2 minutes at to un-archive it at the start of the other steps. It is attached
to this reportb for reference, to illustrate our use case which we would like
this plugin to support.
Use the script as follows:
At the end of job (1) invoke the script using "Execute Shell":
${JENKINS_BIN}/clone-workspace PACK "${BUILD_TAG}"
Optional INCLUDE= and EXCLUDE= filters can be used to limit the contents of the
archive. We actually create 2 archives, one is much smaller containing just
the information required for the "promote" step (2a) to work.
Also add a Post-Build action "Trigger parameterized build on other projects" to
start job (2) using the parameter:
UPSTREAM_BUILD_TAG=${BUILD_TAG}
Jobs (2) and (3) are parameterized, accepting UPSTREAM_BUILD_TAG. The first
task that each of these downstream jobs runs is:
Execute Shell
${JENKINS_BIN}/clone-workspace UNPACK "${UPSTREAM_BUILD_TAG}"
The archive dir must exist on the master node and be referenced by the
JOBS_ARCHIVE environment variable.
The last job in the pipeline removes the redundant archive by invoking:
${JENKINS_BIN}/clone-workspace CLEAN "${UPSTREAM_BUILD_TAG}"
We also purge all archives from it overnight using a "cron" job, just to be
sure.
Now the downstream jobs don't show the change history; that was solved by
re-instating the clone-workspace-plugin but configured to archive just one file.
> clone-workspace-scm performance is poor
> ---
>
> Key: JENKINS-10520
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10520
> Project: Jenkins
> Issue Type: Improvement
> Components: clone-workspace
>Affects Versions: current
> Environment: Solaris/x86, cluster of 5 nodes, all machines in cluster
> are identical
>Reporter: Ed Randall
>Assignee: abayer
> Attachments: clone-workspace
>
>
> Clone workspace performance is poor. Whilst compilation takes around 4
> minutes, archiving the workspace afterwards takes the total job time out to
> 35 minutes! Similarly un-archiving it at the start of downstream jobs.
> We have 4 steps, Compile, quick test, package, full test.
> Compile uses Perforce SCM, we use clone workspace after that to ensure
> downstream builds use identical files but other compiles can continue in
> parallel. So we need almost the files in the entire workspace.
> The filesystem workspace size is about 1.6Gb
> The archived workspace.zip file size is about 1.4Gb
> An "exclude" filter may help a little but I think there is something slow
> going on.
> Note that we use slaves as well so the piped data may have an impact, but all
> the machines are very close together.
> When the compile runs on the master node it doesn't seem any quicker.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/s
[JIRA] (JENKINS-10520) clone-workspace-scm performance is poor
[ https://issues.jenkins-ci.org/browse/JENKINS-10520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated JENKINS-10520: - Attachment: clone-workspace > clone-workspace-scm performance is poor > --- > > Key: JENKINS-10520 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10520 > Project: Jenkins > Issue Type: Improvement > Components: clone-workspace >Affects Versions: current > Environment: Solaris/x86, cluster of 5 nodes, all machines in cluster > are identical >Reporter: Ed Randall >Assignee: abayer > Attachments: clone-workspace > > > Clone workspace performance is poor. Whilst compilation takes around 4 > minutes, archiving the workspace afterwards takes the total job time out to > 35 minutes! Similarly un-archiving it at the start of downstream jobs. > We have 4 steps, Compile, quick test, package, full test. > Compile uses Perforce SCM, we use clone workspace after that to ensure > downstream builds use identical files but other compiles can continue in > parallel. So we need almost the files in the entire workspace. > The filesystem workspace size is about 1.6Gb > The archived workspace.zip file size is about 1.4Gb > An "exclude" filter may help a little but I think there is something slow > going on. > Note that we use slaves as well so the piped data may have an impact, but all > the machines are very close together. > When the compile runs on the master node it doesn't seem any quicker. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
[ https://issues.jenkins-ci.org/browse/JENKINS-13044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated JENKINS-13044: - Description: Configuring an Ant task on a job with multiple properties on 1 line separated by a space, ie.: name1=value1 name2=value2 Results at execution time in: ant ... "-Dname1=value1 name2=value2" This is not expected, what I would expect from the documentation is: -Dname1=value1 -Dname2=value2 etc. eg. Properties: offline=1 user.prefs.dir=/home/hudson/config/Bedrock-DEV-config user.bedrock.properties=bedrock-quicktest.properties console log: [Bedrock-DEV-GF-EL-03-quick-test] $ /home/hudson/tools/apache-ant-1.7.1/bin/ant -DUPSTREAM_BUILD_TAG=jenkins-Bedrock-DEV-GF-EL-01-compile-2656 -DP4_CHANGELIST_PARAM=322808 "-Doffline=1 user.prefs.dir=/home/hudson/config/Bedrock-DEV-config user.bedrock.properties=bedrock-quicktest.properties" hudson.quicktests Buildfile: build.xml was: Configuring an Ant task on a job with multiple properties on 1 line separated by a space, ie.: name1=value1 name2=value2 Results at execution time in: ant ... "-Dname1=value1 name2=value2" This is not expected, what is documented is: -D"name1=value1" -D"name2=value2" etc. eg. Properties: offline=1 user.prefs.dir=/home/hudson/config/Bedrock-DEV-config user.bedrock.properties=bedrock-quicktest.properties console log: [Bedrock-DEV-GF-EL-03-quick-test] $ /home/hudson/tools/apache-ant-1.7.1/bin/ant -DUPSTREAM_BUILD_TAG=jenkins-Bedrock-DEV-GF-EL-01-compile-2656 -DP4_CHANGELIST_PARAM=322808 "-Doffline=1 user.prefs.dir=/home/hudson/config/Bedrock-DEV-config user.bedrock.properties=bedrock-quicktest.properties" hudson.quicktests Buildfile: build.xml > Ant multiple properties delimited by spaces parsed as a single property > --- > > Key: JENKINS-13044 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13044 > Project: Jenkins > Issue Type: Bug > Components: ant >Affects Versions: current > Environment: SunOS ldnwebv10 5.10 Generic_120012-14 i86pc i386 i86pc > Solaris > Jenkins STABLE 1.424.3 >Reporter: Ed Randall > > Configuring an Ant task on a job with multiple properties on 1 line separated > by a space, ie.: > name1=value1 name2=value2 > Results at execution time in: > ant ... "-Dname1=value1 name2=value2" > This is not expected, what I would expect from the documentation is: > -Dname1=value1 -Dname2=value2 > etc. > eg. > Properties: offline=1 user.prefs.dir=/home/hudson/config/Bedrock-DEV-config > user.bedrock.properties=bedrock-quicktest.properties > console log: > [Bedrock-DEV-GF-EL-03-quick-test] $ > /home/hudson/tools/apache-ant-1.7.1/bin/ant > -DUPSTREAM_BUILD_TAG=jenkins-Bedrock-DEV-GF-EL-01-compile-2656 > -DP4_CHANGELIST_PARAM=322808 "-Doffline=1 > user.prefs.dir=/home/hudson/config/Bedrock-DEV-config > user.bedrock.properties=bedrock-quicktest.properties" hudson.quicktests > Buildfile: build.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13044) Ant multiple properties delimited by spaces parsed as a single property
Ed Randall created JENKINS-13044: Summary: Ant multiple properties delimited by spaces parsed as a single property Key: JENKINS-13044 URL: https://issues.jenkins-ci.org/browse/JENKINS-13044 Project: Jenkins Issue Type: Bug Components: ant Affects Versions: current Environment: SunOS ldnwebv10 5.10 Generic_120012-14 i86pc i386 i86pc Solaris Jenkins STABLE 1.424.3 Reporter: Ed Randall Configuring an Ant task on a job with multiple properties on 1 line separated by a space, ie.: name1=value1 name2=value2 Results at execution time in: ant ... "-Dname1=value1 name2=value2" This is not expected, what is documented is: -D"name1=value1" -D"name2=value2" etc. eg. Properties: offline=1 user.prefs.dir=/home/hudson/config/Bedrock-DEV-config user.bedrock.properties=bedrock-quicktest.properties console log: [Bedrock-DEV-GF-EL-03-quick-test] $ /home/hudson/tools/apache-ant-1.7.1/bin/ant -DUPSTREAM_BUILD_TAG=jenkins-Bedrock-DEV-GF-EL-01-compile-2656 -DP4_CHANGELIST_PARAM=322808 "-Doffline=1 user.prefs.dir=/home/hudson/config/Bedrock-DEV-config user.bedrock.properties=bedrock-quicktest.properties" hudson.quicktests Buildfile: build.xml -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12835) NullPointerException in CloneWorkspacePublisher.java:211 after upgrading to 0.4
Ed Randall created JENKINS-12835: Summary: NullPointerException in CloneWorkspacePublisher.java:211 after upgrading to 0.4 Key: JENKINS-12835 URL: https://issues.jenkins-ci.org/browse/JENKINS-12835 Project: Jenkins Issue Type: Bug Components: clone-workspace-scm Affects Versions: current Environment: Jenkins 1.424.2 Jenkins Clone Workspace SCM Plug-in 0.4 Reporter: Ed Randall After upgrading clone-workspace-plugin from 0.3 to 0.4 this happens at the end of the job when it is supposed to start archiving:- BUILD SUCCESSFUL Total time: 5 minutes 1 second Archiving workspace ERROR: Publisher hudson.plugins.cloneworkspace.CloneWorkspacePublisher aborted due to exception java.lang.NullPointerException at hudson.plugins.cloneworkspace.CloneWorkspacePublisher.snapshot(CloneWorkspacePublisher.java:211) at hudson.plugins.cloneworkspace.CloneWorkspacePublisher.perform(CloneWorkspacePublisher.java:170) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:682) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:657) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:635) at hudson.model.Build$RunnerImpl.post2(Build.java:161) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:604) at hudson.model.Run.run(Run.java:1400) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:175) Email was triggered for: Failure -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12804) Promote "When the following upstream promotions are promoted" does not happen
Ed Randall created JENKINS-12804: Summary: Promote "When the following upstream promotions are promoted" does not happen Key: JENKINS-12804 URL: https://issues.jenkins-ci.org/browse/JENKINS-12804 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: Jenkins 1.424.2 Promoted-builds-plugin 2.4 parameterized trigger plugin 2.12 Reporter: Ed Randall I have a "quicktest" job set to: "Promote immediately once the build is complete" and nothing else. This should happen automatically when the tests complete and they all pass, ie when "stable". This works; the promotion is named "Bedrock-DEV-GF-EL-quicktest promoted" The "quicktest" job triggers (via parameterized trigger plugin) a downstream job "zipfile" which packages the project for release to QA, if "quicktest" is stable. The zipfile job is set promote: "Promote immediately once the build is complete" && "When the following upstream promotions are promoted" promotion names: "Bedrock-DEV-GF-EL-quicktest promoted" I'd expect this zipfile job to get promoted, but it doesn't happen; The Promotion status screen says: Bedrock-DEV-GF-EL-zipfile promoted This promotion has not happened. Met Qualification Automatically promoted immediately after the build Unmet Qualification Upstream promotions Bedrock-DEV-GF-EL-quicktest promoted -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12799) When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data
[ https://issues.jenkins-ci.org/browse/JENKINS-12799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ed Randall updated JENKINS-12799: - Attachment: jenkins-job-promotion-config.png > When project configuration is changed, Promoted Builds Plugin continues to > use "old" configuration data > --- > > Key: JENKINS-12799 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12799 > Project: Jenkins > Issue Type: Bug > Components: promoted-builds >Affects Versions: current > Environment: Jenkins 1.424.2 > Promoted Builds 2.4 >Reporter: Ed Randall >Priority: Minor > Attachments: jenkins-build-history.png, > jenkins-job-promotion-config.png, jenkins-promotion-history.png > > > I've been experimenting with different configurations for promoting builds, > now when the promotion happens I'm getting no less than 3 stars applied > alongside the build name. > Two of them should not be there for two reasons > (1) because they are based on configuration information that is no longer > part of the job configuration, it should have been overwritten; > (2) They actually fail according to their own status! > Please see attached screenshots. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12799) When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data
Ed Randall created JENKINS-12799: Summary: When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data Key: JENKINS-12799 URL: https://issues.jenkins-ci.org/browse/JENKINS-12799 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: Jenkins 1.424.2 Promoted Builds 2.4 Reporter: Ed Randall Priority: Minor Attachments: jenkins-build-history.png, jenkins-promotion-history.png I've been experimenting with different configurations for promoting builds, now when the promotion happens I'm getting no less than 3 stars applied alongside the build name. Two of them should not be there for two reasons (1) because they are based on configuration information that is no longer part of the job configuration, it should have been overwritten; (2) They actually fail according to their own status! Please see attached screenshots. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
