[JIRA] (JENKINS-51441) "Replay" doesn't work if declarative pipeline crashes: "execution did not yet start"

2018-08-08 Thread christian.vonrueti+jenk...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Christian V commented on  JENKINS-51441  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: "Replay" doesn't work if declarative pipeline crashes: "execution did not yet start"   
 

  
 
 
 
 

 
 So, if I use Replay, modify the build script, accidentally introduce a syntax error, run the modified replay, I lose my work? I can understand if it's a current limitation of the replay system, that's fine with me, maybe this should be a feature request then instead.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-51441) "Replay" doesn't work if declarative pipeline crashes: "execution did not yet start"

2018-05-20 Thread christian.vonrueti+jenk...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Christian V created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-51441  
 
 
  "Replay" doesn't work if declarative pipeline crashes: "execution did not yet start"   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Attachments: 
 image-2018-05-20-14-17-47-466.png  
 
 
Components: 
 pipeline  
 
 
Created: 
 2018-05-20 12:17  
 
 
Environment: 
 Windows, Subversion, declarative pipeline  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Christian V  
 

  
 
 
 
 

 
 When any of my declarative pipelines crash due to a syntax error or an incorrect step invocation, "replay" doesn't work:   

 

WARNING: Error fetching execution for replay
java.io.IOException: Documentation #20 did not yet start
at org.jenkinsci.plugins.workflow.job.WorkflowRun$Owner.get(WorkflowRun.java:1104)
at org.jenkinsci.plugins.workflow.cps.replay.ReplayAction.getExecutionBlocking(ReplayAction.java:126)
at org.jenkinsci.plugins.workflow.cps.replay.ReplayAction.isReplayableSandboxTest(ReplayAction.java:166)
at sun.reflect.GeneratedMethodAccessor3014.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125)
at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314)
at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185)
at org.apache.commons.jexl.parser.ASTIdentifie

[JIRA] (JENKINS-50199) Failed pipeline jobs stuck running after incorrect resume

2018-05-19 Thread christian.vonrueti+jenk...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Christian V commented on  JENKINS-50199  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Failed pipeline jobs stuck running after incorrect resume   
 

  
 
 
 
 

 
 Here are the contents of the log file after the last successful build step (findbugs):   

 

