[JIRA] (JENKINS-39742) Active Choice Plugin should honor ParameterDefinition serializability (was: Active Choice Plugin in Pipelines throw NotSerializableException)

2017-03-03 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-39742  
 
 
  Active Choice Plugin should honor ParameterDefinition serializability (was: Active Choice Plugin in Pipelines throw NotSerializableException)   
 

  
 
 
 
 

 
Change By: 
 Frédéric Chuong  
 

  
 
 
 
 

 
 Since upgrading to Pipeline: Active Choices Plug-in: 1.5.1 the Groovy script is no longer serializable and therefore throws NotSerializableException when input is requested.h3. Stacktrace{noformat}java.io.NotSerializableException: org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:860) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:967) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:569) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:65) at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:56) at org.jboss.marshalling.MarshallerObjectOutputStream.writeObjectOverride(MarshallerObjectOutputStream.java:50) at org.jboss.marshalling.river.RiverObjectOutputStream.writeObjectOverride(RiverObjectOutputStream.java:179) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344) at java.util.TreeMap.writeObject(TreeMap.java:2434) at sun.reflect.GeneratedMethodAccessor357.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at org.jboss.marshalling.reflect.SerializableClass.callWriteObject(SerializableClass.java:271) at 

[JIRA] (JENKINS-39742) Active Choice Plugin should honor ParameterDefinition serializability (was: Active Choice Plugin in Pipelines throw NotSerializableException)

2017-03-03 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-39742  
 
 
  Active Choice Plugin should honor ParameterDefinition serializability (was: Active Choice Plugin in Pipelines throw NotSerializableException)   
 

  
 
 
 
 

 
Change By: 
 Frédéric Chuong  
 
 
Summary: 
 Active Choice Plugin  should honor ParameterDefinition serializability (was: Active Choice Plugin  in Pipelines throw NotSerializableException )  
 
 
Labels: 
 active-choices pipeline  script-security  
 

  
 
 
 
 

 
 Since upgrading to Pipeline: Active Choices Plug-in: 1.5.1 the Groovy script is no longer serializable and therefore throws NotSerializableException when input is requested.h3. Stacktrace {noformat} java.io.NotSerializableException: org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:860) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:967) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:569) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1032) at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:988) at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:854) at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(BlockMarshaller.java:65) at org.jboss.marshalling.river.BlockMarshaller.writeObject(BlockMarshaller.java:56) at 

[JIRA] (JENKINS-39742) Active Choice Plugin in Pipelines throw NotSerializableException

2017-03-03 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong reopened an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Thanks Bruno P. Kinoshita, I'll update the issue details accordingly. As a first guess, the simplest approach (from the Active Choice Plugin point of view) would be checking with script-security maintainers to see whether SecureGroovyScript could be enhanced to implement Serializable. If that is possible, then it would be a matter of upgrading the script-security dependency to fix this issue.  
 

  
 
 
 
 

 
 Jenkins /  JENKINS-39742  
 
 
  Active Choice Plugin in Pipelines throw NotSerializableException   
 

  
 
 
 
 

 
Change By: 
 Frédéric Chuong  
 
 
Resolution: 
 Won't Fix  
 
 
Status: 
 Resolved Reopened  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)  
 
 

 
   
 

  
 
 

[JIRA] (JENKINS-39742) Active Choice Plugin in Pipelines throw NotSerializableException

2017-03-03 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong edited a comment on  JENKINS-39742  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Active Choice Plugin in Pipelines throw NotSerializableException   
 

  
 
 
 
 

 
 The problem seems more related to compliance to {{hudson.model.ParameterDefinition}} contract which implements {{Serializable}} instead of being specific to Pipelines:_active-choice-plugin_ parameter implementations contain a non-transient {{org.biouno.unochoice.model.GroovyScript}} field (when using Groovy script) which itself contain a non-transient *non- Serialiable Serializable * {{org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript}} field (as of {{script-security}} 1.27), breaking the whole "Serializable chain". A Pipeline script here merely assumes the parameter is compliant to the core "parameter" contract.Would it be a valid reason to re-open this issue (and maybe rename it to _Active Choice Plugin should honor ParameterDefinition serializability_)?In case there are DOM issues for the UI part, I guess another JIRA issue should be created.  
 

  
 
 
 
 

 
 
 

 
 
 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-39742) Active Choice Plugin in Pipelines throw NotSerializableException

