-
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
-
JENKINS-42498 Declarative Pipeline serialization errors when XStreamPickle is used
- Closed
- links to