[JIRA] (JENKINS-55287) Pipeline: Failure to load flow node: FlowNode was not found in storage for head
Title: Message Title Falko Modler edited a comment on JENKINS-55287 Re: Pipeline: Failure to load flow node: FlowNode was not found in storage for head [~dnusbaum] & [~bitwiseman]I have three zipped build folders (all from around the same time, March 12th) but did not yet have the time ro to redact sensitive data. Do you have some hints what and where to look for (regarding sensitive data)? Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google 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.196374.1545361815000.2941.1585580220862%40Atlassian.JIRA.
[JIRA] (JENKINS-55287) Pipeline: Failure to load flow node: FlowNode was not found in storage for head
Title: Message Title Falko Modler commented on JENKINS-55287 Re: Pipeline: Failure to load flow node: FlowNode was not found in storage for head Devin Nusbaum & Liam Newman I have three zipped build folders (all from around the same time, March 12th) but did not yet have the time ro redact sensitive data. Do you have some hints what and where to look for (regarding sensitive data)? Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- You received this message because you are subscribed to the Google 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.196374.1545361815000.2899.1585580160957%40Atlassian.JIRA.
[JIRA] (JENKINS-61131) vsphere-cloud: Credentials selection is broken in UI since 2.22
Title: Message Title Falko Modler updated an issue Jenkins / JENKINS-61131 vsphere-cloud: Credentials selection is broken in UI since 2.22 Change By: Falko Modler It seems that [this JCasC related change |https://github.com/jenkinsci/vsphere-cloud-plugin/commit/35f498f3e74cbcf0b977bd2e660c415980d83705#diff-27ee676943f5bdc72c59cf11b0457840L140] JCasC related change broke Credentials selection in the UI (Manage Jenkins):Although Credentials are present for the given Jenkins instance, the respective dropdown list ist empty. Other Plugins can select the Credentials just fine.Setting the Credentials via JCasC works as expected but once you submit the "Manage Jenkins" page (with unrelated changes) the Credentials setting is reset to none. This is therefore a rather critical bug! 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
[JIRA] (JENKINS-61131) vsphere-cloud: Credentials selection is broken in UI since 2.22
Title: Message Title Falko Modler created an issue Jenkins / JENKINS-61131 vsphere-cloud: Credentials selection is broken in UI since 2.22 Issue Type: Bug Assignee: Unassigned Components: vsphere-cloud-plugin Created: 2020-02-18 15:35 Environment: Jenkins LTS 2.204.2 Latest plugin versions as of 18.02.2020 Priority: Critical Reporter: Falko Modler It seems that this JCasC related change broke Credentials selection in the UI (Manage Jenkins): Although Credentials are present for the given Jenkins instance, the respective dropdown list ist empty. Other Plugins can select the Credentials just fine. Setting the Credentials via JCasC works as expected but once you submit the "Manage Jenkins" page (with unrelated changes) the Credentials setting is reset to none. This is therefore a rather critical bug! Add Comment
[JIRA] (JENKINS-55287) Pipeline: Failure to load flow node: FlowNode was not found in storage for head
Title: Message Title Falko Modler commented on JENKINS-55287 Re: Pipeline: Failure to load flow node: FlowNode was not found in storage for head Any news? This is biting us on a regular basis. 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.196374.1545361815000.8859.1581606300911%40Atlassian.JIRA.
[JIRA] (JENKINS-46553) Maven surefire timeout treated as successful build
Title: Message Title Falko Modler commented on JENKINS-46553 Re: Maven surefire timeout treated as successful build What we would need is another Maven Surefire property/feature, that differentiates between regular test failures and timeouts. I've just created a ticket for that: https://issues.apache.org/jira/browse/SUREFIRE-1728 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.184875.1504135901000.7916.1574893980197%40Atlassian.JIRA.
[JIRA] (JENKINS-43758) Parameters disappear from pipeline job after running the job
Title: Message Title Falko Modler commented on JENKINS-43758 Re: Parameters disappear from pipeline job after running the job Annother super annoyed user here (sorry to say that, but that's just the truth). We are setting up most of our jobs via JCasC (which wraps JobDSL) and every single time we execute our JCasC yaml files, all properties that are defined by the respective pipeline scripts are lost: parameters, triggers, sidebar links etc. Losing parameters of jobs that are triggered not by human project members but by other systems/scripts (e.g. Pull Request Notifier for Bitbucket Server) is especially painful. Those jobs frequently triggered by human project members will sooner or later re-receive their parameters because someone will just click "Build Now" eventually but those jobs triggered from outside will just never run (rejected because of "unknown" parameters?). Every single time we execute our JCasC scripts we have to go through a list of jobs and "fix" them by clicking "Build Now". Yes, we could write a script for that but some jobs don't have parameters. Instead they need to have their scm-polling re-initialized. Since some of those jobs run for many hours, so we need to abort them right away. Writing a script for all those cases feels like investing too much time on the wrong end of the problem. I am willing to contribute a fix but where to start? What is the right approach? Should we start with an opt-in to preserve (instead of wipe) parameters, triggers etc.? 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
[JIRA] (JENKINS-55485) Declarative pipeline, lock() in stage options is executed before when clause
Title: Message Title Falko Modler commented on JENKINS-55485 Re: Declarative pipeline, lock() in stage options is executed before when clause Note: JENKINS-51865 is done, new beforeOptions in when ist available in pipeline-model-definition 1.4.0. 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.196615.1547045335000.13304.1573643760620%40Atlassian.JIRA.
[JIRA] (JENKINS-55485) Declarative pipeline, lock() in stage options is executed before when clause
Title: Message Title
Falko Modler edited a comment on JENKINS-55485
Re: Declarative pipeline, lock() in stage options is executed before when clause
Note: JENKINS-51865 is done, new {{beforeOptions}} in {{when}} ist is available in pipeline-model-definition 1.4.0.
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.196615.1547045335000.13311.1573643760785%40Atlassian.JIRA.
[JIRA] (JENKINS-51865) Stage locks are created for skipped stages in declarative pipeline
Title: Message Title Falko Modler commented on JENKINS-51865 Re: Stage locks are created for skipped stages in declarative pipeline Liam Newman I have just resolved this ticket because the fix is in cluded in 1.4.0. I am not familiar with the overall ticket workflow, though. So I leave it up to you (or Andrew Bayer) to close this issue. 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.191345.1528726775000.13286.1573643640675%40Atlassian.JIRA.
[JIRA] (JENKINS-51865) Stage locks are created for skipped stages in declarative pipeline
Title: Message Title Falko Modler edited a comment on JENKINS-51865 Re: Stage locks are created for skipped stages in declarative pipeline [~bitwiseman] I have just resolved this ticket because the fix is included in cluded in 1.4.0. I am not familiar with the overall ticket workflow, though.So I leave it up to you (or [~abayer]) to close this issue. 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.191345.1528726775000.13288.1573643640774%40Atlassian.JIRA.
[JIRA] (JENKINS-51865) Stage locks are created for skipped stages in declarative pipeline
Title: Message Title Falko Modler updated JENKINS-51865 Jenkins / JENKINS-51865 Stage locks are created for skipped stages in declarative pipeline Change By: Falko Modler Status: Open Fixed but Unreleased Resolution: Fixed Released As: https://github.com/jenkinsci/pipeline-model-definition-plugin/releases/tag/pipeline-model-definition-1.4.0 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.191345.1528726775000.13264.1573643581543%40Atlassian.JIRA.
[JIRA] (JENKINS-51865) Stage locks are created for skipped stages in declarative pipeline
Title: Message Title Falko Modler updated JENKINS-51865 Jenkins / JENKINS-51865 Stage locks are created for skipped stages in declarative pipeline Change By: Falko Modler Status: Fixed but Unreleased Resolved 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.191345.1528726775000.13266.1573643581587%40Atlassian.JIRA.
[JIRA] (JENKINS-51865) Stage locks are created for skipped stages in declarative pipeline
Title: Message Title Falko Modler assigned an issue to Falko Modler Jenkins / JENKINS-51865 Stage locks are created for skipped stages in declarative pipeline Change By: Falko Modler Assignee: Andrew Bayer Falko Modler 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.191345.1528726775000.13245.1573643520439%40Atlassian.JIRA.
[JIRA] (JENKINS-59980) Merge beforeOptions, beforeInput and beforeAgent into a single before attribute
Title: Message Title Falko Modler commented on JENKINS-59980 Re: Merge beforeOptions, beforeInput and beforeAgent into a single before attribute Liam Newman While I am always glad to help improving Jenkins (plugins) I currently don't have time for this, sorry. PS: Are you sure about changing the example from before 'options' to before git? Right now we don't have beforeGit, so do you have something new in mind? 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.202785.1572385981000.8847.1572911880256%40Atlassian.JIRA.
[JIRA] (JENKINS-59980) Merge beforeOptions, beforeInput and beforeAgent into a single before attribute
Title: Message Title
Falko Modler updated an issue
Jenkins / JENKINS-59980
Merge beforeOptions, beforeInput and beforeAgent into a single before attribute
Change By:
Falko Modler
There are now _three_ different {{before}} attributes for {{when}} which are evaluated in this very order:- {{beforeOptions}}- {{beforeInput}}- {{beforeAgent}}The documentation tries to describe this "highlander principle" but it would be much more logical and readable if there was only a single attribute {{before}} allowing only a single value of {{options}}, {{input}} or {{agent}}.E.g.:{noformat}when {before 'options'// ...}{noformat} Migration consideration: The old dedicated {{before}} attributes should not be removed right away. Instead those attributes should be marked deprecated and their usage should yield warnings in the log.
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"
[JIRA] (JENKINS-59980) Merge beforeOptions, beforeInput and beforeAgent into a single before attribute
Title: Message Title
Falko Modler created an issue
Jenkins / JENKINS-59980
Merge beforeOptions, beforeInput and beforeAgent into a single before attribute
Issue Type:
Improvement
Assignee:
Andrew Bayer
Components:
pipeline-model-definition-plugin
Created:
2019-10-29 21:53
Priority:
Minor
Reporter:
Falko Modler
There are now three different before attributes for when which are evaluated in this very order:
beforeOptions
beforeInput
beforeAgent
The documentation tries to describe this "highlander principle" but it would be much more logical and readable if there was only a single attribute before allowing only a single value of options, input or agent. E.g.:
when {
before 'options'
// ...
}
[JIRA] (JENKINS-51865) Stage locks are created for skipped stages in declarative pipeline
Title: Message Title Falko Modler commented on JENKINS-51865 Re: Stage locks are created for skipped stages in declarative pipeline I created a PR for this: https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/356 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.191345.1528726775000.8398.1571179260456%40Atlassian.JIRA.
[JIRA] (JENKINS-59583) JunitTestsPublisher: Also set stage result
Title: Message Title
Falko Modler updated an issue
Jenkins / JENKINS-59583
JunitTestsPublisher: Also set stage result
Change By:
Falko Modler
There is already a TODO in the code:{code:java|title=https://github.com/jenkinsci/pipeline-maven-plugin/blob/pipeline-maven-3.8.1/jenkins-plugin/src/main/java/org/jenkinsci/plugins/pipeline/maven/publishers/JunitTestsPublisher.java#L337-L339}// TODO: Once JENKINS-43995 lands, update this to set the step status instead of the entire build.// context.setResult(Result.UNSTABLE);run.setResult(Result.UNSTABLE);{code}Now with JENKINS-43995 done, this should be implemented via{code:java}context.get(FlowNode.class). add addAction (new WarningAction(Result.UNSTABLE).withMessage(...){code}or maybe even {{addOrReplaceAction()}} as in https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/workflow-basic-steps-2.18/src/main/java/org/jenkinsci/plugins/workflow/steps/UnstableStep.java#L73
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-59583) JunitTestsPublisher: Also set stage result
Title: Message Title
Falko Modler updated an issue
Jenkins / JENKINS-59583
JunitTestsPublisher: Also set stage result
Change By:
Falko Modler
There is already a TODO in the code:{code:java|title=https://github.com/jenkinsci/pipeline-maven-plugin/blob/pipeline-maven-3.8.1/jenkins-plugin/src/main/java/org/jenkinsci/plugins/pipeline/maven/publishers/JunitTestsPublisher.java#L337-L339}// TODO: Once JENKINS-43995 lands, update this to set the step status instead of the entire build.// context.setResult(Result.UNSTABLE);run.setResult(Result.UNSTABLE);{code}Now with JENKINS-43995 done, this should be implemented via{code:java}context.get(FlowNode.class).add(new WarningAction(Result.UNSTABLE).withMessage(...){code}or maybe even ` {{ addOrReplaceAction() ` }} as in https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/workflow-basic-steps-2.18/src/main/java/org/jenkinsci/plugins/workflow/steps/UnstableStep.java#L73
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-59583) JunitTestsPublisher: Also set stage result
Title: Message Title Falko Modler started work on JENKINS-59583 Change By: Falko Modler Status: Open In Progress 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.202223.1569840167000.7738.1569840180246%40Atlassian.JIRA.
[JIRA] (JENKINS-59583) JunitTestsPublisher: Also set stage result
Title: Message Title Falko Modler created an issue Jenkins / JENKINS-59583 JunitTestsPublisher: Also set stage result Issue Type: Improvement Assignee: Falko Modler Components: pipeline-maven-plugin Created: 2019-09-30 10:42 Priority: Minor Reporter: Falko Modler There is already a TODO in the code: https://github.com/jenkinsci/pipeline-maven-plugin/blob/pipeline-maven-3.8.1/jenkins-plugin/src/main/java/org/jenkinsci/plugins/pipeline/maven/publishers/JunitTestsPublisher.java#L337-L339 // TODO: Once JENKINS-43995 lands, update this to set the step status instead of the entire build. // context.setResult(Result.UNSTABLE); run.setResult(Result.UNSTABLE); Now with JENKINS-43995 done, this should be implemented via context.get(FlowNode.class).add(new WarningAction(Result.UNSTABLE).withMessage(...) or maybe even `addOrReplaceAction()` as in https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/workflow-basic-steps-2.18/src/main/java/org/jenkinsci/plugins/workflow/steps/UnstableStep.java#L73
[JIRA] (JENKINS-59114) Maven output is not colorized
Title: Message Title Falko Modler commented on JENKINS-59114 Re: Maven output is not colorized Sorry, must have missed that. The formatting is a bit off, though. This actually works for me. The one main difference is that I am using withMaven and then sh "mvn ...". And my Jenkins is running on CentOS 7, yours is a Windows machine... 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.201539.1566962562000.1424.1568231640224%40Atlassian.JIRA.
[JIRA] (JENKINS-59114) Maven output is not colorized
Title: Message Title Falko Modler commented on JENKINS-59114 Re: Maven output is not colorized You have to add -Dstyle.color=always to the mvn invocation (not to MAVEN_OPTS like jansi.force). See: https://issues.jenkins-ci.org/browse/JENKINS-44543?focusedCommentId=331794=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-331794 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.201539.1566962562000.1332.1568211840302%40Atlassian.JIRA.
[JIRA] (JENKINS-46553) Maven surefire timeout treated as successful build
Title: Message Title
Falko Modler commented on JENKINS-46553
Re: Maven surefire timeout treated as successful build
Plot twist: I don't think anymore that Jenkins is to blame, at least in my case: I am (and probably most other Jenkins users are) setting -Dmaven.test.failure.ignore=true to get all test results instead of a failing build after the first module with test failures. This is where https://issues.apache.org/jira/browse/SUREFIRE-953 comes into play! What we would need is another Maven Surefire property/feature, that differentiates between regular test failures and timeouts. For now I am using the following pipeline lib function which I just need to call in my pipelines (in some post block) without any parameters:
// Parses the console log file for known errors (that Jenkins does not properly recognize as build failures) and fails the build if any are found.
def call() {
def known = [
'There was a timeout or other error in the fork'// https://issues.jenkins-ci.org/browse/JENKINS-46553
]
def consoleLogFile = "${WORKSPACE}/../builds/${BUILD_NUMBER}/log"
println "Checking for known errors in console log file that are not properly handled by Jenkins: ${consoleLogFile}"
// grep the cosole log, notes:
// - "set +x" to avoid echoing the grep command which would lead to a false positive
// - "set +e" to avoid build failure due to non-zero exit code (otherwise "exit 0" wouldn't be reached)
def foundErrors = sh(script: "set +xe && grep '${known.join('|')}' ${consoleLogFile}; exit 0", returnStdout: true)
if (foundErrors != "") {
error("Found known errors in the log (see previous outputs for more context):\n${foundErrors}")
}
}
PS: Yes I know, directly "grepping" the log file is not good practise. I also haven't tested this with/on slaves. I do also know that there are log parsing plugins but they do come with their own litte quirks, bugs and overhead...
Add Comment
[JIRA] (JENKINS-46553) Maven surefire timeout treated as successful build
Title: Message Title
Falko Modler edited a comment on JENKINS-46553
Re: Maven surefire timeout treated as successful build
*Plot twist*: I don't think anymore that Jenkins is to blame, at least in my case:I am (and probably most other Jenkins users are) setting {{-Dmaven.test.failure.ignore=true}} to get all test results instead of a failing build after the first module with test failures.This is where https://issues.apache.org/jira/browse/SUREFIRE-953 comes into play!What we would need is another Maven Surefire property/feature, that differentiates between regular test failures and timeouts.For now I am using the following pipeline lib function which I just need to call in my pipelines (in some {{post}} block) without any parameters:{code:groovy |title=failOnKnownConsoleLogPatterns.groovy }// Parses the console log file for known errors (that Jenkins does not properly recognize as build failures) and fails the build if any are found.def call() {def known = ['There was a timeout or other error in the fork'// https://issues.jenkins-ci.org/browse/JENKINS-46553]def consoleLogFile = "${WORKSPACE}/../builds/${BUILD_NUMBER}/log"println "Checking for known errors in console log file that are not properly handled by Jenkins: ${consoleLogFile}"// grep the cosole log, notes:// - "set +x" to avoid echoing the grep command which would lead to a false positive// - "set +e" to avoid build failure due to non-zero exit code (otherwise "exit 0" wouldn't be reached)def foundErrors = sh(script: "set +xe && grep '${known.join('|')}' ${consoleLogFile}; exit 0", returnStdout: true)if (foundErrors != "") {error("Found known errors in the log (see previous outputs for more context):\n${foundErrors}")}}{code}PS: Yes I know, directly "grepping" the log file is not good practise. I also haven't tested this with/on slaves.I do also know that there are log parsing plugins but they do come with their own litte quirks, bugs and overhead...
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-46553) Maven surefire timeout treated as successful build
Title: Message Title
Falko Modler edited a comment on JENKINS-46553
Re: Maven surefire timeout treated as successful build
Same here. In a regular shell (locally, not in Jenkins) the error is manifested as a build failure:{noformat}[INFO][INFO] Results:[INFO][INFO] Tests run: 13, Failures: 0, Errors: 0, Skipped: 0[INFO][INFO] [INFO] BUILD FAILURE[INFO] [INFO] Total time: 57.572 s[INFO] Finished at: 2019-09-09T13:36:55+02:00[INFO] Final Memory: 50M/1024M[INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.21.0:test (default-test) on project some-project: There was a timeout or other error in the fork -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.21.0:test (default-test) on project some-project: There was a timeout or other error in the forkat org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)Caused by: org.apache.maven.plugin.MojoFailureException: There was a timeout or other error in the forkat org.apache.maven.plugin.surefire.SurefireHelper.throwException(SurefireHelper.java:240)at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:112)at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:354)at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1008)at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:854)at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)at
[JIRA] (JENKINS-46553) Maven surefire timeout treated as successful build
Title: Message Title
Falko Modler edited a comment on JENKINS-46553
Re: Maven surefire timeout treated as successful build
Same here. In a regular shell (locally, not in Jenkins) the error is manifested as a build failure:{noformat}[ INFO][INFO] Results:[INFO][INFO] Tests run: 13, Failures: 0, Errors: 0, Skipped: 0[INFO][INFO] [INFO] BUILD FAILURE[INFO] [INFO] Total time: 57.572 s[INFO] Finished at: 2019-09-09T13:36:55+02:00[INFO] Final Memory: 50M/1024M[INFO] [ ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.21.0:test (default-test) on project some-project: There was a timeout or other error in the fork -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.21.0:test (default-test) on project some-project: There was a timeout or other error in the forkat org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212)at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307)at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193)at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106)at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863)at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)at org.apache.maven.cli.MavenCli.main(MavenCli.java:199)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)at java.lang.reflect.Method.invoke(Method.java:498)at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)Caused by: org.apache.maven.plugin.MojoFailureException: There was a timeout or other error in the forkat org.apache.maven.plugin.surefire.SurefireHelper.throwException(SurefireHelper.java:240)at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:112)at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:354)at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1008)at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:854)at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)at
[JIRA] (JENKINS-46553) Maven surefire timeout treated as successful build
Title: Message Title Falko Modler commented on JENKINS-46553 Re: Maven surefire timeout treated as successful build Same here. In a regular shell (locally, not in Jenkins) the error is manifested as a build failure: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.21.0:test (default-test) on project some-project: There was a timeout or other error in the fork -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.21.0:test (default-test) on project some-project: There was a timeout or other error in the fork at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:212) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:307) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:193) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:106) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:863) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288) at org.apache.maven.cli.MavenCli.main(MavenCli.java:199) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356) Caused by: org.apache.maven.plugin.MojoFailureException: There was a timeout or other error in the fork at org.apache.maven.plugin.surefire.SurefireHelper.throwException(SurefireHelper.java:240) at org.apache.maven.plugin.surefire.SurefireHelper.reportExecution(SurefireHelper.java:112) at org.apache.maven.plugin.surefire.SurefirePlugin.handleSummary(SurefirePlugin.java:354) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.executeAfterPreconditionsChecked(AbstractSurefireMojo.java:1008) at org.apache.maven.plugin.surefire.AbstractSurefireMojo.execute(AbstractSurefireMojo.java:854) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:207) ... 20 more [ERROR] [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following
[JIRA] (JENKINS-59153) Link to Job sporadically broken due to null Jenkins root URL
Title: Message Title Falko Modler commented on JENKINS-59153 Re: Link to Job sporadically broken due to null Jenkins root URL PR 54 switches from `new` to `.get()`. 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.201590.1567184497000.3387.1567188780186%40Atlassian.JIRA.
[JIRA] (JENKINS-59153) Link to Job sporadically broken due to null Jenkins root URL
Title: Message Title
Falko Modler edited a comment on JENKINS-59153
Re: Link to Job sporadically broken due to null Jenkins root URL
[PR 54|https://github.com/jenkinsci/rocketchatnotifier-plugin/pull/54] switches from ` {{ new ` }} to ` {{ .get() ` }} .
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.201590.1567184497000.3389.1567188780211%40Atlassian.JIRA.
[JIRA] (JENKINS-59154) Emoji support for publisher usage
Title: Message Title Falko Modler created an issue Jenkins / JENKINS-59154 Emoji support for publisher usage Issue Type: Improvement Assignee: Martin Reinhardt Components: rocket-chat-notifier-plugin Created: 2019-08-30 17:11 Priority: Minor Reporter: Falko Modler I could not figure out how to set a specific emoji (like :sob: for failing builds) when using this plugin as a publisher (not as a pipeline step). Ideally, one should be able to set a specific emoji for each status (e.g. :sob: for failing builds, :ok_hand: for successful builds etc.). Add Comment
[JIRA] (JENKINS-59153) Link to Job sporadically broken due to null Jenkins root URL
Title: Message Title
Falko Modler updated an issue
Jenkins / JENKINS-59153
Link to Job sporadically broken due to null Jenkins root URL
Change By:
Falko Modler
I had very inconsistent results when testing this plugin as a publisher (not as a pipeline step)._Sporadically_, the "{{... (Open)}}" link in the message was showing up as "{{()}}".The {{null}} part is the Jenkins root URL.I don't really understand how this can happen because _both_ the "Jenkins URL" under "Jenkins Location" _and_ "Build Server URL" under "Global RocketChat Notifier Settings" are configured properly.After some research I did find the following statement regarding the usage of {{new JenkinsLocationConfiguration()}} vs {{JenkinsLocationConfiguration.get()}}:https://issues.jenkins-ci.org/browse/JENKINS-52983?focusedCommentId=347707=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-347707RC notifier is using the apparently "deprecated" {{new JenkinsLocationConfiguration() }} approach which should be switched to {{.get()}}, AFAICS.
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-59153) Link to Job sporadically broken due to null Jenkins root URL
Title: Message Title
Falko Modler updated an issue
Jenkins / JENKINS-59153
Link to Job sporadically broken due to null Jenkins root URL
Change By:
Falko Modler
I had very inconsistent results when testing this plugin as a publisher (not as a pipeline step)._Sporadically_, the " {{... (Open)}} " link in the message was showing up as " {{()}} " .The {{null}} part is the Jenkins root URL.I don't really understand how this can happen because _both_ the "Jenkins URL" under "Jenkins Location" _and_ "Build Server URL" under "Global RocketChat Notifier Settings" are configured properly.After some research I did find the following statement regarding the usage of {{new JenkinsLocationConfiguration()}} vs {{JenkinsLocationConfiguration.get()}}:https://issues.jenkins-ci.org/browse/JENKINS-52983?focusedCommentId=347707=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-347707RC notifier is using the apparently "deprecated" {{new}} approach which should be switched to {{.get()}}, AFAICS.
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-59153) Link to Job sporadically broken due to null Jenkins root URL
Title: Message Title Falko Modler created an issue Jenkins / JENKINS-59153 Link to Job sporadically broken due to null Jenkins root URL Issue Type: Bug Assignee: Martin Reinhardt Components: rocket-chat-notifier-plugin Created: 2019-08-30 17:01 Priority: Minor Reporter: Falko Modler I had very inconsistent results when testing this plugin as a publisher (not as a pipeline step). Sporadically, the ... (Open) link in the message was showing up as (). The null part is the Jenkins root URL. I don't really understand how this can happen because both the "Jenkins URL" under "Jenkins Location" and "Build Server URL" under "Global RocketChat Notifier Settings" are configured properly. After some research I did find the following statement regarding the usage of new JenkinsLocationConfiguration() vs JenkinsLocationConfiguration.get(): https://issues.jenkins-ci.org/browse/JENKINS-52983?focusedCommentId=347707=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-347707 RC notifier is using the apparently "deprecated" new approach which should be switched to .get(), AFAICS. Add Comment
[JIRA] (JENKINS-48591) Concurrent Builds Plugin Does not work properly
Title: Message Title Falko Modler commented on JENKINS-48591 Re: Concurrent Builds Plugin Does not work properly A whitespace instead of comma seems to work for me. See also: https://github.com/jenkinsci/throttle-concurrent-builds-plugin/pull/59 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.187234.1513425323000.2867.1567093081764%40Atlassian.JIRA.
[JIRA] (JENKINS-48591) Concurrent Builds Plugin Does not work properly
Title: Message Title Falko Modler edited a comment on JENKINS-48591 Re: Concurrent Builds Plugin Does not work properly A whitespace instead of comma to separate the parameter names seems to work for me. See also: https://github.com/jenkinsci/throttle-concurrent-builds-plugin/pull/59 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.187234.1513425323000.2869.1567093082217%40Atlassian.JIRA.
[JIRA] (JENKINS-58425) withMaven prints debug log and pollutes
Title: Message Title
Falko Modler commented on JENKINS-58425
Re: withMaven prints debug log and pollutes
Same here. I had to add {{ | tail -1}} to my mvn help:evaluate execution.
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.200552.1562762817000.2159.1565729640367%40Atlassian.JIRA.
[JIRA] (JENKINS-58425) withMaven prints debug log and pollutes
Title: Message Title
Falko Modler edited a comment on JENKINS-58425
Re: withMaven prints debug log and pollutes
Same here. I had to add {{ | tail -1}} to my {{mvn help:evaluate}} execution.
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.200552.1562762817000.2162.1565729640472%40Atlassian.JIRA.
[JIRA] (JENKINS-58425) withMaven prints debug log and pollutes
Title: Message Title
Falko Modler edited a comment on JENKINS-58425
Re: withMaven prints debug log and pollutes
Same here. I had to add {{ " | tail -1 }} " to my {{mvn help:evaluate}} execution.
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.200552.1562762817000.2165.1565729640612%40Atlassian.JIRA.
[JIRA] (JENKINS-51865) Stage locks are created for skipped stages in declarative pipeline
Title: Message Title
Falko Modler edited a comment on JENKINS-51865
Re: Stage locks are created for skipped stages in declarative pipeline
[~wgc123]{quote}It also doesn’t work because either you hardcore “dummy” and potentially block on it{quote}Those potential blocks/locks are very short-lived. You could also define a pool of multiple "dummy" resources to further reduce the (already very small) impact.So this partial workaround is better than nothing.[~abayer]{quote}You can always put lock or timeout (and any other block-scoped options) in your steps instead.{quote}Unfortunately, this is no solution/workaround for {{post}} blocks. E.g. you lock some external resource/server and in ` {{ post ` }} you want to collect the server's logfiles (regardless of the build status).So IMHO, {{beforeOptions}} is still needed.
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-51865) Stage locks are created for skipped stages in declarative pipeline
Title: Message Title Falko Modler commented on JENKINS-51865 Re: Stage locks are created for skipped stages in declarative pipeline D Pasto It also doesn’t work because either you hardcore “dummy” and potentially block on it Those potential blocks/locks are very short-lived. You could also define a pool of multiple "dummy" resources to further reduce the (already very small) impact. So this partial workaround is better than nothing. Andrew Bayer You can always put lock or timeout (and any other block-scoped options) in your steps instead. Unfortunately, this is no solution/workaround for post blocks. E.g. you lock some external resource/server and in `post` you want to collect the server's logfiles (regardless of the build status). So IMHO, beforeOptions is still needed. 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-43002) Unable to lock by label in a declarative pipeline script
Title: Message Title Falko Modler commented on JENKINS-43002 Re: Unable to lock by label in a declarative pipeline script fwiw, you can do lock(resource: null, label: 'foo') and that'll work fine. I think. Confirmed (Jenkins 2.150.3, pipeline-model-definition 1.3.4.1). 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-56457) Regression in timestamper 1.9: Start of maven plugins is logged with different format
Title: Message Title Falko Modler updated an issue Jenkins / JENKINS-56457 Regression in timestamper 1.9: Start of maven plugins is logged with different format Change By: Falko Modler Environment: Jenkins 2.150.3All Pipeline plugins pretty much up to date 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-56457) Regression in timestamper 1.9: Start of maven plugins is logged with different format
Title: Message Title Falko Modler created an issue Jenkins / JENKINS-56457 Regression in timestamper 1.9: Start of maven plugins is logged with different format Issue Type: Bug Assignee: Steven G Brown Components: timestamper-plugin Created: 2019-03-07 11:48 Environment: Jenkins 2.150.3 All Pipeline plugins pretty up to date Priority: Minor Reporter: Falko Modler After the upgrade from 1.8.10 to 1.9 I am seeing strange format changes: 1.8.10 12:25:11 [INFO] --- maven-clean-plugin:3.0.0:clean (default-clean) @ root --- 12:25:11 [INFO] Clean is skipped. 12:25:11 [INFO] Execution of maven-clean-plugin:3.0.0:clean (default-clean) @ root took 0.063s 12:25:11 [INFO] 12:25:11 [INFO] --- maven-enforcer-plugin:3.0.0-M1-MMS1:enforce (enforce-versions) @ root --- 12:25:11 [INFO] Skipping Rule Enforcement. 12:25:11 [INFO] Execution of maven-enforcer-plugin:3.0.0-M1-MMS1:enforce (enforce-versions) @ root took 0.125s 1.9
[JIRA] (JENKINS-51865) Stage locks are created for skipped stages in declarative pipeline
Title: Message Title
Falko Modler commented on JENKINS-51865
Re: Stage locks are created for skipped stages in declarative pipeline
Stephen Connolly thanks for sharing your workaround. Unfortunately this won't work in case the criteria to check of is calculcated in a previous stage, e.g.:
pipeline {
stages {
stage('Calculate criteria') {
steps {
script {
someCriteria = true
}
}
}
stage('Example stage') {
when {
_expression_ {
return someCriteria
}
}
options { lock resource: "${someCriteria ? 'example resource':'dummy'}" }
steps { // ... }
}
}
}
This will fail in options with:
groovy.lang.MissingPropertyException: No such property: someCriteria for class: groovy.lang.Binding
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-54038) Jacoco creates multiple Coverage reports and Trends graphs
Title: Message Title
Falko Modler edited a comment on JENKINS-54038
Re: Jacoco creates multiple Coverage reports and Trends graphs
A very stripped down excerpt of my setup:{noformat:title=somewhere in your stage}withMaven(publisherStrategy: 'EXPLICIT' , options: [junitPublisher( ) ]) {sh "mvn clean install -Pjacoco"}{noformat}{code:xml|title=custom 'jacoco' maven profile}jacoco org.jacoco jacoco-maven-plugin prepare-agent prepare-agent jacoco.agent.argLine org.apache.maven.plugins maven-surefire-plugin ${jacoco.agent.argLine} ${surefire.argLine} {code}{noformat:title=somewhere in your pipeline, e.g. in an 'always' post block}post {always {jacoco(exclusionPattern: '**/test*/**/*.class,**/gen/**/*.class', inclusionPattern: 'com/somecompany/someproject/**/*.class,com/somecompany/module/**/*.class')}}{noformat}The patterns are just an example.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54038) Jacoco creates multiple Coverage reports and Trends graphs
Title: Message Title
Falko Modler commented on JENKINS-54038
Re: Jacoco creates multiple Coverage reports and Trends graphs
A very stripped down excerpt of my setup:
somewhere in your stage
withMaven(publisherStrategy: 'EXPLICIT') {
sh "mvn clean install -Pjacoco"
}
custom 'jacoco' maven profile
jacoco
org.jacoco
jacoco-maven-plugin
prepare-agent
prepare-agent
jacoco.agent.argLine
org.apache.maven.plugins
maven-surefire-plugin
${jacoco.agent.argLine} ${surefire.argLine}
somewhere in your pipeline, e.g. in an 'always' post block
post {
always {
jacoco(exclusionPattern: '**/test*/**/*.class,**/gen/**/*.class',
inclusionPattern: 'com/somecompany/someproject/**/*.class,com/somecompany/module/**/*.class')
}
}
The patterns are just an example.
[JIRA] (JENKINS-54038) Jacoco creates multiple Coverage reports and Trends graphs
Title: Message Title Falko Modler commented on JENKINS-54038 Re: Jacoco creates multiple Coverage reports and Trends graphs This ticket should be closed as this is not happening anymore with pipeline-maven 3.5.15+ (see comments above). 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-54139) Jacoco report rendering problem in multi module projects
Title: Message Title Falko Modler commented on JENKINS-54139 Re: Jacoco report rendering problem in multi module projects Cross-reference which might help other users who are trying to figure out how to create one big report for multipe maven modules: https://issues.jenkins-ci.org/browse/JENKINS-54038?focusedCommentId=359814=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-359814 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-54038) Jacoco creates multiple Coverage reports and Trends graphs
Title: Message Title
Falko Modler edited a comment on JENKINS-54038
Re: Jacoco creates multiple Coverage reports and Trends graphs
Update to my previous comment:The *workaround* for recent {{pipeline-maven}} versions is actually easier than I first thought:*Don't rely* on {{withMaven()}} to create your aggregated report, just add an explicit {{jacoco()}} invokation invocation instead!This will automatically "merge" all the {{exec}} files to create one big report for everything.If you want to _explicitly_ disable the jacoco report publishing via {{withMaven()}} (which doesn't work anyway for multiple modules) you have two options:- {{withMaven(publisherStrategy: 'EXPLICIT', options: [...])}} (don't add {{jacocoPublisher()}} to options)- {{withMaven(options: [jacocoPublisher(disabled: true)],...)}}
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-54038) Jacoco creates multiple Coverage reports and Trends graphs
Title: Message Title
Falko Modler edited a comment on JENKINS-54038
Re: Jacoco creates multiple Coverage reports and Trends graphs
Update to my previous comment:The *workaround* for recent {{pipeline-maven}} versions is actually easier than I first thought: Just * don Don 't rely* on {{withMaven()}} to create your aggregated report, just add an explicit {{jacoco()}} invokation instead!This will automatically "merge" all the {{exec}} files to create one big report for everything.If you want to _explicitly_ disable the jacoco report publishing via {{withMaven()}} (which doesn't work anyway for multiple modules) you have two options:- {{withMaven(publisherStrategy: 'EXPLICIT', options: [...])}} (don't add {{jacocoPublisher()}} to options)- {{withMaven(options: [jacocoPublisher(disabled: true)],...)}}
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-54038) Jacoco creates multiple Coverage reports and Trends graphs
Title: Message Title Falko Modler commented on JENKINS-54038 Re: Jacoco creates multiple Coverage reports and Trends graphs Update to my previous comment: The workaround for recent pipeline-maven versions is actually easier than I first thought: Just don't rely on withMaven() to create your aggregated report, just add an explicit jacoco() invokation instead! This will automatically "merge" all the exec files to create one big report for everything. If you want to explicitly disable the jacoco report publishing via withMaven() (which doesn't work anyway for multiple modules) you have two options: withMaven(publisherStrategy: 'EXPLICIT', options: [...]) (don't add jacocoPublisher() to options) withMaven(options: [jacocoPublisher(disabled: true)],...) 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-46095) Allow pipeline configuration to stop trend graphs from rendering
Title: Message Title Falko Modler commented on JENKINS-46095 Re: Allow pipeline configuration to stop trend graphs from rendering Any updates on this one? We are building a project with > 90 modules incrementally via gitflow-incremental-builder and in that scenario the graphs are more confusing than helpful. 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-54038) Jacoco creates multiple Coverage reports and Trends graphs
Title: Message Title Falko Modler edited a comment on JENKINS-54038 Re: Jacoco creates multiple Coverage reports and Trends graphs As per pipeline-maven 3.5.15+, multi module coverage reports are _disabled_:- https://issues.jenkins-ci.org/browse/JENKINS-54139?focusedCommentId=351853=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-351853- https://github.com/jenkinsci/pipeline-maven-plugin/commit/75ce8e28539151ac35615655deb15d860a963c83#diff-00c89ee459a797b514c25cf81fa61585R131So instead of too many report reports you get, well, none!I am not sure how to solve this. I suppose you must now either merge the exec files and feed this into jacoco-plugin explicitly _or_ you have to generate your own report ([via the maven plugin|https://github.com/jacoco/jacoco/wiki/MavenMultiModule]) which you then _might_ be able to publish with [HTML Publisher Plugin|https://plugins.jenkins.io/htmlpublisher].Or "just" use SonarQube... 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-54038) Jacoco creates multiple Coverage reports and Trends graphs
Title: Message Title Falko Modler edited a comment on JENKINS-54038 Re: Jacoco creates multiple Coverage reports and Trends graphs As per pipeline-maven 3.5.15+, multi module coverage reports are _disabled_:- https://issues.jenkins-ci.org/browse/JENKINS-54139?focusedCommentId=351853=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-351853- https://github.com/jenkinsci/pipeline-maven-plugin/commit/75ce8e28539151ac35615655deb15d860a963c83#diff-00c89ee459a797b514c25cf81fa61585R131So instead of too many report you get, well, none!I am not sure how to solve this. I suppose you must now either merge the exec files and feed this into jacoco-plugin explicitly _or_ you have to generate your own report ([via the maven plugin|https://github.com/jacoco/jacoco/wiki/MavenMultiModule]) which you then _might_ be able to publish with [HTML Publisher Plugin|https://plugins.jenkins.io/htmlpublisher].Or " just " use SonarQube... 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-54038) Jacoco creates multiple Coverage reports and Trends graphs
Title: Message Title Falko Modler commented on JENKINS-54038 Re: Jacoco creates multiple Coverage reports and Trends graphs As per pipeline-maven 3.5.15+, multi module coverage reports are disabled: https://issues.jenkins-ci.org/browse/JENKINS-54139?focusedCommentId=351853=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-351853 https://github.com/jenkinsci/pipeline-maven-plugin/commit/75ce8e28539151ac35615655deb15d860a963c83#diff-00c89ee459a797b514c25cf81fa61585R131 So instead of too many report you get, well, none! I am not sure how to solve this. I suppose you must now either merge the exec files and feed this into jacoco-plugin explicitly or you have to generate your own report (via the maven plugin) which you then might be able to publish with HTML Publisher Plugin. Or just use SonarQube... 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-55890) RocketChat notification (using proxy) fails since version 1.3.1
Title: Message Title Falko Modler commented on JENKINS-55890 Re: RocketChat notification (using proxy) fails since version 1.3.1 PR sent: https://github.com/jenkinsci/rocketchatnotifier-plugin/pull/30 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-54541) Unreserve doesn't set environment variable
Title: Message Title Falko Modler commented on JENKINS-54541 Re: Unreserve doesn't set environment variable Thanks for the pointer, Niels Wegner! 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-54541) Unreserve doesn't set environment variable
Title: Message Title
Falko Modler edited a comment on JENKINS-54541
Re: Unreserve doesn't set environment variable
Same here, Jenkins ver. 2.138.2 and lockable-resources 2.3. This results in a failed build due to {{groovy.lang.MissingPropertyException: No such property: [...] for class: groovy.lang.Binding}} PS: First, I was irritated by [this closed GitHub ticket|https://github.com/jenkinsci/lockable-resources-plugin/issues/96] because I thought it was the same scenario, but it's not!That ticket adressed one build waiting for another (to free up the resource), but here we have a job waiting for a _manually reserved_ resource.
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-54541) Unreserve doesn't set environment variable
Title: Message Title Falko Modler commented on JENKINS-54541 Re: Unreserve doesn't set environment variable Same here, Jenkins ver. 2.138.2 and lockable-resources 2.3. PS: First, I was irritated by this closed GitHub ticket because I thought it was the same scenario, but it's not! That ticket adressed one build waiting for another (to free up the resource), but here we have a job waiting for a manually reserved resource. 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-54559) Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE)
Title: Message Title Falko Modler commented on JENKINS-54559 Re: Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE) Fix confirmed - thanks for your quick reaction, Cyrille Le Clerc! 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-54559) Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE)
Title: Message Title
Falko Modler edited a comment on JENKINS-54559
Re: Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE)
I think there is a misunderstanding. The block that you just enriched with log output has in deed indeed not changed semantically.I was just wondering whether you removed the call to {{archiver}} because you assumed JENKINS-43995 is done (which isn't the case).That's the only reason why I mentioned this lower block (:308 and below).The actual regression was introduced by the change of the upper block/line (:295). I tried to highlight the problem in this screenshot: !screenshot-1.png|thumbnail!
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-54559) Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE)
Title: Message Title Falko Modler commented on JENKINS-54559 Re: Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE) I think there is a misunderstanding. The block that you just enriched with log output has in deed not changed semantically. I was just wondering whether you removed the call to archiver because you assumed JENKINS-43995 is done (which isn't the case). That's the only reason why I mentioned this lower block (:308 and below). The actual regression was introduced by the change of the upper block/line (:295). I tried to highlight the problem in this screenshot: 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-54559) Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE)
Title: Message Title Falko Modler updated an issue Jenkins / JENKINS-54559 Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE) Change By: Falko Modler Attachment: screenshot-1.png 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-54559) Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE)
Title: Message Title
Falko Modler updated an issue
Jenkins / JENKINS-54559
Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE)
Change By:
Falko Modler
The removal of [this block |https://github.com/jenkinsci/pipeline-maven-plugin/commit/cfe37eeb66c07fc81c286f78499acfdef7aa05ec#diff-2b37dae22162f359b4bc1b4f1c45d897L295] block is causing a (temporary) inconsistent overall build result because {{archiver.perform()}} used to set {{currentBuild.result}} in 3.5.14 (see also [here|https://github.com/jenkinsci/junit-plugin/blob/master/src/main/java/hudson/tasks/junit/JUnitResultArchiver.java#L157]) but now (due to the removal) the result is not set anymore.This now leads to other plugins picking up the wrong result (SUCCESS) when being used in {{post}} pipeline blocks. We, for instance, explicitely call {{step([$class: 'StashNotifier'])}} in {{cleanup}} which before 3.5.15 sent the correct status to BitBucket PRs but now with 3.5.15 the PRs always receive SUCCESS/OK even though there are test failures. And of course if you evaluate {{currentBuild.result}} directly (like we also do to send messages via Rocket.Chat), you also see the wrong result.The final pipeline build result _is correct_ in these cases (UNSTABLE) but you just cannot retrieve it anymore from within the pipeline while it is still running.I consider this a severe breaking change.What puzzles me is that the very same commit that removed the invokation of {{archiver.perform()}} also remove removed this note (further down):{quote}// TODO: Once JENKINS-43995 lands, update this to set the step status instead of the entire build.{quote}Judging from it's status, JENKINS-43995 has *not* "landed" yet!
Add Comment
[JIRA] (JENKINS-54559) Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE)
Title: Message Title Falko Modler updated an issue Jenkins / JENKINS-54559 Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE) Change By: Falko Modler Issue Type: Improvement Bug 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-54559) Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE)
Title: Message Title Falko Modler created an issue Jenkins / JENKINS-54559 Build result regression since pipeline-maven 3.5.15 for failing tests (UNSTABLE) Issue Type: Improvement Assignee: Alvaro Lobato Components: pipeline-maven-plugin Created: 2018-11-09 16:59 Environment: Jenkins ver. 2.138.2 pipeline-maven 3.5.15 Priority: Critical Reporter: Falko Modler The removal of this block is causing a (temporary) inconsistent overall build result because archiver.perform() used to set currentBuild.result in 3.5.14 (see also here) but now (due to the removal) the result is not set anymore. This now leads to other plugins picking up the wrong result (SUCCESS) when being used in post pipeline blocks. We, for instance, explicitely call step([$class: 'StashNotifier']) in cleanup which before 3.5.15 sent the correct status to BitBucket PRs but now with 3.5.15 the PRs always receive SUCCESS/OK even though there are test failures. And of course if you evaluate currentBuild.result directly (like we also do to send messages via Rocket.Chat), you also see the wrong result. The final pipeline build result is correct in these cases (UNSTABLE) but you just cannot retrieve it anymore from within the pipeline while it is still running. I consider this a severe breaking change. What puzzles me is that the very same commit that removed the invokation of archiver.perform() also remove this note (further down): // TODO: Once JENKINS-43995 lands, update this to set the step status instead of the entire build. Judging from it's status, JENKINS-43995 has not "landed" yet!
[JIRA] (JENKINS-12575) Add option to sort JUNIT tests by date (currently ordered alphabetically)
Title: Message Title Falko Modler commented on JENKINS-12575 Re: Add option to sort JUNIT tests by date (currently ordered alphabetically) This problem is still present. 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-41929) Offer "Build with Parameters" on first build when declarative Jenkinsfile found
Title: Message Title
Falko Modler commented on JENKINS-41929
Re: Offer "Build with Parameters" on first build when declarative Jenkinsfile found
I am also affected by this:
Jenkinsfile from SCM
string parameter with defaultValue
value is accessed via ${params.[...]}
changed defaultValue is only picked up in the second build, not right away
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-50290) origin pr builds not treated as trusted
Title: Message Title
Falko Modler edited a comment on JENKINS-50290
Re: origin pr builds not treated as trusted
This is pretty much a blocker for us.If someone ([~stephenconnolly] ?) could point me in the right direction I'd take a stab at this. I am lost somewhere between {{BitbucketSCMSource.getTrustedRevision(SCMRevision, TaskListener)}} and {{OriginChangeRequestSCMHeadAuthority.checkTrusted(SCMSourceRequest, ChangeRequestSCMHead2)}}...
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-50290) origin pr builds not treated as trusted
Title: Message Title Falko Modler commented on JENKINS-50290 Re: origin pr builds not treated as trusted This is pretty much a blocker for us. If someone could point me in the right direction I'd take a stab at this. I am lost somewhere between BitbucketSCMSource.getTrustedRevision(SCMRevision, TaskListener) and OriginChangeRequestSCMHeadAuthority.checkTrusted(SCMSourceRequest, ChangeRequestSCMHead2)... 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-30308) Make it possible to use Job parameter as list of needed resources
Title: Message Title Falko Modler commented on JENKINS-30308 Re: Make it possible to use Job parameter as list of needed resources PR33 seems pretty popular. Count me in on that! Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-42073) Support sorting tags by taggerdate
Title: Message Title Falko Modler created an issue Jenkins / JENKINS-42073 Support sorting tags by taggerdate Issue Type: Improvement Assignee: Boguslaw Klimas Components: git-parameter-plugin Created: 2017/Feb/15 5:27 PM Priority: Minor Reporter: Falko Modler See http://www.nico.schottelius.org/blog/how-to-show-the-latest-git-tag/ Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
[JIRA] (JENKINS-38966) Rename job: No valid crumb was included in the request
Title: Message Title Falko Modler commented on JENKINS-38966 Re: Rename job: No valid crumb was included in the request Same here on 2.32.2 LTS. Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-15344) ClassCastException when reports are created with maven-site-plugin
Falko Modler commented on JENKINS-15344 ClassCastException when reports are created with maven-site-plugin Any updates? I just had to downgrade to maven-site-plugin 3.0. 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
[JIRA] (JENKINS-7666) ClassCastException parsing JUnit result
Falko Modler commented on JENKINS-7666 ClassCastException parsing JUnit result I tried patching Jenkins 1.471 as described in the blog article which did solve the DocumentFactory ClassCastException but another ClassCastException occured: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:98) at hudson.maven.Maven3Builder.call(Maven3Builder.java:64) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.ExceptionInInitializerError at edu.umd.cs.findbugs.DetectorFactoryCollection.getCoreResource(DetectorFactoryCollection.java:360) at edu.umd.cs.findbugs.SystemProperties.loadPropertiesFromConfigFile(SystemProperties.java:72) at edu.umd.cs.findbugs.SystemProperties.clinit(SystemProperties.java:55) at edu.umd.cs.findbugs.SortedBugCollection.clinit(SortedBugCollection.java:185) at hudson.plugins.findbugs.parser.FindBugsParser.readXml(FindBugsParser.java:262) at hudson.plugins.findbugs.parser.FindBugsParser.parse(FindBugsParser.java:206) at hudson.plugins.findbugs.parser.FindBugsParser.parse(FindBugsParser.java:143) at hudson.plugins.findbugs.parser.FindBugsParser.parse(FindBugsParser.java:103) at hudson.plugins.analysis.core.FilesParser.parseFile(FilesParser.java:358) at hudson.plugins.analysis.core.FilesParser.parseFiles(FilesParser.java:317) at hudson.plugins.analysis.core.FilesParser.invoke(FilesParser.java:266) at hudson.plugins.analysis.core.FilesParser.invoke(FilesParser.java:31) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.plugins.findbugs.FindBugsReporter.perform(FindBugsReporter.java:168) at hudson.plugins.analysis.core.HealthAwareReporter.postExecute(HealthAwareReporter.java:304) at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:421) at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:403) at com.t_systems_mms.reuse.maven.exec_listeners_extension.MojoTimeExecutionListener.mojoSucceeded(MojoTimeExecutionListener.java:130) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:87) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:228) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) ... 18 more Caused by: java.lang.ClassCastException: org.dom4j.tree.QNameCache cannot be cast to org.dom4j.tree.QNameCache at org.dom4j.QName.getCache(QName.java:253) at org.dom4j.QName.get(QName.java:86) at
[JIRA] (JENKINS-7666) ClassCastException parsing JUnit result
Falko Modler reopened JENKINS-7666 ClassCastException parsing JUnit result Today this problem occured in our site build. Jenkins version is: 1.471 See also (and the comments as well): http://www.beyondlinux.com/2011/04/20/running-sonar-in-jenkinshudson-org-dom4j-documentfactory-cannot-be-cast-to-org-dom4j-documentfactory/ Btw: We do not use sonar! So it seems it is not limited to sonar... Change By: Falko Modler (06/Jul/12 12:34 PM) Resolution: CannotReproduce Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
