-
Bug
-
Resolution: Duplicate
-
Minor
I have some multibranch pipelines, where I want to move over to the declarative pipeline syntax.
I use a shared workflow library (added implicitly to all jobs, set as the default in the master config).
When using declarative pipelines I get
21:38:23 + docker-compose -f docker-compose.yml ps 21:38:24 stty: standard input: Inappropriate ioctl for device 21:38:24 Name Command State Ports 21:38:24 ----------------------------------------------------------------------------------------------------------------------------- 21:38:24 serverfeaturetacjfrsr167b43eenhq7fwkjpebbaprznkzesfair6fcv3a7pw26uh2fvuomq5a_oracle_1 /bin/sh -c /run.sh Up 1521/tcp [Pipeline] sh 21:38:24 [server_feature_TACJFRSR-167-B43EENHQ7FWKJPEBBAPRZNKZESFAIR6FCV3A7PW26UH2FVUOMQ5A] Running shell script [Pipeline] sh 21:38:24 [server_feature_TACJFRSR-167-B43EENHQ7FWKJPEBBAPRZNKZESFAIR6FCV3A7PW26UH2FVUOMQ5A] Running shell script [Pipeline] } ..... Caused by: java.lang.UnsupportedOperationException: Refusing to marshal org.codehaus.groovy.runtime.GStringImpl for security reasons
when running the helper method from my pipeline library. The same helper method with the same arguments works just fine in a "classic" style Jenkinsfile pipeline.
So I headed off and put @NonCPS on the helper-method, the strange thing is that I then get another return type from that method! w/o annotation it's a List as expected, with annotation it becomes a String:
java.lang.ClassCastException: org.jenkinsci.plugins.workflow.steps.EnvStep.overrides expects java.util.List<java.lang.String> but received class java.lang.String
It seems strange that the same pipeline-library behaves differently between the two pipeline styles of declaration.
See gist for full details:
https://gist.github.com/davidkarlsen/882af8fa46859134aa3502fd5921cb79#file-gistfile1-txt-L5
- duplicates
-
-
- Closed
-
- links to
[JENKINS-43635] declarative pipeline fails with workflow library
And of course, because that'd be too easy, I can't reproduce this. Can you tell me what versions of the following plugins you have installed?
- pipeline-model-definition
- workflow-cps
- workflow-api
Thanks!
pipeline model def: 1.0.2
The other two I don't find (but they might have changed name?)
Anyway I took a support bundle and the console log and sent in the cloudbees internal registered issue due to privacy reasons.
Ok, the actual issue is in the expression, and was fixed in 1.1 (JENKINS-42498).
That is, it's this code:
when {
//if it is a feature branch - rebase in changes from develop branch - the branch we target integration into:
expression { isFeatureBranch(env) }
}
abayer How strange that it does not fail early on - as that expression is evaluated at the very start of the pipeline - long before we gets to the stage which use the global pipeline library part (which calls compose/shellscripts).
Yeah, the serialization errors can happen at pretty much any time in the run. Very annoying, but fixed. =)
davidkarlsen One little request - any chance you could post the full log? If not, I understand.