2017-03-03 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-39742  
 
 
  Active Choice Plugin in Pipelines throw NotSerializableException   
 

  
 
 
 
 

 
Change By: 
 Frédéric Chuong  
 
 
Component/s: 
 script-security-plugin  
 

  
 
 
 
 

 
 
 

 
 
 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-39742) Active Choice Plugin in Pipelines throw NotSerializableException

2017-03-02 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong edited a comment on  JENKINS-39742  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Active Choice Plugin in Pipelines throw NotSerializableException   
 

  
 
 
 
 

 
 The problem seems more related to compliance to {{hudson.model.ParameterDefinition}} contract which implements {{Serializable}} instead of being specific to Pipelines:_active-choice-plugin_ parameter implementations contain a non-transient {{org.biouno.unochoice.model.GroovyScript}} field (when using Groovy script) which itself contain a non-transient *non-Serialiable* {{org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript}} field (as of {{script-security}} 1.27), breaking the whole "Serializable chain". A Pipeline script here merely assumes the parameter is compliant to the core "parameter" contract.Would it be a valid reason to re-open this issue  (and maybe rename it to _Active Choice Plugin should honor ParameterDefinition serializability_) ?In case there are DOM issues for the UI part, I guess another JIRA issue should be created.  
 

  
 
 
 
 

 
 
 

 
 
 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-39742) Active Choice Plugin in Pipelines throw NotSerializableException

2017-03-02 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong commented on  JENKINS-39742  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Active Choice Plugin in Pipelines throw NotSerializableException   
 

  
 
 
 
 

 
 The problem seems more related to compliance to hudson.model.ParameterDefinition contract which implements Serializable instead of being specific to Pipelines: active-choice-plugin parameter implementations contain a non-transient org.biouno.unochoice.model.GroovyScript field (when using Groovy script) which itself contain a non-transient non-Serialiable org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SecureGroovyScript field (as of script-security 1.27), breaking the whole "Serializable chain". A Pipeline script here merely assumes the parameter is compliant to the core "parameter" contract. Would it be a valid reason to re-open this issue? In case there are DOM issues for the UI part, I guess another JIRA issue should be created.  
 

  
 
 
 
 

 
 
 

 
 
 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-40732) Add closest modifiable ancestor LookupStrategy

2016-12-30 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-40732  
 
 
  Add closest modifiable ancestor LookupStrategy   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Daniel Spilker  
 
 
Components: 
 job-dsl-plugin  
 
 
Created: 
 2016/Dec/30 9:06 AM  
 
 
Environment: 
 job-dsl 1.53   
 
 
Labels: 
 job-dsl-plugin folders  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Frédéric Chuong  
 

  
 
 
 
 

 
 Given the following item hierarchy: 
 
Jenkins root 
 
ModifiableFolder (such as com.cloudbees.hudson.plugins.folder.Folder) 
 
ComputedFolder (such as org.jenkinsci.plugins.workflow.multibranch.WorkflowMultiBranchProject) 
 
JobDslAwareJob (such as org.jenkinsci.plugins.workflow.job.WorkflowJob with Jenkinsfile making use of the jobDsl pipeline DSL) 
  
  
  
 Without prior knowledge of ModifiableFolder, it is not 

[JIRA] (JENKINS-40732) Add closest modifiable ancestor LookupStrategy

2016-12-30 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-40732  
 
 
  Add closest modifiable ancestor LookupStrategy   
 

  
 
 
 
 

 
Change By: 
 Frédéric Chuong  
 
 
Environment: 
 Jenkins 2.19.x job-dsl 1.53   
 

  
 
 
 
 

 
 
 

 
 
 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-39362) Build test classpath is inconsistent: mockito-all clashes with hamcrest-core

2016-10-28 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-39362  
 
 
  Build test classpath is inconsistent: mockito-all clashes with hamcrest-core   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Oleg Nenashev  
 
 