[FINDBUGS] Computing warning deltas based on reference build #379
 [8mha:4HijrKHZ7mkGmdh75hYMWnTg3qhyKH/0crRFeYRzrFm+aB+LCP9b85aBtbiIwTG/KF0vKzUvOzOvODlTryCnNB3I0ivPL8pOy8kv18vKT9JLzs8rzs9J1QuHCgaV5jlDhPzyS1IZIICRiYGhoohBKqM0pTg/D64Hh8ICAFt0h+h/ [0m[Pipeline] }
 [8mha:4HijrKHZ7mkGmdh75hYMWnTg3qhyKH/0crRFeYRzrFm+aB+LCP9b85aBtbiIwTG/KF0vKzUvOzOvODlTryCnNB3I0ivPL8pOy8kv18vKT9JLzs8rzs9J1QuHCgaV5jlDhPzyS1IZIICRiYGhoohBKqM0pTg/D64Hh8ICAFt0h+h/ [0m[Pipeline] // stage
 [8mha:4HijrKHZ7mkGmdh75hYMWnTg3qhyKH/0crRFeYRzrFm+aB+LCP9b85aBtbiIwTG/KF0vKzUvOzOvODlTryCnNB3I0ivPL8pOy8kv18vKT9JLzs8rzs9J1QuHCgaV5jlDhPzyS1IZIICRiYGhoohBKqM0pTg/D64Hh8ICAFt0h+h/ [0m[Pipeline] }
 [8mha:4HijrKHZ7mkGmdh75hYMWnTg3qhyKH/0crRFeYRzrFm+aB+LCP9b85aBtbiIwTG/KF0vKzUvOzOvODlTryCnNB3I0ivPL8pOy8kv18vKT9JLzs8rzs9J1QuHCgaV5jlDhPzyS1IZIICRiYGhoohBKqM0pTg/D64Hh8ICAFt0h+h/ [0m[Pipeline] // withEnv
 [8mha:4HijrKHZ7mkGmdh75hYMWnTg3qhyKH/0crRFeYRzrFm+aB+LCP9b85aBtbiIwTG/KF0vKzUvOzOvODlTryCnNB3I0ivPL8pOy8kv18vKT9JLzs8rzs9J1QuHCgaV5jlDhPzyS1IZIICRiYGhoohBKqM0pTg/D64Hh8ICAFt0h+h/ [0m[Pipeline] }
 [8mha:4HijrKHZ7mkGmdh75hYMWnTg3qhyKH/0crRFeYRzrFm+aB+LCP9b85aBtbiIwTG/KF0vKzUvOzOvODlTryCnNB3I0ivPL8pOy8kv18vKT9JLzs8rzs9J1QuHCgaV5jlDhPzyS1IZIICRiYGhoohBKqM0pTg/D64Hh8ICAFt0h+h/ [0m[Pipeline] // node
Aborted by  [8mha:4CCuiaL4WcqYxDmSFZCzdJeS5EDzittu/+y5aEfwI3pHmR+LCP9b85aBtbiIQTGjNKU4P08vOT+vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihhk0NSjKDWzXb3RdlLBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUNodHsLgAz2EgZe/dLi1CL90rzsvPzyPAATbMabwg== [0munknown
Aborted by  [8mha:4CCuiaL4WcqYxDmSFZCzdJeS5EDzittu/+y5aEfwI3pHmR+LCP9b85aBtbiIQTGjNKU4P08vOT+vOD8nVc83PyU1x6OyILUoJzMv2y+/JJUBAhiZGBgqihhk0NSjKDWzXb3RdlLBUSYGJk8GtpzUvPSSDB8G5tKinBIGIZ+sxLJE/ZzEvHT94JKizLx0a6BxUmjGOUNodHsLgAz2EgZe/dLi1CL90rzsvPzyPAATbMabwg== [0munknown
 [8mha:4AbMXzlrx4Nu9/bUEGTqZys67oL8ln9itw4ppRv/RwtBBh+LCP9djL1OwzAURm9SwYwYERsz10mhPyrqRCVAqqBS4AHS1nWcGNvY17QsfQheAxYkXoGH4AXYmBlYCM0E33LOcr7nT9jyDkbGCSy5rqT2M4lWBVEbLo2rFsos0QdrjSP0xK1HqW0gnFxl1+cPljsldXVpiO+8t16/et8fMURjaAWnCHbHZX6fM5VrwTJyUouTlYP9Isy90Tgz2hvF8c9Ld/j0Mny0bzHEF7CtuBZUNHd3sIaozvf+5acNf2NoFsUAK1sLEkQHBKOCyA4YSxPstbHbxzQ9HnQ6ScpKM2VnN9mG5IKuNiaCP1xIPZ8G4dlRP2HE3e0Pbpyu7CsBAAA= [0mClick here to forcibly terminate running steps
 [8mha:4AbMXzlrx4Nu9/bUEGTqZys67oL8ln9itw4ppRv/RwtBBh+LCP9djL1OwzAURm9SwYwYERsz10mhPyrqRCVAqqBS4AHS1nWcGNvY17QsfQheAxYkXoGH4AXYmBlYCM0E33LOcr7nT9jyDkbGCSy5rqT2M4lWBVEbLo2rFsos0QdrjSP0xK1HqW0gnFxl1+cPljsldXVpiO+8t16/et8fMURjaAWnCHbHZX6fM5VrwTJyUouTlYP9Isy90Tgz2hvF8c9Ld/j0Mny0bzHEF7CtuBZUNHd3sIaozvf+5acNf2NoFsUAK1sLEkQHBKOCyA4YSxPstbHbxzQ9HnQ6ScpKM2VnN9mG5IKuNiaCP1xIPZ8G4dlRP2HE3e0Pbpyu7CsBAAA= [0mClick here to forcibly terminate running steps
Ready to run at Fri May 18 11:36:47 CEST 2018
Resuming build at Fri May 18 11:36:47 CEST 2018 after Jenkins restart
Ready to run at Fri May 18 11:54:24 CEST 2018
Resuming build at Fri May 18 11:54:24 CEST 2018 after Jenkins restart
Ready to run at Fri May 18 13:36:18 CEST 2018
Resuming build at Fri May 18 13:36:18 CEST 2018 after Jenkins restart
Aborted by  [8mha:4CCuiaL4WcqYxDmSFZCzdJeS5EDzittu/+y5a

[JIRA] (JENKINS-50199) Failed pipeline jobs stuck running after incorrect resume

2018-05-19 Thread christian.vonrueti+jenk...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Christian V commented on  JENKINS-50199  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Failed pipeline jobs stuck running after incorrect resume   
 

  
 
 
 
 

 
 I'm also seeing this: 

 

org.jenkinsci.remoting.util.ExecutorServiceUtils$FatalRejectedExecutionException: Cannot execute the command java.util.concurrent.FutureTask@134626b. The executor service is shutting down

at hudson.remoting.SingleLaneExecutorService.execute(SingleLaneExecutorService.java:108)

at java.util.concurrent.AbstractExecutorService.submit(Unknown Source)

at com.google.common.util.concurrent.ForwardingExecutorService.submit(ForwardingExecutorService.java:110)

at jenkins.util.InterceptingExecutorService.submit(InterceptingExecutorService.java:49)

at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$4.onSuccess(CpsFlowExecution.java:903)

at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution$4.onSuccess(CpsFlowExecution.java:899)

at org.jenkinsci.plugins.workflow.support.concurrent.Futures$1.run(Futures.java:150)

at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:253)

at com.google.common.util.concurrent.ExecutionList$RunnableExecutorPair.execute(ExecutionList.java:149)

at com.google.common.util.concurrent.ExecutionList.add(ExecutionList.java:105)

at com.google.common.util.concurrent.AbstractFuture.addListener(AbstractFuture.java:155)

at org.jenkinsci.plugins.workflow.support.concurrent.Futures.addCallback(Futures.java:160)

at org.jenkinsci.plugins.workflow.support.concurrent.Futures.addCallback(Futures.java:90)

at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.runInCpsVmThread(CpsFlowExecution.java:899)

at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.getCurrentExecutions(CpsFlowExecution.java:977)

at org.jenkinsci.plugins.workflow.flow.FlowExecutionList$ItemListenerImpl.onLoaded(FlowExecutionList.java:180)

at jenkins.model.Jenkins.(Jenkins.java:972)

at hudson.model.Hudson.(Hudson.java:85)

at hudson.model.Hudson.(Hudson.java:81)

at hudson.WebAppMain$3.run(WebAppMain.java:233) 

   I have updated to the latest Jenkins version and all my Pipeline plugins are up to date. This happened before the update, after the plugin updates, and after updating Jenkins. It's always the same exception.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
  

[JIRA] (JENKINS-44142) Step jobDsl can be used at most once in pipeline with DELETE

2018-05-18 Thread christian.vonrueti+jenk...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Christian V commented on  JENKINS-44142  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Step jobDsl can be used at most once in pipeline with DELETE   
 

  
 
 
 
 

 
 Hmm, Generated*BuildActions also contain the lookup strategy. One would have to have up to two actions per type, one per possible strategy.   Then, JENKINS-29784 should also be solved, hopefully.  
 

  
 
 
 
 

 
 
 

 
 
 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-44142) Step jobDsl can be used at most once in pipeline with DELETE

2018-05-18 Thread christian.vonrueti+jenk...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Christian V edited a comment on  JENKINS-44142  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Step jobDsl can be used at most once in pipeline with DELETE   
 

  
 
 
 
 

 
 Hmm, Generated*BuildActions also  contain  contains  the lookup strategy. One would have to have up to two actions per type, one per possible strategy. Then, JENKINS-29784 should also be solved, hopefully.  
 

  
 
 
 
 

 
 
 

 
 
 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-44142) Step jobDsl can be used at most once in pipeline with DELETE

2018-05-18 Thread christian.vonrueti+jenk...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Christian V commented on  JENKINS-44142  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Step jobDsl can be used at most once in pipeline with DELETE   
 

  
 
 
 
 

 
 I've taken another look at this. When multiple job-dsl scripts are run, job-dsl will attach multiple "actions" to the build. The current code seems to assume that there is only a single one.   To find the last generated objects, it's probably a simple change, maybe something like this:     

 

Set findLastGeneratedObjects() {
for (Run run = job.lastBuild; run != null; run = run.previousBuild) {
// We need to fetch all actions because job-dsl could habe been run multiple times in a single build.

// Previously, it would use the first build, whose first buildAction's modifiedObjects was set
// Now, it chooses the first build, where at least one buildAction's modifiedObjects is set
List actions = run.getActions(buildActionClass)
Set result = []
boolean useThisResult = false
for (B action : actions) {
if (action.modifiedObjects != null) {
useThisResult = true
result += action.modifiedObjects
}
}

if (useThisResult) {
return result
}
}
[]
}
 

 Further, job-dsl needs to be made aware of previous invocations during the same build run.   Currently, it compares the "new items" against the items items from the first suitable previous run. Here's a simple idea: 

 

GeneratedItems generatedItems = dslScriptLoader.runScripts(scriptRequests);
mergeWithCurrentRun(generatedItems, run); // <-- this would be the only change
Set freshJobs = generatedItems.getJobs();
Set freshViews = generatedItems.getViews();
Set freshConfigFiles = generatedItems.getConfigFiles();
Set freshUserContents = generatedItems.getUserContents(); 

   One could simply pretend that a subsequent invocation also "generated" the items that were generated previously in the same run.   The last invocation's log output would then summarize everything that job-dsl did.   Finally, one could check whether a build action is already appened to the current run and replace it it instead, instead of unconditionally doing run.addAction:   

 

// Save onto Builder, which belongs to a Project.
run.addAction(new GeneratedJobsBuildAction(freshJobs, getLookupStrategy()));
run.addAction(new GeneratedViewsBuildAction(freshViews, getLookupStrategy()));
run.addAction(new GeneratedConfigFilesBuildAction(freshConfigFiles));
run.addAction(new GeneratedUserContentsBuildAction(freshUserContents)); 

   This might affect JENKINS-29784   Daniel Spilker Thoughts?    
 

  
 
  

[JIRA] (JENKINS-44128) Pass custom parameters to job-dsl via pipeline step jobDsl

2018-05-05 Thread christian.vonrueti+jenk...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Christian V commented on  JENKINS-44128  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Pass custom parameters to job-dsl via pipeline step jobDsl   
 

  
 
 
 
 

 
 Aaron Marasco It's also documented here: https://github.com/jenkinsci/job-dsl-plugin/wiki/User-Power-Moves#use-job-dsl-in-pipeline-scripts  
 

  
 
 
 
 

 
 
 

 
 
 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-42565) mavenSettingsFilePath doesn't resolve relative paths to $WORKSPACE

2017-03-08 Thread christian.vonrueti+jenk...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Christian V created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-42565  
 
 
  mavenSettingsFilePath doesn't resolve relative paths to $WORKSPACE   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Alvaro Lobato  
 
 
Components: 
 pipeline-maven-plugin  
 
 
Created: 
 2017/Mar/08 8:41 AM  
 
 
Environment: 
 2.47, Windows  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Christian V  
 

  
 
 
 
 

 
 The documentation says: Maven Settings File Path (mavenSettingsFilePath): Specify a Maven settings.xml file. The specified path can be absolute or relative to the workspace. However, the settings file in my workspace is only used if I use an absolute path: 

 

mavenSettingsFilePath: '$WORKSPACE/settings.xml'
 

 Without $WORKSPACE/, it fails with: 

 
Setting up settings file settings.xml
[Pipeline] // withMaven
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: Could not find file 'settings.xml' on the build agent nor the master
Finished: FAILURE