-
Bug
-
Resolution: Fixed
-
Major
-
Jenkins 2.176.2 with minimal plugins to execute pipeline shared libraries (git, pipeline, pipeline shared libs).
-
-
workflow-cps 2.75
We found a change that prints an annoying warning about the CPS mismatch during running the MPL module: https://github.com/griddynamics/mpl/issues/31
Running on Jenkins in /var/jenkins_home/workspace/mpl-master [Pipeline] { [Pipeline] stage [Pipeline] { (Checkout) [Pipeline] fileExists expected to call org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.evaluate but wound up catching Checkout.run; see: https://jenkins.io/redirect/pipeline-cps-method-mismatches/
We're not quite sure how to fix that in the library, but realized that the issue is related to the change JENKINS-31314 introduced in workflow-cps-2.71.
Reproduce is quite simple - just need to install the minimal latest jenkins, add required git & shared lib plugins, attach mpl library from github and create a simple jenkins job to build the mpl. It will fail (no Maven 3 tool) - but will show the issue during each module start.
Who could help with determining the actual cause and how to fix that?
- is caused by
-
-
- Resolved
-
- links to
[JENKINS-58620] expected to call CpsGroovyShell.evaluate but wound up catching <something>.run
Hi jglick, ok I got it - if it's not about security, but about a simple example to show that we need an exception in the warning logic: I tested with turned off sandbox - found a minimal implementation to show the issue:
- Jenkinsfile:
org.jenkinsci.plugins.workflow.cps.CpsThread.current().getExecution().getShell().evaluate('echo "OK"', 'X.groovy')
- Output:
Started by user unknown or anonymous Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline expected to call org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.evaluate but wound up catching X.run; see: https://jenkins.io/redirect/pipeline-cps-method-mismatches/ [Pipeline] echo OK [Pipeline] End of Pipeline Finished: SUCCESS
I think there is two ways to fix the issue:
- Prepare overload for evaluate function to be able to execute groovy logic with providing the src path and bindings
- Prepare an exception for executing CpsGroovyShell.evaluate https://github.com/cloudbees/groovy-cps/pull/99
jglick what do you think will be better? Easier for sure prepare an exception hack, but probably that will be appropriate to modify the evaluate step?
Or maybe even prepare `module` step and put such MPL functionality into the Jenkins itself? I'm just not sure that it's a good idea because probably I will need to prepare an additional plugin and I would avoid that and keep minimal requirements for the MPL library.
A patch to groovy-cps as in #2 would be the appropriate fix, I think. If we are entering certain overloads of GroovyShell.evaluate and we get a continuation from some Script.run implementation, then all is well and there should be no warning.
Thank you, I will prepare an implementation with tests for this case.
Ok, just prepared a couple of PR's:
- https://github.com/cloudbees/groovy-cps/pull/101 - with the exception implementation
- https://github.com/jenkinsci/workflow-cps-plugin/pull/315 - with the test of the minimal Jenkinsfile
jglick could you please check them?
The changes of PR#315 was merged to the master of workflow-cps-plugin - so hopefully will be available in the next release 2.75
A fix for this issue was just released in Pipeline: Groovy Plugin version 2.75.
Yep, confirmed here: https://github.com/griddynamics/mpl/issues/31#issuecomment-548919000
No, this would hide the critical diagnostic information from the people writing Pipelines who are normally responsible for making mistakes here.
The first step is to have a PR up with an addition to the existing @Ignore’d test case demonstrating the problem using the shortest possible script, possibly something like one of the above examples. In that case, a fix in groovy-cps is likely possible.