-
Bug
-
Resolution: Not A Defect
-
Major
The following shared library class:
package org.test; class X implements Serializable { String toString() { "X" } }
used in a Jenkinsfile like:
def x = new org.test.X() echo "${x}"
will not result in any output. The output wont even show the echo step.
However
def x = new org.test.X() echo "${x.toString()}"
will work as expected
- relates to
-
-
- Resolved
-
- links to
[JENKINS-45904] toString method in shared library class not correctly resolved
I've got a test reproducing this in https://github.com/cloudbees/groovy-cps/pull/66 - no fix yet, but I wanted to get the reproduction case up there in case someone else takes a run at this before I find a fix.
Not a defect. An @Override of a method defined in a binary supertype must also be marked @NonCPS. Docs
jglick Thanks for the link. I tried really hard to search for this case before submitting this issue but it is (almost?) impossible to find this information.
Would it be possible to move this to a more prominent place such as https://jenkins.io/doc/book/pipeline/shared-libraries/ or https://jenkins.io/doc/book/pipeline/shared-libraries/ ?
This is probably not a good place to vent but I'm wondering why Jenkinsfiles actually use the CPS transformation at all. Almost every frustration I had with Jenkinsfiles is caused by this and it tarnishes an otherwise great feature.
Philipp Moeller
added a comment - - edited jglick Thanks for the link. I tried really hard to search for this case before submitting this issue but it is (almost?) impossible to find this information.
Would it be possible to move this to a more prominent place such as https://jenkins.io/doc/book/pipeline/shared-libraries/ or https://jenkins.io/doc/book/pipeline/shared-libraries/ ?
This is probably not a good place to vent but I'm wondering why Jenkinsfiles actually use the CPS transformation at all. Almost every frustration I had with Jenkinsfiles is caused by this and it tarnishes an otherwise great feature. CPS transformation's history is...a thing. Basically, we had to do something weird to be able to achieve durability, and for reasons lost to the winds of time, we went with transforming Groovy into continuation passing style. At this point, it'd almost certainly be more work than it'd be worth to switch to some other approach that still gave us the durability we need, and any alternative approach would probably have similar limitations as well. Sadly.
pmr feel free to vote on JENKINS-33761. The issues are very well known already, as are potential alternatives, so comments are not really needed.
Smells similar to
JENKINS-45982- it's another problem where we're getting a CpsCallableInvocation where we probably shouldn't. Specifically here it's the coercion to a String (presumably via the CPS-transformed toString method) that is for some reason throwing a CpsCallableInvocation. My guess is that it's somehow ending up going through a non-CPS transformed context...