[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title Christoph Amshoff closed an issue as Fixed Setting system property hudson.slaves.WorkspaceList should do the trick, see https://wiki.jenkins.io/display/JENKINS/Features+controlled+by+system+properties Jenkins / JENKINS-50907 customWorkspace setting of agent directive does not support EXECUTOR_NUMBER Change By: Christoph Amshoff Status: Open Closed Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and
[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title Christoph Amshoff commented on JENKINS-50907 Re: customWorkspace setting of agent directive does not support EXECUTOR_NUMBER Georgi, thanks for your input! According to mentioned web page, this property is already available since version 1.424. I wish we had gotten this information ealier, would have saved us quite some time... Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.190037.1524217689000.1043.1579263842381%40Atlassian.JIRA.
[JIRA] (JENKINS-58402) On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Title: Message Title Christoph Amshoff updated JENKINS-58402 Dependency-Check version 5.2.0 works fine, consider issue fixed. Jenkins / JENKINS-58402 On Windows slaves, any call of dependency check tool results in "The input line is too long" error Change By: Christoph Amshoff Status: Open Fixed but Unreleased Resolution: Fixed Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200527.1562668975000.19767.1563913440582%40Atlassian.JIRA.
[JIRA] (JENKINS-58402) On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Title: Message Title Christoph Amshoff commented on JENKINS-58402 Re: On Windows slaves, any call of dependency check tool results in "The input line is too long" error @Kelly, thanks for your discovery. I can confirm it's indeed the CLASSPATH setting. We were able to locally work around this issue (unpack all JARs in single folder) until it's resolved. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.200527.1562668975000.16379.1563537780727%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58523) Multiple invocations of dependencyCheckPublisher in one build don't show correct results
Title: Message Title Christoph Amshoff commented on JENKINS-58523 Re: Multiple invocations of dependencyCheckPublisher in one build don't show correct results There is another bad consequence of the issue: when risk gates are given, the DependencyCheckPublisher compares the current values of the second invocation with the values from first invocation of the previous build, which will constantly produce red/yellow build if the number of violations in first invocation is lower than in second... 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.200669.1563309781000.16321.1563530760100%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58523) Multiple invocations of dependencyCheckPublisher in one build don't show correct results
Title: Message Title Christoph Amshoff created an issue Jenkins / JENKINS-58523 Multiple invocations of dependencyCheckPublisher in one build don't show correct results Issue Type: Bug Assignee: Unassigned Components: dependency-check-jenkins-plugin Created: 2019-07-16 20:43 Priority: Major Reporter: Christoph Amshoff We have a build pipeline that executes dependency-check-maven for two independant modules (services and ui), and both reports should be published as part of the build. When dependencyCheckPublisher is invoked twice in the pipeline, two actions are added to the build and the UI shows two (identical) "Dependency-Check" links in the sidebar. However, both are showing the same page, apparently those of the second invocation; the information for the first publisher call is not accessible. Behavior is the same, whether there are two calls of dependencyCheckPublisher step in the pipeline, or a single call with a pattern string that does match both report files. Add Comment
[JIRA] (JENKINS-58402) On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Title: Message Title
Christoph Amshoff edited a comment on JENKINS-58402
Re: On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Steve, thanks for the tips.First of all, going back to dependency-check-5.0.0 did not help.After configuring a logger for hudson.Proc I saw that the syntax of the call is most probably wrong, caused by using the fully qualified job name and build number as default for --project parameter: {noformat}Running: c:\builds\jenkins-slave\tools\org.jenkinsci.plugins.DependencyCheck.tools.DependencyCheckInstallation\dependency-check-5.0.0\bin\dependency-check.bat --project Experimental » ams-testDepCheck #9 --scan c:\builds\jenkins-slave\workspace\lfjee\Experimental\ams-testDepCheck --format XML --updateonly --data c:/builds/dependency-check-data --proxyserver x --proxyport 8080{noformat} When instead passing in some value for project, I get this command line {noformat}Running: c:\builds\jenkins-slave\tools\org.jenkinsci.plugins.DependencyCheck.tools.DependencyCheckInstallation\dependency-check-5.0.0\bin\dependency-check.bat --scan c:\builds\jenkins-slave\workspace\lfjee\Experimental\ams-testDepCheck --format XML --project updateDepData --updateonly --data c:/builds/dependency-check-data --proxyserver x --proxyport 8080{noformat} Which seems correct and indeed does work when copy & pasted into local installation of dependency-check command line tool.{noformat}c:\Utils\dependency-check\bin>dependency-check.bat --scan c:\lfjee\ams-testDepCheck --format XML --project updateDepData --updateonly --data c:/builds/dependency-check-data --proxyserver x --proxyport 8080[INFO] Checking for updates[INFO] NVD CVE requires several updates; this could take a couple of minutes.[INFO] Download Started for NVD CVE - 2002[INFO] Download Started for NVD CVE - 2003[INFO] Download Complete for NVD CVE - 2003 (1779 ms)[INFO] Download Started for NVD CVE - 2004[INFO] Processing Started for NVD CVE - 2003...{noformat}However, in Jenkins I still get{noformat}Building remotely on mu-s-iplint5 (lf-win) in workspace c:\builds\jenkins-slave\workspace\lfjee\Experimental\ams-testDepCheck[DependencyCheck] The input line is too long.[DependencyCheck] The syntax of the command is incorrect.Build step 'Invoke Dependency-Check' changed build result to FAILURE{noformat}There is no other info in the hudson.Proc log. When logging just hudson package, there are tons of messages, though; I think they are unrelated, but I'll attach the log anyway.
Add Comment
[JIRA] (JENKINS-58402) On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Title: Message Title Christoph Amshoff updated an issue Jenkins / JENKINS-58402 On Windows slaves, any call of dependency check tool results in "The input line is too long" error Change By: Christoph Amshoff Attachment: hudson.log 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.200527.1562668975000.7937.1562851320695%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58402) On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Title: Message Title Christoph Amshoff commented on JENKINS-58402 Re: On Windows slaves, any call of dependency check tool results in "The input line is too long" error Steve, thanks for the tips. First of all, going back to dependency-check-5.0.0 did not help. After configuring a logger for hudson.Proc I saw that the syntax of the call is most probably wrong, caused by using the fully qualified job name and build number as default for --project parameter: Running: c:\builds\jenkins-slave\tools\org.jenkinsci.plugins.DependencyCheck.tools.DependencyCheckInstallation\dependency-check-5.0.0\bin\dependency-check.bat --project Experimental » ams-testDepCheck #9 --scan c:\builds\jenkins-slave\workspace\lfjee\Experimental\ams-testDepCheck --format XML --updateonly --data c:/builds/dependency-check-data --proxyserver x --proxyport 8080 When instead passing in some value for project, I get this command line Running: c:\builds\jenkins-slave\tools\org.jenkinsci.plugins.DependencyCheck.tools.DependencyCheckInstallation\dependency-check-5.0.0\bin\dependency-check.bat --scan c:\builds\jenkins-slave\workspace\lfjee\Experimental\ams-testDepCheck --format XML --project updateDepData --updateonly --data c:/builds/dependency-check-data --proxyserver x --proxyport 8080 Which seems correct and indeed does work when copy & pasted into local installation of dependency-check command line tool. c:\Utils\dependency-check\bin>dependency-check.bat --scan c:\lfjee\ams-testDepCheck --format XML --project updateDepData --updateonly --data c:/builds/dependency-check-data --proxyserver x --proxyport 8080 [INFO] Checking for updates [INFO] NVD CVE requires several updates; this could take a couple of minutes. [INFO] Download Started for NVD CVE - 2002 [INFO] Download Started for NVD CVE - 2003 [INFO] Download Complete for NVD CVE - 2003 (1779 ms) [INFO] Download Started for NVD CVE - 2004 [INFO] Processing Started for NVD CVE - 2003 ... However, in Jenkins I still get Building remotely on mu-s-iplint5 (lf-win) in workspace c:\builds\jenkins-slave\workspace\lfjee\Experimental\ams-testDepCheck [DependencyCheck] The input line is too long. [DependencyCheck] The syntax of the command is incorrect. Build step 'Invoke Dependency-Check' changed build result to FAILURE There is no other info in the hudson.Proc log. When logging just hudson package, there are tons of messages, though; I think they are unrelated, but I'll attach the log anyway.
[JIRA] (JENKINS-58402) On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-58402
On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Change By:
Christoph Amshoff
We defined Jenkins Global Tool for dependency-check-5.1.0 with auto install. When executing a job on a Windows slave, the tool gets installed (in folder c:\jenkins-slave\tools\org.jenkinsci.plugins.DependencyCheck.tools.DependencyCheckInstallation\dependency-check-5.1.0), but any call of Dependency Check results in errors:{{[DependencyCheck] The input line is too long.}} {{[DependencyCheck] The syntax of the command is incorrect.}}This is the case even for simple calls like{{dependencycheck additionalArguments: '--updateonly --data c: \\ / builds \\ / }}{{dependency-check-data2', odcInstallation: 'dependency-check-5.1.0'}}Is there any way to see the command line that is built? And more importantly, to get rid of the errors?
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
[JIRA] (JENKINS-58402) On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-58402
On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Change By:
Christoph Amshoff
We defined Jenkins Global Tool for dependency-check-5.1.0 with auto install. When executing a job on a Windows slave, the tool gets installed (in folder c:\jenkins-slave\tools\org.jenkinsci.plugins.DependencyCheck.tools.DependencyCheckInstallation\dependency-check-5.1.0), but any call of Dependency Check results in errors:{{[DependencyCheck] The input line is too long.}}{{[DependencyCheck] The syntax of the command is incorrect.}}This is the case even for simple calls like{{dependencycheck additionalArguments: '--updateonly --data c:\\builds\\ }}{{ dependency-check-data2', odcInstallation: 'dependency-check-5.1.0'}}Is there any way to see the command line that is built? And more importantly, to get rid of the errors?
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
[JIRA] (JENKINS-58402) On Windows slaves, any call of dependency check tool results in "The input line is too long" error
Title: Message Title Christoph Amshoff created an issue Jenkins / JENKINS-58402 On Windows slaves, any call of dependency check tool results in "The input line is too long" error Issue Type: Bug Assignee: Unassigned Components: dependency-check-jenkins-plugin Created: 2019-07-09 10:42 Environment: dependency-check 5.0, Windows Priority: Critical Reporter: Christoph Amshoff We defined Jenkins Global Tool for dependency-check-5.1.0 with auto install. When executing a job on a Windows slave, the tool gets installed (in folder c:\jenkins-slave\tools\org.jenkinsci.plugins.DependencyCheck.tools.DependencyCheckInstallation\dependency-check-5.1.0), but any call of Dependency Check results in errors: [DependencyCheck] The input line is too long. [DependencyCheck] The syntax of the command is incorrect. This is the case even for simple calls like dependencycheck additionalArguments: '--updateonly --data c:\\buildsdependency-check-data2', odcInstallation: 'dependency-check-5.1.0' Is there any way to see the command line that is built? And more importantly, to get rid of the errors?
[JIRA] (JENKINS-56402) Declarative Pipeline shows SUCCESS even though job FAILED
Title: Message Title Christoph Amshoff commented on JENKINS-56402 Re: Declarative Pipeline shows SUCCESS even though job FAILED I've installed 1.3.7-beta-1 version of all four pipeline plugins (Pipeline: Declarative, Pipeline: Declarative Extension Points API, Pipeline: Model API and Pipeline: Stage Tags Metadata) and can confirm that it works! Status in post action is correcct now, mails are sent with proper status and Claims plugin's icon shows up again for unstable or failed builds. So, thanks for the fix! I really appreciate your efforts, and can imagine it's hard to fix this messy status implementation without breaking any functionality... 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-56402) Declarative Pipeline shows SUCCESS even though job FAILED
Title: Message Title Christoph Amshoff commented on JENKINS-56402 Re: Declarative Pipeline shows SUCCESS even though job FAILED Michel Zanini, for email-ext there is a Pipeline compatible step available, see https://jenkins.io/doc/pipeline/steps/email-ext/ and https://jenkins.io/blog/2017/02/15/declarative-notifications/ 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-56402) Declarative Pipeline shows SUCCESS even though job FAILED
Title: Message Title
Christoph Amshoff commented on JENKINS-56402
Re: Declarative Pipeline shows SUCCESS even though job FAILED
We run into this issue after last update of Jenkins core and plugins. It's highly critical because it results in wrong mails/notifications and changed behavior. Using currentBuild.result was a documented, working way of accessing the build result, also for declarative pipelines. It's not an option to change hundreds of pipelines in various branches and move code from always block to different post condition blocks. This would just duplicate a lot of code, like the call of emailext step. Moveover, the issue makes some plugins like claim-plugin unusable. This is called by step([$class: 'ClaimPublisher']) in the post section, and internally evaluates the build's status in order to decide whether to show claim functionality (build result is failure or unstalbe) or not; see ClaimPublisher.java:
@Override
public void perform(@Nonnull Run build, @Nonnull FilePath workspace, @Nonnull Launcher launcher,
@Nonnull TaskListener listener) throws InterruptedException, IOException {
Result runResult = build.getResult();
if (runResult != null && runResult.isWorseThan(Result.SUCCESS)) {
...
}
}
Since the result is always SUCCESS now, claim UI elements are never shown. Same applies to some custom plugins developed here. Thus, please restore the previous functionality ASAP! After that, you might think about better ways to fix the edge cases or provide new variables...
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
[JIRA] (JENKINS-56430) In latest version of pipeline plugins, currentBuild.result is not correctly set any more for unstable/failure/aborted builds
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-56430
In latest version of pipeline plugins, currentBuild.result is not correctly set any more for unstable/failure/aborted builds
Change By:
Christoph Amshoff
After upgrading to Jenkins 2.150.3 and all Pipeline plugins to their latest version, we have severe problems with internal handling of build result. Even when there are build failures, timeouts etc. the value of currentBuild.result is still null, causing issues like sending "success" mails, ClaimPublisher not being triggered etc.The status is displayed correctly in Stage View and Blue Ocean, though.Attached minimal Jenkinsfile (producing failed build) results in this output:{quote}[Pipeline] Start of Pipeline (hide) [Pipeline] node Running on x in /home/lf4linux/y [Pipeline] { [Pipeline] stage [Pipeline] Unknown macro: \{ (Build) [Pipeline] echo build started... stage [Pipeline] sleep Sleeping for 2 sec [Pipeline] sh + cp with-wrong-syntax cp Unknown macro }[Pipeline] // stage [Pipeline] stage [Pipeline]Unknown macro: \ { (Test) Stage "Test" skipped due to earlier failure(s) [Pipeline] }[Pipeline] // stage [Pipeline] stage [Pipeline] { (Declarative: Post Actions) [Pipeline] echo {color:#ff}result = null{color} [Pipeline] echo {color:#ff}currentResult = SUCCESS{color} [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline {color:#ff}ERROR: script returned exit code 1{color} {color:#ff} Finished: FAILURE{color}{quote}Even when using the error step, the result property is still not set (meaning SUCCESS):{quote}[Pipeline] { (Declarative: Post Actions) [Pipeline] echo {color:#ff}result = null{color} [Pipeline] echo {color:#ff}currentResult = SUCCESS{color} [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline {color:#ff}ERROR: some error here!!!{color} {color:#ff} Finished: FAILURE{color}{quote}I haven't read about changed behavior in this area, so I assume this is a bug somewhere in the pipeline plugins...Any help is greatly appreciated. I'd be willing to rollback the upgrade we did last week, if I just knew which of the 95 plugins we upgraded is causing this. Let Jenkins: 2.150.3; Pipeline Plugins: 1.3.5 (let me know if you need more info on to know other plugin version etc. versions)
[JIRA] (JENKINS-56430) In latest version of pipeline plugins, currentBuild.result is not correctly set any more for unstable/failure/aborted builds
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-56430
In latest version of pipeline plugins, currentBuild.result is not correctly set any more for unstable/failure/aborted builds
Change By:
Christoph Amshoff
After upgrading to Jenkins 2.150.3 and all Pipeline plugins to their latest version, we have severe problems with internal handling of build result. Even when there are build failures, timeouts etc. the value of currentBuild.result is still null, causing issues like sending "success" mails, ClaimPublisher not being triggered etc.The status is displayed correctly in Stage View and Blue Ocean, though.Attached minimal Jenkinsfile (producing failed build) results in this output:{quote}[Pipeline] Start of Pipeline (hide) [Pipeline] node Running on x in /home/lf4linux/y [Pipeline] { [Pipeline] stage [Pipeline] Unknown macro: \ { (Build) [Pipeline] echo build started... [Pipeline] sleep Sleeping for 2 sec [Pipeline] sh + cp with-wrong-syntax cp : missing destination file operand after 'with-wrong-syntax' Try 'cp --help' for more information. [Pipeline] } [Pipeline] // stage [Pipeline] stage [Pipeline] Unknown macro: \ { (Test) Stage "Test" skipped due to earlier failure(s) [Pipeline] } [Pipeline] // stage [Pipeline] stage [Pipeline] { (Declarative: Post Actions) [Pipeline] echo {color:# FF ff }result = null{color} [Pipeline] echo {color:# FF ff }currentResult = SUCCESS{color} [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline {color:# FF ff }ERROR: script returned exit code 1{color}{color:# FF ff } Finished: FAILURE{color}{quote}Even when using the error step, the result property is still not set (meaning SUCCESS):{quote}[Pipeline] { (Declarative: Post Actions) [Pipeline] echo {color:# FF ff }result = null{color} [Pipeline] echo {color:# FF ff }currentResult = SUCCESS{color} [Pipeline] } [Pipeline] // stage [Pipeline] } [Pipeline] // node [Pipeline] End of Pipeline {color:# FF ff }ERROR: some error here!!!{color}{color:# FF ff } Finished: FAILURE{color}{quote}I haven't read about changed behavior in this area, so I assume this is a bug somewhere in the pipeline plugins...Any help is greatly appreciated. I'd be willing to rollback the upgrade we did last week, if I just knew which of the 95 plugins we upgraded is causing this. Let me know if you need more info on plugin version etc.
[JIRA] (JENKINS-56430) In latest version of pipeline plugins, currentBuild.result is not correctly set any more for unstable/failure/aborted builds
Title: Message Title Christoph Amshoff updated an issue Jenkins / JENKINS-56430 In latest version of pipeline plugins, currentBuild.result is not correctly set any more for unstable/failure/aborted builds Change By: Christoph Amshoff Summary: In latest version of pipeline plugins , currentBuild.result is not set correctly set any more for unstable/failure /aborted builds 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-56430) In pipeline, currentBuild.result is not set correctly for unstable/failure
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-56430
In pipeline, currentBuild.result is not set correctly for unstable/failure
Change By:
Christoph Amshoff
After upgrading to Jenkins 2.150.3 and all Pipeline plugins to their latest version, we have severe problems with internal handling of build result. Even when there are build failures, timeouts etc. the value of currentBuild.result is still null, causing issues like sending "success" mails, ClaimPublisher not being triggered etc.The status is displayed correctly in Stage View and Blue Ocean, though.Attached minimal Jenkinsfile (producing failed build) results in this output:{quote} [Pipeline] Start of Pipeline (hide)[Pipeline] nodeRunning on x in /home/lf4linux/y[Pipeline] \ {[Pipeline] stage[Pipeline] \ { (Build)[Pipeline] echobuild started...[Pipeline] sleepSleeping for 2 sec[Pipeline] sh+ cp with-wrong-syntaxcp: missing destination file operand after 'with-wrong-syntax'Try 'cp --help' for more information.[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] \ { (Test)Stage "Test" skipped due to earlier failure(s)[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] \ { (Declarative: Post Actions)[Pipeline] echo {color:#FF} result = null {color} [Pipeline] echo {color:#FF} currentResult = SUCCESS {color} [Pipeline] }[Pipeline] // stage[Pipeline] }[Pipeline] // node[Pipeline] End of Pipeline {color:#FF} ERROR: script returned exit code 1 {color} {color:#FF} Finished: FAILURE {color} {quote} Even when using the error step, the result property is still not set (meaning SUCCESS):{quote} [Pipeline] \ { (Declarative: Post Actions)[Pipeline] echo {color:#FF} result = null {color} [Pipeline] echo {color:#FF} currentResult = SUCCESS {color} [Pipeline] }[Pipeline] // stage[Pipeline] }[Pipeline] // node[Pipeline] End of Pipeline {color:#FF} ERROR: some error here!!! {color} {color:#FF} Finished: FAILURE {color} {quote}I haven't read about changed behavior in this area, so I assume this is a bug somewhere in the pipeline plugins...Any help is greatly appreciated. Let me know if you need more info on plugin version etc.
Add Comment
[JIRA] (JENKINS-56430) In pipeline, currentBuild.result is not set correctly for unstable/failure
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-56430
In pipeline, currentBuild.result is not set correctly for unstable/failure
Change By:
Christoph Amshoff
After upgrading to Jenkins 2.150.3 and all Pipeline plugins to their latest version, we have severe problems with internal handling of build result. Even when there are build failures, timeouts etc. the value of currentBuild.result is still null, causing issues like sending "success" mails, ClaimPublisher not being triggered etc.The status is displayed correctly in Stage View and Blue Ocean, though.Attached minimal Jenkinsfile (producing failed build) results in this output:{quote} {{ [Pipeline] Start of Pipeline }} (hide) {{ [Pipeline] node }} {{ Running on mu-s-linsrv33 x in /home/lf4linux/ builds/jenkins-slave/workspace/lfjee/Experimental/test}} y {{ [Pipeline] \ { }} {{ [Pipeline] stage }} {{ [Pipeline] \ { (Build) }} {{ [Pipeline] echo }} {{ build started... }} {{ [Pipeline] sleep }} {{ Sleeping for 2 sec }} {{ [Pipeline] sh }} {{ + cp with-wrong-syntax }} {{ cp: missing destination file operand after 'with-wrong-syntax' }} {{ Try 'cp --help' for more information. }} {{ [Pipeline] } }} {{ [Pipeline] // stage }} {{ [Pipeline] stage }} {{ [Pipeline] \ { (Test) }} {{ Stage "Test" skipped due to earlier failure(s) }} {{ [Pipeline] } }} {{ [Pipeline] // stage }} {{ [Pipeline] stage }} {{ [Pipeline] \ { (Declarative: Post Actions) }} {{ [Pipeline] echo }} {{ result = null }} {{ [Pipeline] echo }} {{ currentResult = SUCCESS }} {{ [Pipeline] } }} {{ [Pipeline] // stage }} {{ [Pipeline] } }} {{ [Pipeline] // node }} {{ [Pipeline] End of Pipeline }} {{ ERROR: script returned exit code 1 }} {{ Finished: FAILURE }} {quote} Even when using the error step, the result property is still not set (meaning SUCCESS):{quote} {{}}{{ [Pipeline] \ { (Declarative: Post Actions) }} {{ [Pipeline] echo }} {{ result = null }} {{ [Pipeline] echo }} {{ currentResult = SUCCESS }} {{ [Pipeline] } }} {{ [Pipeline] // stage }} {{ [Pipeline] } }} {{ [Pipeline] // node }} {{ [Pipeline] End of Pipeline }} {{ ERROR: some error here!!! }} {{ Finished: FAILURE }} {quote}I haven't read about changed behavior in this area, so I assume this is a bug somewhere in the pipeline plugins...Any help is greatly appreciated. Let me know if you need more info on plugin version etc.
[JIRA] (JENKINS-56430) In pipeline, currentBuild.result is not set correctly for unstable/failure
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-56430
In pipeline, currentBuild.result is not set correctly for unstable/failure
Change By:
Christoph Amshoff
After upgrading to Jenkins 2.150.3 and all Pipeline plugins to their latest version, we have severe problems with internal handling of build result. Even when there are build failures, timeouts etc. the value of currentBuild.result is still null, causing issues like sending "success" mails, ClaimPublisher not being triggered etc.The status is displayed correctly in Stage View and Blue Ocean, though.Attached minimal Jenkinsfile (producing failed build) results in this output:{quote}{{[Pipeline] Start of Pipeline}}{{[Pipeline] node}}{{Running on mu-s-linsrv33 in /home/lf4linux/builds/jenkins-slave/workspace/lfjee/Experimental/test}}{{[Pipeline] {}}{{[Pipeline] stage}}{{[Pipeline] { (Build)}}{{[Pipeline] echo}}{{build started...}}{{[Pipeline] sleep}}{{Sleeping for 2 sec}}{{[Pipeline] sh}}{{+ cp with-wrong-syntax}}{{cp: missing destination file operand after 'with-wrong-syntax'}}{{Try 'cp --help' for more information.}}{{[Pipeline] }}}{{[Pipeline] // stage}}{{[Pipeline] stage}}{{[Pipeline] { (Test)}}{{Stage "Test" skipped due to earlier failure(s)}}{{[Pipeline] }}}{{[Pipeline] // stage}}{{[Pipeline] stage}}{{[Pipeline] { (Declarative: Post Actions)}}{{[Pipeline] echo}}{{result = null}}{{[Pipeline] echo}}{{currentResult = SUCCESS}}{{[Pipeline] }}}{{[Pipeline] // stage}}{{[Pipeline] }}}{{[Pipeline] // node}}{{[Pipeline] End of Pipeline}}{{ERROR: script returned exit code 1}}{{Finished: FAILURE}} {quote}Even when using the error step, the result property is still not set (meaning SUCCESS):{quote}{{ }}{{ [Pipeline] { (Declarative: Post Actions)}}{{[Pipeline] echo}}{{result = null}}{{[Pipeline] echo}}{{currentResult = SUCCESS}}{{[Pipeline] }}}{{[Pipeline] // stage}}{{[Pipeline] }}}{{[Pipeline] // node}}{{[Pipeline] End of Pipeline}}{{ERROR: some error here!!!}}{{Finished: FAILURE}}{quote}I haven't read about changed behavior in this area, so I assume this is a bug somewhere in the pipeline plugins...Any help is greatly appreciated. Let me know if you need more info on plugin version etc.
Add Comment
[JIRA] (JENKINS-56430) In pipeline, currentBuild.result is not set correctly for unstable/failure
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-56430
In pipeline, currentBuild.result is not set correctly for unstable/failure
Change By:
Christoph Amshoff
After upgrading to Jenkins 2.150.3 and all Pipeline plugins to their latest version, we have severe problems with internal handling of build result. Even when there are build failures, timeouts etc. the value of currentBuild.result is still null, causing issues like sending "success" mails, ClaimPublisher not being triggered etc.The status is displayed correctly in Stage View and Blue Ocean, though.Attached minimal Jenkinsfile (producing failed build) results in this output:{ color:#9a quote } {{ [Pipeline] Start of Pipeline {color } {color:#9a } {{ [Pipeline] node {color } }{{ Running on [|http://jenkins:8080/computer/ mu-s-linsrv33 /] in /home/lf4linux/ {color:#9a builds/jenkins-slave/workspace/lfjee/Experimental/test } }{{ [Pipeline] { {color } {color:#9a } {{ [Pipeline] stage {color } {color:#9a } {{ [Pipeline] { (Build) {color } {color:#9a } {{ [Pipeline] echo {color } }{{ build started... {color:#9a } }{{ [Pipeline] sleep {color } }{{ Sleeping for 2 sec {color:#9a } }{{ [Pipeline] sh {color } }{{ + cp with-wrong-syntax }} {{ cp: missing destination file operand after 'with-wrong-syntax' }} {{ Try 'cp --help' for more information. {color:#9a } }{{ [Pipeline] } {color } {color:#9a } {{ [Pipeline] // stage {color } {color:#9a } {{ [Pipeline] stage {color } {color:#9a } {{ [Pipeline] { (Test) {color } }{{ Stage "Test" skipped due to earlier failure(s) {color:#9a } }{{ [Pipeline] } {color } {color:#9a } {{ [Pipeline] // stage {color } {color:#9a } {{ [Pipeline] stage {color } {color:#9a } {{ [Pipeline] { (Declarative: Post Actions) {color } {color:#9a } {{ [Pipeline] echo {color } }{{ result = null {color:#9a } }{{ [Pipeline] echo {color } }{{ currentResult = SUCCESS {color:#9a } }{{ [Pipeline] } {color } {color:#9a } {{ [Pipeline] // stage {color } {color:#9a } {{ [Pipeline] } {color } {color:#9a } {{ [Pipeline] // node {color } {color:#9a } {{ [Pipeline] End of Pipeline }} {{ ERROR: script returned exit code 1 }}{{ Finished: FAILURE }} { color quote }Even when using the error step, the result property is still not set (meaning SUCCESS):{ color:#9a quote } {{ [Pipeline] { (Declarative: Post Actions) {color } {color:#9a } {{ [Pipeline] echo {color } }{{ result = null {color:#9a } }{{ [Pipeline] echo {color } }{{ currentResult = SUCCESS {color:#9a } }{{ [Pipeline] } {color } {color:#9a } {{ [Pipeline] // stage {color } {color:#9a } {{ [Pipeline] } {color } {color:#9a } {{ [Pipeline] // node {color } {color:#9a } {{ [Pipeline] End of Pipeline {color } }{{ ERROR: some error here!!! }} {{ Finished: FAILURE }} {quote} I haven't read about changed behavior in this area, so I assume this is a bug somewhere in the pipeline plugins...Any help is greatly appreciated. Let me know if
[JIRA] (JENKINS-56430) In pipeline, currentBuild.result is not set correctly for unstable/failure
Title: Message Title
Christoph Amshoff created an issue
Jenkins / JENKINS-56430
In pipeline, currentBuild.result is not set correctly for unstable/failure
Issue Type:
Bug
Assignee:
Unassigned
Attachments:
Jenkinsfile-wrong-result
Components:
pipeline
Created:
2019-03-06 09:15
Labels:
pipeline
Priority:
Blocker
Reporter:
Christoph Amshoff
After upgrading to Jenkins 2.150.3 and all Pipeline plugins to their latest version, we have severe problems with internal handling of build result. Even when there are build failures, timeouts etc. the value of currentBuild.result is still null, causing issues like sending "success" mails, ClaimPublisher not being triggered etc. The status is displayed correctly in Stage View and Blue Ocean, though. Attached minimal Jenkinsfile (producing failed build) results in this output: [Pipeline] Start of Pipeline[Pipeline] nodeRunning on in /home/lf4linux/[Pipeline] {[Pipeline] stage[Pipeline] { (Build)[Pipeline] echobuild started...[Pipeline] sleepSleeping for 2 sec[Pipeline] sh+ cp with-wrong-syntax cp: missing destination file operand after 'with-wrong-syntax' Try 'cp --help' for more information.[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] { (Test)Stage "Test" skipped due to earlier failure(s)[Pipeline] }[Pipeline] // stage[Pipeline] stage[Pipeline] { (Declarative: Post Actions)[Pipeline] echoresult = null[Pipeline] echocurrentResult = SUCCESS[Pipeline] }[Pipeline] // stage[Pipeline] }[Pipeline] // node[Pipeline] End of Pipeline ERROR: script returned exit code 1 Finished: FAILURE Even when using the error
[JIRA] (JENKINS-56413) Option failFast in declarative pipeline does not support variables
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-56413
Option failFast in declarative pipeline does not support variables
Change By:
Christoph Amshoff
In a declarative pipeline, we have some parallel steps. On start of a build, the user should be able to decide whether the steps should fail fast or not.Thus, we introduced a boolean parameter "FAIL_FAST" and used it in the step like this:{{stage('Smoke Test') {}}{{ failFast params.FAIL_FAST}}{{ parallel {}}{{ ...}} {{ }}} However, that led to following exception:{{org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:}}{{WorkflowScript: 196: Expected a boolean with failFast @ line 196, column 7.}}{{ failFast params.FAIL_FAST}}{{ ^}}It should be possible to use variables at this point.
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-56413) Option failFast in declarative pipeline does not support variables
Title: Message Title
Christoph Amshoff created an issue
Jenkins / JENKINS-56413
Option failFast in declarative pipeline does not support variables
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2019-03-05 11:24
Labels:
pipeline
Priority:
Major
Reporter:
Christoph Amshoff
In a declarative pipeline, we have some parallel steps. On start of a build, the user should be able to decide whether the steps should fail fast or not. Thus, we introduced a boolean parameter "FAIL_FAST" and used it in the step like this: stage('Smoke Test') { failFast params.FAIL_FAST parallel { ... {{ }}} However, that led to following exception: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 196: Expected a boolean with failFast @ line 196, column 7. failFast params.FAIL_FAST ^ It should be possible to use variables at this point.
Add Comment
[JIRA] (JENKINS-55257) Timestamper break builds on Windows agents
Title: Message Title Christoph Amshoff edited a comment on JENKINS-55257 Re: Timestamper break builds on Windows agents Same problem here after upgrading Jenkins Core from 2.138.3 to 2.150.1, along with several Pipeline/Blue Ocean plugin updates. Agents are running under Windows Server 2012 R2 and 2016. Removing timestamps() step fixed the build, but that's not really an option for us (lots of jobs in different branches), so we had to rollback the update... hence this is a showstopper, actually. Configuration worked before and did not change, so it's definitely related to the update and I doubt it's a configuration problem. 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-55257) Timestamper break builds on Windows agents
Title: Message Title Christoph Amshoff commented on JENKINS-55257 Re: Timestamper break builds on Windows agents Same problem here after upgrading Jenkins Core from 2.138.3 to 2.150.1, along with several Pipeline/Blue Ocean plugin updates. Agents are running under Windows Server 2012 R2 and 2016. Removing timestamps() step fixed the build, but that's not really an option for us (lots of jobs in different branches), so we had to rollback the update... hence this is a showstopper, actually. 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-54718) Claim plugin does not allow to claim unstable builds with declarative pipeline
Title: Message Title Christoph Amshoff closed an issue as Not A Defect This issue was caused by another issue of the pipeline-maven-plugin version 3.5.15, which does not set the build status correctly (to UNSTABLE) when tests are failing (see JENKINS-54559). Jenkins / JENKINS-54718 Claim plugin does not allow to claim unstable builds with declarative pipeline Change By: Christoph Amshoff Status: Open Closed Resolution: Not A Defect 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-54718) Claim plugin does not allow to claim unstable builds with declarative pipeline
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-54718
Claim plugin does not allow to claim unstable builds with declarative pipeline
Change By:
Christoph Amshoff
We're not able to claim unstable builds any more (with declarative pipeline). For failed builds, it still works. I'm pretty sure it worked for unstable builds as well so I guess this is a regression.The plugin is called in post section, independant of build result: {code:java} post { always { step([$class: 'ClaimPublisher']) }} {code} We're currently using: * Jenkins 2.138.3 * Claim Plugin 2.15
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-54718) Claim plugin does not allow to claim unstable builds with declarative pipeline
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-54718
Claim plugin does not allow to claim unstable builds with declarative pipeline
Change By:
Christoph Amshoff
We're not able to claim unstable builds any more (with declarative pipeline). For failed builds, it still works. I'm pretty sure it worked for unstable builds as well so I guess this is a regression.The plugin is called in post section, independant of build result: {quote}post { always { step([$class: 'ClaimPublisher']) } } {quote} We're currently using: * Jenkins 2.138.3 * Claim Plugin 2.15
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-54718) Claim plugin does not allow to claim unstable builds with declarative pipeline
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-54718
Claim plugin does not allow to claim unstable builds with declarative pipeline
Change By:
Christoph Amshoff
We're not able to claim unstable builds any more (with declarative pipeline). For failed builds, it still works. I'm pretty sure it worked for unstable builds as well so I guess this is a regression.The plugin is called in post section, independant of build result: { { quote} post { }} {{ {{ always { {{ {{ step([$class: 'ClaimPublisher']) {{ } } } { { quote } }} We're currently using: * Jenkins 2.138.3 * Claim Plugin 2.15
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-54718) Claim plugin does not allow to claim unstable builds with declarative pipeline
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-54718
Claim plugin does not allow to claim unstable builds with declarative pipeline
Change By:
Christoph Amshoff
We're not able to claim unstable builds any more (with declarative pipeline). For failed builds, it still works. I'm pretty sure it worked for unstable builds as well so I guess this is a regression.The plugin is called in post section, independant of build result:{{ post {}}{{ {{ always {}} }} {{ {{ step([$class: 'ClaimPublisher'])}} }} {{ }}}{{ }}}We're currently using: * Jenkins 2.138.3 * Claim Plugin 2.15
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-54718) Claim plugin does not allow to claim unstable builds with declarative pipeline
Title: Message Title
Christoph Amshoff created an issue
Jenkins / JENKINS-54718
Claim plugin does not allow to claim unstable builds with declarative pipeline
Issue Type:
Bug
Assignee:
Christian Bremer
Components:
claim-plugin
Created:
2018-11-20 08:48
Labels:
claim
Priority:
Major
Reporter:
Christoph Amshoff
We're not able to claim unstable builds any more (with declarative pipeline). For failed builds, it still works. I'm pretty sure it worked for unstable builds as well so I guess this is a regression. The plugin is called in post section, independant of build result: {{ post {}} always { step([$class: 'ClaimPublisher']) {{ }}} {{ }}} We're currently using:
Jenkins 2.138.3
Claim Plugin 2.15
Add Comment
[JIRA] (JENKINS-46507) Parallel Pipeline random java.lang.InterruptedException
Title: Message Title Christoph Amshoff commented on JENKINS-46507 Re: Parallel Pipeline random java.lang.InterruptedException Same issue here... We're having a quite small Jenkinsfile that calls a RESTful service, which takes (depending on parameters) few seconds up to an hour or more to complete. The JSON returned by the service should be attached to the build, that's why it's called synchronously. The longer the service call takes, the more likely the InterruptedException occurs. There are no parallel steps in our pipeline, so I'm pretty sure it's related to the long-running step. The REST call is done by some selfmade Groovy function and classes in our shared library, basically setting up a HttpURLConnection instance. However, that works nicely in fast service calls, so I don't think there is an issue in this code. Let me know if I can help with any files/logs. 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-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-50907
customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Change By:
Christoph Amshoff
The default workspace has the executor number in the path, separated by '@' sign, for example c:\builds\jenkins-slave\workspace\test@2 when running on executor number 2.This causes some trouble with our build scripts, so we'd like to use a path without '@' sign, but including the executor number (in order to isolate the builds). However, using something like{quote}agent \{ node \{ label " mu my - s-lfbld5 agent " customWorkspace "C:\builds\jenkins-slave\workspace\$\{JOB_NAME}_$\{EXECUTOR_NUMBER}" } }{quote}in declarative pipeline does not work, it will issue a groovy.lang.MissingPropertyException: No such property: EXECUTOR_NUMBER.Why can't EXECUTOR_NUMBER be used here? Any other way how this could be achieved?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message
[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-50907
customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Change By:
Christoph Amshoff
The default workspace has the executor number in the path, separated by '@' sign, for example c:\builds\jenkins-slave\workspace\test@2 when running on executor number 2.This causes some trouble with our build scripts, so we'd like to use a path without '@' sign, but including the executor number (in order to isolate the builds). However, using something like{quote}agent \{ node \{ label "mu-s-lfbld5" customWorkspace "C:\builds\jenkins-slave\workspace\$\{JOB_NAME}_$\{EXECUTOR_NUMBER}" } }{quote} in declarative pipeline does not work, it will issue a groovy.lang.MissingPropertyException: No such property: EXECUTOR_NUMBER.Why can't EXECUTOR_NUMBER be used here? Any other way how this could be achieved?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you
[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-50907
customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Change By:
Christoph Amshoff
The default workspace has the executor number in the path, separated by '@' sign, for example c:\builds\jenkins-slave\workspace\test@2 when running on executor number 2.This causes some trouble with our build scripts, so we'd like to use a path without '@' sign, but including the executor number (in order to isolate the builds). However, using something like{quote}agent \{ node \{ label "mu-s-lfbld5" customWorkspace "C:\ \ builds\ \ jenkins-slave\ \ workspace\ \job_ $\{JOB_NAME}_$\{EXECUTOR_NUMBER}" } }{quote}does not work, it will issue a groovy.lang.MissingPropertyException: No such property: EXECUTOR_NUMBER.Why can't EXECUTOR_NUMBER be used here? Any other way how this could be achieved?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are
[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-50907
customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Change By:
Christoph Amshoff
The default workspace has the executor number in the path, separated by '@' sign, for example c:\builds\jenkins-slave\workspace\test@2 when running on executor number 2.This causes some trouble with our build scripts, so we'd like to use a path without '@' sign, but including the executor number (in order to isolate the builds). However, using something like{quote}agent \{ node \{ label "mu-s-lfbld5" customWorkspace "C:\\builds\\jenkins-slave\\workspace\\ \ job_ $\{JOB_NAME}_$\{EXECUTOR_NUMBER}" } }{quote}does not work, it will issue a groovy.lang.MissingPropertyException: No such property: EXECUTOR_NUMBER. }} Why can't EXECUTOR_NUMBER be used here? Any other way how this could be achieved?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are
[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-50907
customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Change By:
Christoph Amshoff
The default workspace has the executor number in the path, separated by '@' sign, for example c:\builds\jenkins-slave\workspace\test@2 when running on executor number 2.This causes some trouble with our build scripts, so we'd like to use a path without '@' sign, but including the executor number (in order to isolate the builds). However, using something like{quote}agent \{ node \{ label "mu-s-lfbld5" customWorkspace "C:\\builds\\jenkins-slave\\workspace\\ \ $\{JOB_NAME}_$\{EXECUTOR_NUMBER}" }}{quote}does not work, it will issue a groovy.lang.MissingPropertyException: No such property: EXECUTOR_NUMBER.}}Why can't EXECUTOR_NUMBER be used here? Any other way how this could be achieved?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this message because you are subscribed to
[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-50907
customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Change By:
Christoph Amshoff
The default workspace has the executor number in the path, separated by '@' sign, for example c:\builds\jenkins-slave\workspace\test@2 when running on executor number 2.This causes some trouble with our build scripts, so we'd like to use a path without '@' sign, but including the executor number (in order to isolate the builds). However, using something like{quote} {{ agent \{ }} {{ node \{ }} {{ label "mu-s-lfbld5" }} {{ customWorkspace "C:\\builds\\jenkins-slave\\workspace\\$\{JOB_NAME}_$\{EXECUTOR_NUMBER}" }} {{ } } } { {}}}{ quote}does not work, it will issue a groovy.lang.MissingPropertyException: No such property: EXECUTOR_NUMBER.}}Why can't EXECUTOR_NUMBER be used here? Any other way how this could be achieved?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received
[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-50907
customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Change By:
Christoph Amshoff
The default workspace has the executor number in the path, separated by '@' sign, for example c:\builds\jenkins-slave\workspace\test@2 when running on executor number 2.This causes some trouble with our build scripts, so we'd like to use a path without '@' sign, but including the executor number (in order to isolate the builds). However, using something like { quote} { { agent \{}}{{ node \{}}{{ label " myagent mu-s-lfbld5 "}}{{ customWorkspace "C:\\builds\\jenkins-slave\\workspace\\$\{JOB_NAME}_$\{EXECUTOR_NUMBER}"}}{{ }}}{{ }}} { { quote} does not work, it will issue a groovy.lang.MissingPropertyException: No such property: EXECUTOR_NUMBER.}}Why can't EXECUTOR_NUMBER be used here? Any other way how this could be achieved?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You
[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title
Christoph Amshoff updated an issue
Jenkins / JENKINS-50907
customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Change By:
Christoph Amshoff
The default workspace has the executor number in the path, separated by '@' sign, for example c:\builds\jenkins-slave\workspace\test@2 when running on executor number 2.This causes some trouble with our build scripts, so we'd like to use a path without '@' sign, but including the executor number (in order to isolate the builds). However, using something like {{ agent \{ }} {{ node \{ }} {{ label "myagent" }} {{ customWorkspace ( "C:\\builds\\jenkins-slave\\workspace\\$\{JOB_NAME}_$\{EXECUTOR_NUMBER}" ) }} {{ } }} {{ } }} {{ does not work, it will issue a groovy.lang.MissingPropertyException: No such property: EXECUTOR_NUMBER. }} Why can't EXECUTOR_NUMBER be used here? Any other way how this could be achieved?
Add Comment
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
--
You received this
[JIRA] (JENKINS-50907) customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Title: Message Title
Christoph Amshoff created an issue
Jenkins / JENKINS-50907
customWorkspace setting of agent directive does not support EXECUTOR_NUMBER
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2018-04-20 09:48
Priority:
Critical
Reporter:
Christoph Amshoff
The default workspace has the executor number in the path, separated by '@' sign, for example c:\builds\jenkins-slave\workspace\test@2 when running on executor number 2. This causes some trouble with our build scripts, so we'd like to use a path without '@' sign, but including the executor number (in order to isolate the builds). However, using something like agent { node { label "myagent" customWorkspace("C:\\builds\\jenkins-slave\\workspace${JOB_NAME}_${EXECUTOR_NUMBER}") } } does not work, it will issue a groovy.lang.MissingPropertyException: No such property: EXECUTOR_NUMBER. Why can't EXECUTOR_NUMBER be used here? Any other way how this could be achieved?
Add Comment
[JIRA] (JENKINS-50368) Allow status of last finished build
Title: Message Title Christoph Amshoff created an issue Jenkins / JENKINS-50368 Allow status of last finished build Issue Type: Improvement Assignee: Antonio Muñiz Components: embeddable-build-status-plugin Created: 2018-03-23 13:42 Priority: Major Reporter: Christoph Amshoff For CI/CD jobs that are building all the time (and take a while to build), the status icon says "build running" most of the time. This information is not very useful, instead it would be great to be able to show status of last finished build. Add Comment
[JIRA] (JENKINS-43556) Stage View shows incorrect build result
Title: Message Title Christoph Amshoff commented on JENKINS-43556 Re: Stage View shows incorrect build result Same issue here for maybe one out of 30 builds; up to now this seems to happen just for the first successful build after a broken (failed) build. Build history is fine. logs don't show any issue, just the pipeline in stage view is rendered red. In Blue Ocean, everything looks good. I don't know if that heps, but when looking at the rendered HTML of stage view, I can see that tr has CSS classes "job FAILED", while all td's for the steps have classes "stage-cell stage-cell-x SUCCESS". We're using Jenkins 2.89.4, Pipeline Stage View Plugin 2.9 and Pipeline REST API plugin 2.9. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-49913) email-ext: check for attachment size does not consider compression
Title: Message Title Christoph Amshoff created an issue Jenkins / JENKINS-49913 email-ext: check for attachment size does not consider compression Issue Type: Bug Assignee: David van Laatum Components: email-ext-plugin Created: 2018-03-05 09:39 Priority: Major Reporter: Christoph Amshoff We are attaching build log to the mail in Jenkins pipeline, and are setting both "attachLog" and "compressLog" options to true. The build logs say "Skipping build log attachment - too large for maximum attachments size". When downloading the logs manually, these are about 40 MB in size (uncompressed) and less than 3 MB compressed. The "Maximum Attachment Size" is set to 16 MB on global setting page, so the compressed log should pass in any case. It seem the plugin is comparing size of uncompressed logs with the given limit, which is not what I would expect. Add Comment
