Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
None
-
Jenkins 2.73.3 in Docker
pipeline-model-definition-plugin 1.2.3 (works) -> 1.2.4 (broken)
Description
Options block like this:
pipeline {
options {
disableConcurrentBuilds()
timeout(time: 30, unit: 'MINUTES')
}
(...)
}
disableConcurrentBuilds() now throws a Groovy exception at build time when Jenkins tries to compile the Jenkinsfile. Class cast error from @{} to Describable.
Probably related to this change:
Attachments
Issue Links
- is duplicated by
-
-
- Resolved
-
-
-
- Closed
-
- links to
Activity
| Field | Original Value | New Value |
|---|---|---|
| Priority | Critical [ 2 ] | Blocker [ 1 ] |
I can't reproduce this locally so far - can you include the full stacktrace and possibly a minimal Jenkinsfile that reproduces it? Thanks!
Sure, give me a few minutes I rolled back the changes (it broke our dev builds).
| Attachment | image-2017-11-20-14-05-25-123.png [ 40438 ] |
Here's the full plugin update list that I installed before I had to roll back. I can't duplicate right now as we need our dev server for awhile, but if you install these I'm pretty sure you'll repro.
Â
Bah, still can't reproduce it. I'll keep experimenting to try to reproduce it, but the full stacktrace would really be helpful.
hudson.remoting.ProxyException: org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object '{name=disableConcurrentBuilds, args={}}' with class 'java.util.LinkedHashMap' to class 'hudson.model.Describable' due to: groovy.lang.GroovyRuntimeException: Could not find matching constructor for: hudson.model.Describable(java.util.LinkedHashMap) at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnSAM(DefaultTypeTransformation.java:403) at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.continueCastOnNumber(DefaultTypeTransformation.java:319) at org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation.castToType(DefaultTypeTransformation.java:232) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.castToType(ScriptBytecodeAdapter.java:603) at org.jenkinsci.plugins.pipeline.modeldefinition.Utils$_instantiateList_closure6.doCall(Utils.groovy:445) 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.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022) at groovy.lang.Closure.call(Closure.java:414) at groovy.lang.Closure.call(Closure.java:430) at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2040) at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2025) at org.codehaus.groovy.runtime.DefaultGroovyMethods.each(DefaultGroovyMethods.java:2066) at com.cloudbees.groovy.cps.CpsDefaultGroovyMethods.each(CpsDefaultGroovyMethods.java:915) 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.groovy.runtime.metaclass.ReflectionMetaMethod.invoke(ReflectionMetaMethod.java:54) at org.codehaus.groovy.runtime.metaclass.NewInstanceMetaMethod.invoke(NewInstanceMetaMethod.java:56) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022) at org.codehaus.groovy.runtime.callsite.PojoMetaClassSite.call(PojoMetaClassSite.java:47) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) at org.jenkinsci.plugins.pipeline.modeldefinition.Utils.instantiateList(Utils.groovy:441) 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.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93) at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite$StaticMetaMethodSiteNoUnwrapNoCoerce.invoke(StaticMetaMethodSite.java:151) at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.callStatic(StaticMetaMethodSite.java:102) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallStatic(CallSiteArray.java:56) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:194) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callStatic(AbstractCallSite.java:214) at org.jenkinsci.plugins.pipeline.modeldefinition.Utils.updateJobProperties(Utils.groovy:471) at org.jenkinsci.plugins.pipeline.modeldefinition.Utils$updateJobProperties$8.call(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:19) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.executeProperties(jar:file:/var/jenkins_home/plugins/pipeline-model-definition/WEB-INF/lib/pipeline-model-definition.jar!/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy:620) at org.jenkinsci.plugins.pipeline.modeldefinition.ModelInterpreter.call(jar:file:/var/jenkins_home/plugins/pipeline-model-definition/WEB-INF/lib/pipeline-model-definition.jar!/org/jenkinsci/plugins/pipeline/modeldefinition/ModelInterpreter.groovy:65) at WorkflowScript.run(WorkflowScript:15) at ___cps.transform___(Native Method) at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82) at sun.reflect.GeneratedMethodAccessor243.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.get(PropertyishBlock.java:76) at com.cloudbees.groovy.cps.LValueBlock$GetAdapter.receive(LValueBlock.java:30) at com.cloudbees.groovy.cps.impl.PropertyishBlock$ContinuationImpl.fixName(PropertyishBlock.java:66) 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 com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) at com.cloudbees.groovy.cps.Next.step(Next.java:83) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163) at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122) at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:19) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:35) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:32) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108) at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:32) at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:330) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:82) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:242) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:230) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
This is pretty dang weird. I'm not yet sure how that map is getting that far - it should have been transformed well beforehand. Any chance you could set the system property org.jenkinsci.plugins.pipeline.modeldefinition.parser.ModelParser.astDebugLogging to true and run the build again? Then look in the Jenkins console logs for WARNING: Transformed runtime AST: - args: and grab me everything after that until the ConstantExpression etc lines stop and it goes back to normal Jenkins logging?
Wait a sec, the weirdness just gets deeper. Any chance you could go to the Jenkins script console (Manage Jenkins -> Script Console) and run
import org.jenkinsci.plugins.structs.SymbolLookup import org.jenkinsci.plugins.workflow.steps.StepDescriptor println SymbolLookup.get().findDescriptor(Describable.class, "disableConcurrentBuilds") println StepDescriptor.metaStepsOf("disableConcurrentBuilds")
and paste the output here?
Don't bother, I found at least one problem - the JIRA Steps plugin is...weirdly broken. Its jiraNewComponent and jiraNewVersion steps (and others that aren't reporting in quite the same way) are for some reason set up to be "metasteps", with no restriction on what they're metasteps of. What that means here is that any symbol (like "disableConcurrentBuilds") is treated as if it were a step! That's quite not good and is breaking Declarative's logic for determining what exactly a symbol like "disableConcurrentBuilds" really means. Sigh. I'll open a PR against JIRA Steps to fix that, but for now, if you can disable JIRA Steps, you'll be ok.
Ah, and I can work around the brokenness of JIRA Steps in Declarative. Working on that now.
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Status | In Progress [ 3 ] | In Review [ 10005 ] |
Change to Declarative that deals with the poorly configured steps that return true for isMetaStep() without any actual metastep arguments is up at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/221
| Remote Link | This issue links to "PR #221 (Web Link)" [ 18118 ] |
Wow that sounds pretty weird. Thanks for the investigation, I'll disable that plugin for now.
Jenkins really is plugin-cross-dependency hell isn't it?
| Component/s | jira-steps-plugin [ 21974 ] | |
| Component/s | workflow-step-api-plugin [ 21718 ] |
cc nrayapati - looks like your change https://github.com/jenkinsci/jira-steps-plugin/pull/53 for JENKINS-47948 broke a bunch of things - beyond just the Declarative issue here, I've verified that you can't use any metastep (like archiveArtifacts) if you have jira-steps 1.3.0 installed. I opened https://github.com/jenkinsci/jira-steps-plugin/pull/61 to get rid of the now pointless isMetaStep() returning true methods on your steps, but you need to address this ASAP.
abayer: I have merged your change in for the pull request that you have opened for isMetaStep() change, initially I copied it over from the core steps when I have started that plugin, looks like I carried it over to other steps as well.
I am going to dot release it soon.
I didn't get the other part? JENKINS-47948 change, what did it break? do you have any example code which has broken and by the way there were few non passive changes in it, I did mention it in the release notes.
abayer And I am wondering why isMetaStep() true change isn't causing any problems before? those steps were there since version 1.0.0 and with JENKINS-47943, I just deleted the deprecated objects those were deprecated long ago, so I don't think thats problem. I noticed from the screenshot that 1.2.3 version was working then those objects that I deleted were already deprecated in that version and also these steps were using isMetaStep ture all the time.
nrayapati Because before that change, you didn't have any cases of a step with isMetaStep()==true and a sole parameter of type Object.class. Now you do. =) i.e., https://github.com/jenkinsci/jira-steps-plugin/pull/53/files#diff-5fdac2c995ffb47d0b70de3b29aa2af7L33. Now, the places where you had isMetaStep()==true and a parameter of type String.class or the like isn't ideal, but probably wouldn't have had any actual effect, since no Describable inherits from them. But everything inherits from Object.class.
abayer Okay that makes sense then, and also I have added groovy-all as a compile time dependency, do you think that would be a problem? probably i will change that to provided dependency?
https://github.com/jenkinsci/jira-steps-plugin/blob/master/pom.xml#L187
Please advice if that is not a problem I will go ahead and dot release jira-steps
Okay groovy-all dependency doesn't seems to be a problem, as I have seen few other plugins has this as a compile time dependency and are using different versions. But looks like jenkins-core is on 2.4.11 so I will update to use 2.4.11 instead of 2.4.12. Thanks. Correct me if I am wrong here.
Yeah, you should be ok. It'll get overridden in practice when running in Jenkins by whatever Groovy version the core has.
dbsanfte
I have dot released jira-steps 1.3.1 http://repo.jenkins-ci.org/releases/org/jenkins-ci/plugins/jira-steps/1.3.1/ it should available for consumption soon.
Thanks for your inputs abayer Sorry for the inconvenience caused if any.
Have a happy holidays 
| Remote Link | This issue links to "PR61 (Web Link)" [ 18121 ] |
| Remote Link | This issue links to "PR61 (Web Link)" [ 18121 ] |
| Remote Link | This issue links to "JIRA Steps #61 (Web Link)" [ 18122 ] |
| Link |
This issue is duplicated by |
| Link |
This issue is duplicated by |
Ok, jira-steps and workflow-step-api fixes released, Declarative picking up that workflow-step-api change will be coming shortly, but isn't actually needed to unbreak things. =)
| Resolution | Fixed [ 1 ] | |
| Status | In Review [ 10005 ] | Resolved [ 5 ] |
Things are working again with the latest releases to the plugins. Thanks guys.
Code changed in jenkins
User: Andrew Bayer
Path:
pipeline-model-definition/pom.xml
pipeline-model-definition/src/main/groovy/org/jenkinsci/plugins/pipeline/modeldefinition/parser/ASTParserUtils.groovy
pipeline-model-definition/src/test/java/org/jenkinsci/plugins/pipeline/modeldefinition/OptionsTest.java
pipeline-model-definition/src/test/resources/disableConcurrentBuilds.groovy
pom.xml
http://jenkins-ci.org/commit/pipeline-model-definition-plugin/5a06b265938fcf49030336a0ce7bdbaa39c100ea
Log:
[FIXED JENKINS-48115] Work around badly configured metasteps
jira-steps has `isMetaStep()` returning true for all its step
descriptors, which is...wrong. As a result, literally every symbol has
at least one erstwhile metastep, breaking our logic for determining
whether we're looking at a function or a describable. Sigh. While this
should be fixed in jira-steps too, we should definitely be working
around the super-broad cases like this.
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Well, bugger. Lemme look.