-
Bug
-
Resolution: Fixed
-
Blocker
-
None
-
Jenkins 2.73.3 in Docker
pipeline-model-definition-plugin 1.2.3 (works) -> 1.2.4 (broken)
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:
- is duplicated by
-
-
- Resolved
-
-
-
- Closed
-
- links to
[JENKINS-48115] disableConcurrentBuilds() within an options block is now broken, throws Groovy exception during Jenkinsfile parsing
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 
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. =)
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.
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.