Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Duplicate
Description
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
Attachments
Issue Links
- duplicates
-
-
- Closed
-
- links to
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
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 \{noformat} 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 \{noformat} 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: \{noformat} |java.lang.ClassCastException: org.jenkinsci.plugins.workflow.steps.EnvStep.overrides expects java.util.List<java.lang.String> but received class java.lang.String| | | \{noformat} 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 |
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 {noformat} 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 {noformat} 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: {noformat} java.lang.ClassCastException: org.jenkinsci.plugins.workflow.steps.EnvStep.overrides expects java.util.List<java.lang.String> but received class java.lang.String {noformat} 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 |
| Component/s | pipeline-model-definition-plugin [ 21706 ] | |
| Component/s | pipeline [ 21692 ] |
| Assignee | Andrew Bayer [ abayer ] |
| Attachment | Jenkinsfile [ 37251 ] |
You've got that in the gist, I think, but attaching it here wouldn't hurt.
| Attachment | dockerCompose.groovy [ 37444 ] |
The @NonCPS case is a red herring: JENKINS-31314. You may not mark this method @NonCPS.
The @NonCPS failure is, like Jesse said, a red herring, in that it'd fail like that even if everything else was working fine. The non-@NonCPS case, however, is a legit bug independent of anything else.
davidkarlsen One little request - any chance you could post the full log? If not, I understand.
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. =)
| Link |
This issue duplicates |
| Resolution | Duplicate [ 3 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Remote Link | This issue links to "CloudBees Internal OSS-2242 (Web Link)" [ 18377 ] |
| Status | Resolved [ 5 ] | Closed [ 6 ] |
Can you include the Jenkinsfile (or a dummy Jenkinsfile that reproduces the error) as well?