Components: 
 promoted-builds-plugin  
 
 
Created: 
 2016/Oct/29 2:35 AM  
 
 
Environment: 
 promoted-builds-plugin f7589c3c3e76f357393c6431a6412f2bc1e55ee7  
 
 
Labels: 
 dependencies junit  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Frédéric Chuong  
 

  
 
 
 
 

 
 Trying to implement semantically improved unit test results in a runtime error: 

 

mvn test -Dtest=MatcherTest -Dconcurrency=1 -DtrimStackTrace=false
 

 

 
---
Test set: hudson.plugins.promoted_builds.MatcherTest
---
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.068 sec <<< FAILURE! - in hudson.plugins.promoted_builds.MatcherTest
test(hudson.plugins.promoted_builds.MatcherTest)  Time elapsed: 0.008 sec  <<< ERROR!
java.lang.NoSuchMethodError: org.hamcrest.Matcher.describeMismatch(Ljava/lang/Object;Lorg/hamcrest/Description;)V

[JIRA] (JENKINS-39342) Make the promoted-builds-plugin DSL extension for job-dsl-plugin extensible: Automatically Generated DSL

2016-10-28 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong assigned an issue to Oleg Nenashev  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-39342  
 
 
  Make the promoted-builds-plugin DSL extension for job-dsl-plugin extensible: Automatically Generated DSL   
 

  
 
 
 
 

 
Change By: 
 Frédéric Chuong  
 
 
Assignee: 
 Daniel Spilker Oleg Nenashev  
 

  
 
 
 
 

 
 
 

 
 
 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-39342) Make the promoted-builds-plugin DSL extension for job-dsl-plugin extensible: Automatically Generated DSL

2016-10-28 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-39342  
 
 
  Make the promoted-builds-plugin DSL extension for job-dsl-plugin extensible: Automatically Generated DSL   
 

  
 
 
 
 

 
Change By: 
 Frédéric Chuong  
 
 
Component/s: 
 job-dsl-plugin  
 

  
 
 
 
 

 
 
 

 
 
 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-39342) Make the promoted-builds-plugin DSL extension for job-dsl-plugin extensible: Automatically Generated DSL

2016-10-28 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-39342  
 
 
  Make the promoted-builds-plugin DSL extension for job-dsl-plugin extensible: Automatically Generated DSL   
 

  
 
 
 
 

 
Issue Type: 
  Improvement  
 
 
Assignee: 
 Daniel Spilker  
 
 
Components: 
 job-dsl-plugin, promoted-builds-plugin  
 
 
Created: 
 2016/Oct/28 6:12 AM  
 
 
Environment: 
 job-dsl-plugin 1.46  promoted-builds-plugin 2.27  
 
 
Labels: 
 job-dsl-plugin promoted-builds  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Frédéric Chuong  
 

  
 
 
 
 

 
 The current DSL extension is static and needs to be modified/improved whenever a new feature is added to promoted-builds-plugin. By the extensible nature of this plugin (it provides the PromotionCondition ExtensionPoint for third parties to implement), this makes the DSL extension requirement to be dynamic depending on available plugins ; this doesn't scale well with the current static DSL extension. job-dsl-plugin 1.46 introduced the Automatically Generated DSL feature to address this issue on job-dsl-plugin itself by the use of javaposse.jobdsl.dsl.ExtensibleContext / javaposse.jobdsl.dsl.ContextType at the DSL level (model introspection done by helpers such as javaposse.jobdsl.plugin.structs.DescribableContext). The promoted-builds-plugin DSL extension should make use of those DSL authoring tool to automatically discover available PromotionCondition.  
 

  
 
 
 
  

[JIRA] (JENKINS-34982) Add configure block in DSL for promotions

2016-10-25 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-34982  
 
 
  Add configure block in DSL for promotions   
 

  
 
 
 
 

 
Change By: 
 Frédéric Chuong  
 
 
Component/s: 
 job-dsl-plugin  
 

  
 
 
 
 

 
 
 

 
 
 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-34982) Add configure block in DSL for promotions

2016-10-25 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong commented on  JENKINS-34982  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Add configure block in DSL for promotions   
 

  
 
 
 
 

 
 FYI an experimental branch tried to rethink the design of the Job-DSL integration (and more generally address the scalability of the promoted-builds-plugin DSL) https://github.com/jenkinsci/promoted-builds-plugin/pull/96#issuecomment-255899713 : 

The driver for those changes is the scalability of the DSL extension when using the existing implementation: 
 
promoted-builds-plugin developers may not know how/when they also have to provide DSL integration to allow `job-dsl-plugin`. Eg: GroovyCondition is not covered by the DSL extension even though it is provided by the very same plugin. 
Third-party plugin developers wanting to extend promoted-builds-plugin (ie. wanting to provide custom PromotionCondition (which extends ExtensionPoint) for their own plugin) have to add binary dependency on promoted-builds-plugin to their own plugin because of the domain object to XML serialization approach (this creates a chicken-egg problem defeating the purpose of providing {{ExtensionPoint}}s). 
job-dsl-plugin users cannot manipulate the PromotionProcess XML to workaround lack of integration https://github.com/jenkinsci/job-dsl-plugin/wiki/The-Configure-Block 
 
Those issues all have a common impact: they prevent job-dsl-plugin users from being able to generate fine-tuned promotions as soon as the components they need is not implemented into the DSL extension. The proposed changes tries to adopt the https://github.com/jenkinsci/job-dsl-plugin/wiki/Automatically-Generated-DSL approach applied to this DSL extension to fix those issues. 
As for the implementation, it indeed needs to be improved/fixed at least for the reported issues
 The branch itself brings its share of issues (as reminded by plugin maintainer): binary compatibility and migration path. It could also use some advice from job-dsl-plugin maintainers for approval/endorsement purpose.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
   

[JIRA] (JENKINS-27916) GString not flattened to String by DSL inside a map

2016-06-24 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong commented on  JENKINS-27916  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: GString not flattened to String by DSL inside a map   
 

  
 
 
 
 

 
 In Groovy, you have to escape symbols for map literals keys: 

 

[(requiredFile): 'xxx']
 

 http://groovy-lang.org/groovy-dev-kit.html#_map_literals : 

Map keys are strings by default: [a:1] is equivalent to ['a':1]. This can be confusing if you define a variable named a and that you want the value of a to be the key in your map. If this is the case, then you must escape the key by adding parenthesis
 That means the workaround of using a GString as a key should not be needed  
 

  
 
 
 
 

 
 
 

 
 
 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-27927) Some interface idioms do not work in Groovy CPS

2016-06-24 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Frédéric Chuong commented on  JENKINS-27927  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Some interface idioms do not work in Groovy CPS   
 

  
 
 
 
 

 
 Upstream issue: https://github.com/cloudbees/groovy-cps/issues/26  
 

  
 
 
 
 

 
 
 

 
 
 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] [release-plugin] (JENKINS-32637) ReleaseWrapper should prevent parameter duplication when overrideBuildParameters is not set

2016-01-26 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Jenkins /  JENKINS-32637 
 
 
 
  ReleaseWrapper should prevent parameter duplication when overrideBuildParameters is not set  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 
 Peter Hayes 
 
 
 

Components:
 

 release-plugin 
 
 
 

Created:
 

 27/Jan/16 1:53 AM 
 
 
 

Environment:
 

 Release plugin 2.5.4 
 
 
 

Priority:
 
  Minor 
 
 
 

Reporter:
 
 Frédéric Chuong 
 
 
 
 
 
 
 
 
 
 
When overrideBuildParameters is not enabled, ReleaseWrapper does not attempt to filter default parameters that are also included in the Release configuration and blindly add new parameter regardless of whether a default parameter (from the regular job) has the same name, this results in release builds with confusing duplicated parameters 

 
if (isOverrideBuildParameters()) {
// if overrideBuildParameters is set, then build params are submitted
// within the list of release params -- no need to gather default values
paramValues = new ArrayList();
}
else {
 lack of filtering in regards to getParameterDefinitions()
paramValues = getDefaultParametersValues();
}

if (getParameterDefinitions() != null && !getParameterDefinitions().isEmpty()

[JIRA] [build-failure-analyzer-plugin] (JENKINS-32615) com.sonyericsson.jenkins.plugins.bfa.model.dbf.ParameterizedTriggerDBF uses wrong ClassLoader to detect hudson.plugins.parameterizedtrigger.Build

2016-01-25 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Jenkins /  JENKINS-32615 
 
 
 
  com.sonyericsson.jenkins.plugins.bfa.model.dbf.ParameterizedTriggerDBF uses wrong ClassLoader to detect hudson.plugins.parameterizedtrigger.BuildInfoExporterAction  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 
 Tomas Westling 
 
 
 

Components:
 

 build-failure-analyzer-plugin 
 
 
 

Created:
 

 26/Jan/16 7:18 AM 
 
 
 

Environment:
 

 Jenkins 1.625.3  Build Failure Analyzer 1.13.3  Parameterized Trigger plugin 2.30 
 
 
 

Labels:
 

 parameterized-trigger 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Frédéric Chuong 
 
 
 
 
 
 
 
 
 
 
com.sonyericsson.jenkins.plugins.bfa.model.dbf.ParameterizedTriggerDBF mentions We want to avoid having dependencies to other plugins thus using reflection., that means checking for hudson.plugins.parameterizedtrigger.BuildInfoExporterAction using the current classloader (Class.forName(className)) will never return anything since Jenkins isolate plugins classloaders. 
This causes the feature (extract failure from downstream) not to work and produces the following error to be logged: 
  

[JIRA] [job-dsl-plugin] (JENKINS-30010) Missing support for multiple conditions configuration in same flexible-publisher instance in job-dsl

2015-12-10 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong commented on  JENKINS-30010 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Missing support for multiple conditions configuration in same flexible-publisher instance in job-dsl  
 
 
 
 
 
 
 
 
 
 
Here is how you can monkeypatch the DSL to handle mutilple flexiblePublish() invocations which will results in multiple ConditionalPublisher instead of mutiple FlexiblePublisher: 

 

import javaposse.jobdsl.dsl.ContextHelper;
import javaposse.jobdsl.dsl.helpers.publisher.PublisherContext;
import javaposse.jobdsl.dsl.helpers.publisher.FlexiblePublisherContext;
import hudson.util.VersionNumber;
import groovy.util.NodeBuilder;
import com.thoughtworks.xstream.io.xml.XmlFriendlyNameCoder;
import static javaposse.jobdsl.dsl.Preconditions.checkArgument


PublisherContext.metaClass.flexiblePublish = { Closure flexiblePublishClosure ->

  jobManagement.logPluginDeprecationWarning('flexible-publish', '0.13')
  
  FlexiblePublisherContext context = new FlexiblePublisherContext(jobManagement, item)
  ContextHelper.executeInContext(flexiblePublishClosure, context)
  
  checkArgument(!context.actions.empty, 'no publisher or build step specified')
  
  Closure conditionalPublisher = {
'org.jenkins__ci.plugins.flexible__publish.ConditionalPublisher' {
  condition(class: context.condition.conditionClass) {
context.condition.addArgs(delegate)
  }
  if (jobManagement.getPluginVersion('flexible-publish')?.isOlderThan(new VersionNumber('0.13'))) {
publisher(
  class: new XmlFriendlyNameCoder().decodeAttribute(context.actions[0].name().toString()),
  context.actions[0].value()
)
  } else {
publisherList(context.actions)
  }
  runner(class: 'org.jenkins_ci.plugins.run_condition.BuildStepRunner$Fail')
}
  };
  def flexiblePublisherNode = publisherNodes.find {
it.name() == 'org.jenkins__ci.plugins.flexible__publish.FlexiblePublisher'
  };
  if (flexiblePublisherNode) {
flexiblePublisherNode.publishers[0].children().with {
  it[it.size() - 1]
}.plus(conditionalPublisher)
  } else {
publisherNodes << new NodeBuilder().'org.jenkins__ci.plugins.flexible__publish.FlexiblePublisher' {
  delegate.publishers conditionalPublisher
}
  }
} 

 
Insert that before your regular DSL (made against 1.39, don't know for 1.40). 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message 

[JIRA] [job-dsl-plugin] (JENKINS-31832) javaposse.jobdsl.dsl.Job is not a suitable parent class for javaposse.jobdsl.dsl.jobs.WorkflowJob (org.jenkinsci.plugins.workflow.job.WorkflowJob does not exten

2015-12-01 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Jenkins /  JENKINS-31832 
 
 
 
  javaposse.jobdsl.dsl.Job is not a suitable parent class for javaposse.jobdsl.dsl.jobs.WorkflowJob (org.jenkinsci.plugins.workflow.job.WorkflowJob does not extend hudson.model.AbstractProject)  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 
 Daniel Spilker 
 
 
 

Components:
 

 job-dsl-plugin 
 
 
 

Created:
 

 01/Dec/15 4:05 PM 
 
 
 

Environment:
 

 Jenkins 1.619  job-dsl-plugin 1.39  workflow-plugin 1.10 
 
 
 

Labels:
 

 job-dsl workflow 
 
 
 

Priority:
 
  Minor 
 
 
 

Reporter:
 
 Frédéric Chuong 
 
 
 
 
 
 
 
 
 
 
javaposse.jobdsl.dsl.jobs.WorkflowJob (which matches org.jenkinsci.plugins.workflow.job.WorkflowJob) extends javaposse.jobdsl.dsl.Job (which mainly matches hudson.model.AbstractProject) whereas hudson.model.AbstractProject is not a parent class of org.jenkinsci.plugins.workflow.job.WorkflowJob. That results in invalid configuration file being generated when using the javaposse.jobdsl.dsl.Job API combined with javaposse.jobdsl.dsl.DslFactory#workflowJob(java.lang.String, groovy.lang.Closure). That means we cannot trust the delegate type to select which customization 

[JIRA] [envinject-plugin] (JENKINS-31829) Evaluated Groovy script should expose the current hudson.model.TaskListener

2015-12-01 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Jenkins /  JENKINS-31829 
 
 
 
  Evaluated Groovy script should expose the current hudson.model.TaskListener  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Improvement 
 
 
 

Assignee:
 
 Oleg Nenashev 
 
 
 

Components:
 

 envinject-plugin 
 
 
 

Created:
 

 01/Dec/15 2:24 PM 
 
 
 

Environment:
 

 envinject-plugin 1.92.1 
 
 
 

Labels:
 

 envinject groovy 
 
 
 

Priority:
 
  Minor 
 
 
 

Reporter:
 
 Frédéric Chuong 
 
 
 
 
 
 
 
 
 
 
Evaluated Groovy script should expose the current hudson.model.TaskListener so that scripts implementers can invoke hudson.model.Run#getEnvironment(hudson.model.TaskListener) (with the actual value) instead of invoking the deprecated hudson.model.Run#getEnvironment() which was deprecated since Jenkins 1.305 (EnvInject currently requires Jenkins ≥ 1.532.3): 

 

/**
 * @deprecated as of 1.305 use {@link #getEnvironment(TaskListener)}
 */
public EnvVars getEnvironment() throws IOException, InterruptedException {
 
  

[JIRA] [job-dsl-plugin] (JENKINS-30010) Missing support for multiple conditions configuration in same flexible-publisher instance in job-dsl

2015-11-08 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong commented on  JENKINS-30010 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Missing support for multiple conditions configuration in same flexible-publisher instance in job-dsl  
 
 
 
 
 
 
 
 
 
 
Unfortunately you have to do it with XML style which makes that workaround not convenient. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





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


[JIRA] [job-dsl-plugin] (JENKINS-30010) Missing support for multiple conditions configuration in same flexible-publisher instance in job-dsl

2015-11-06 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong commented on  JENKINS-30010 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Missing support for multiple conditions configuration in same flexible-publisher instance in job-dsl  
 
 
 
 
 
 
 
 
 
 
XML approach workaround: 

 

  configure {
it / 'publishers' / 'org.jenkins__ci.plugins.flexible__publish.FlexiblePublisher' {
  'publishers' {
'org.jenkins__ci.plugins.flexible__publish.ConditionalPublisher' {
  condition {
currentNode['@class'] = 'org.jenkins_ci.plugins.run_condition.logic.And'
conditions {
  'org.jenkins__ci.plugins.run__condition.logic.ConditionContainer' {
condition {
  currentNode['@class'] = 'ConditionClass_A'
  // stuff for ConditionClass_A
}
  }
  'org.jenkins__ci.plugins.run__condition.logic.ConditionContainer' {
condition {
  currentNode['@class'] = 'ConditionClass_B'
  // stuff for ConditionClass_B
}
  }
}
  }
  publisherList {
'Publisher_1' {
  // stuff for Publisher_1
}
  }
}
'org.jenkins__ci.plugins.flexible__publish.ConditionalPublisher' {
  // repeat as needed
  condition {}
  publisherList {}
}
  }
}
  }
 

 
but this is very error prone (and you may get ConcurrentModificationException from DSL conflicts) which may be difficult to drill down. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





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


[JIRA] [job-dsl-plugin] (JENKINS-30010) Missing support for multiple conditions configuration in same flexible-publisher instance in job-dsl

2015-11-06 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Jenkins /  JENKINS-30010 
 
 
 
  Missing support for multiple conditions configuration in same flexible-publisher instance in job-dsl  
 
 
 
 
 
 
 
 
 

Change By:
 
 Frédéric Chuong 
 
 
 

Labels:
 
 flexible-publish 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





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


[JIRA] [release-plugin] (JENKINS-31159) Release post build steps for Matrix project cannot be set from UI

2015-11-02 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong commented on  JENKINS-31159 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Release post build steps for Matrix project cannot be set from UI  
 
 
 
 
 
 
 
 
 
 
Thanks for accepting the pull request, the problem is now gone with 2.5.4. 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





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


[JIRA] [flexible-publish-plugin] (JENKINS-31229) Flexible publisher does not properly consider 'dynamic' RunCondition for MatrixBuild aggregation

2015-10-28 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Jenkins /  JENKINS-31229 
 
 
 
  Flexible publisher does not properly consider 'dynamic' RunCondition for MatrixBuild aggregation  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 
 bap 
 
 
 

Components:
 

 flexible-publish-plugin 
 
 
 

Created:
 

 28/Oct/15 1:31 PM 
 
 
 

Environment:
 

 Jenkins 1.619  flexible-publisher 0.15.2 
 
 
 

Labels:
 

 flexible-publish run-condition matrix 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Frédéric Chuong 
 
 
 
 
 
 
 
 
 
 
For MatrixProject, aggregation conditions seems to be only evaluated during the initial org.jenkins_ci.plugins.flexible_publish.FlexiblePublisher.createAggregator(MatrixBuild, Launcher, BuildListener) call. That is fine for static conditions (such as org.jenkins_ci.plugins.run_condition.common.PrebuildSameAsPerformRunCondition hierarchy) but that does not allow 'dynamic' conditions to behave as expected: the associated publishers will be executed if the initial state of the build met the condition, regardless of the dynamic nature of the build (which may have invalidated the RunCondition after createAggretator()) 
  

[JIRA] [release-plugin] (JENKINS-31159) Release post build steps for Matrix project cannot be set from UI

2015-10-26 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong created an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Jenkins /  JENKINS-31159 
 
 
 
  Release post build steps for Matrix project cannot be set from UI  
 
 
 
 
 
 
 
 
 

Issue Type:
 
  Bug 
 
 
 

Assignee:
 
 Peter Hayes 
 
 
 

Components:
 

 release-plugin 
 
 
 

Created:
 

 26/Oct/15 6:37 AM 
 
 
 

Environment:
 

 Jenkins 1.619  release-plugin 2.5.3 
 
 
 

Labels:
 

 release-plugin jelly matrix 
 
 
 

Priority:
 
  Major 
 
 
 

Reporter:
 
 Frédéric Chuong 
 
 
 
 
 
 
 
 
 
 
Assigning release build steps to After failed or successful release build and all matrix configurations is impossible from Jelly UI because of code duplication in src/main/resources/hudson/plugins/release/ReleaseWrapper/config.jelly 2.5.3: 
Line 105 

 

		
		"attach-previous">${%After failed or successful release build}
		"postBuildSteps" hasHeader="true"
		 descriptors="${h2.getBuildSteps(it)}"
		 items="${instance.postBuildSteps}"
		 addCaption="${%Add release 

[JIRA] [release-plugin] (JENKINS-31159) Release post build steps for Matrix project cannot be set from UI

2015-10-26 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong updated an issue 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 Jenkins /  JENKINS-31159 
 
 
 
  Release post build steps for Matrix project cannot be set from UI  
 
 
 
 
 
 
 
 
 

Change By:
 
 Frédéric Chuong 
 
 
 
 
 
 
 
 
 
 Assigning release build steps to _After failed or successful release build and all matrix configurations_ is impossible from Jelly UI because of code duplication in {{src/main/resources/hudson/plugins/release/ReleaseWrapper/config.jelly}} 2.5.3:Line 105{code:xml}  ${%After failed or successful release build} {code}is duplicated at line 160:{code:xml}  ${%After failed or successful release build and all matrix configurations} {code}whereas it should use {{postMatrixBuildSteps}} instead of {{postBuildSteps}} .  This results in the _post build steps_ steps to be duplicated each time the page is saved. The only workaround is NOT to rely on Jenkins Jelly UI to configure such job (XML editing / Jenkins API) . 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop 

[JIRA] [workflow-plugin] (JENKINS-26481) Mishandling of binary methods accepting Closure

2015-09-23 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong commented on  JENKINS-26481 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Mishandling of binary methods accepting Closure  
 
 
 
 
 
 
 
 
 
 
workflow-plugin 1.10, using @com.cloudbees.groovy.cps.NonCPS does produce the expected output (when combined with synchronous steps such as org.jenkinsci.plugins.workflow.steps.EchoStep.Execution) as a workaround to groovy-cps #9. 

 

@com.cloudbees.groovy.cps.NonCPS
def foo1() {
  [1, 2, 3].each {
println it
  }
}

@com.cloudbees.groovy.cps.NonCPS
def foo2() {
  println "abc".replaceAll(/[a-z]/) {
it.toUpperCase()
  }
}

node {
  foo1()
  foo2()
}
 

 

 

Started by user anonymous
Running: Allocate node : Start
Running on master in xxx
Running: Allocate node : Body : Start
Running: Print Message
1
Running: Print Message
2
Running: Print Message
3
Running: Print Message
ABC
Running: Allocate node : Body : End
Running: Allocate node : End
Running: End of Workflow
Finished: SUCCESS
 

 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





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


[JIRA] [workflow-plugin] (JENKINS-26481) Mishandling of binary methods accepting Closure

2015-09-23 Thread frederic.chu...@gmail.com (JIRA)
Title: Message Title
 
 
 
 
 
 
 
 
 
 
  
 
 Frédéric Chuong commented on  JENKINS-26481 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
  Re: Mishandling of binary methods accepting Closure  
 
 
 
 
 
 
 
 
 
 
Yes, which is why synchronous steps were mentioned when using @NonCPS as the current implementation already fails with basic Groovy: 

 

@com.cloudbees.groovy.cps.NonCPS
def doAssertNoCPS() {
  // no error when CPS disabled
  assert [1, 2, 3].collect { it } == [1, 2, 3]
}
def doAssertCPS() {
  // fails because CPS transformation results in '4'
  assert [4, 5, 6].collect { it } == [4, 5, 6]
}

doAssertNoCPS()
doAssertCPS()
 

 
To be more relevant with current issue, it prevents such direct Groovy approach: 

 

// won't retrieve parameter value as result of 'find' is inconsistent
currentBuild.rawBuild.getAction(hudson.model.ParametersAction).parameters.find { it.name == 'FOO' }.value
 

 
 
 
 
 
 
 
 
 
 
 
 
 

 
 Add Comment 
 
 
 
 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 

 This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) 
 
 
 
 
  
 
 
 
 
 
 
 
 
   





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