Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Won't Fix
Description
So I wanted to discuss this, in case there's a good reason for rejecting org.codehaus.groovy.runtime.GStringImpl specifically. We're currently blacklisting org.codehaus.groovy.runtime.* in hudson.remoting.ClassFilter.DEFAULT and that can cause hassles, so I thought it was worth discussion.
Attachments
Issue Links
- relates to
-
JENKINS-43934 GString kept unevaluated as long as StepDescriptor.newInstance (was: Pipeline build fails with serialization error when using string interpolation)
-
- Closed
-
-
-
- Reopened
-
- links to
Activity
| Field | Original Value | New Value |
|---|---|---|
| Link |
This issue relates to |
| Link | This issue relates to JENKINS-44873 [ JENKINS-44873 ] |
| Component/s | core [ 15593 ] |
abayer The ticket has the Remoting label, but from I see there is only request for XStream.
Or do we need both?
| Remote Link | This issue links to "CloudBees Internal CD-347 (Web Link)" [ 18987 ] |
Any attempt to save a GString in XML (or, not shown here, pass it over Remoting) should be treated as a plugin bug.
| Resolution | Won't Fix [ 2 ] | |
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Labels | JEP-200 |
I was one of customers being punished by JEP-200 too. Interestingly I have found a workaround like below. Basically, it seems to work fine when converting into String explicitly within the script.
def retList = []
for (String s in aFunctionReturnsAGStringList()) {
retList << s
}
retList
This is causing us issues as of the latest update on an unmodified Jenkinsfile. I can't trace down what particular change caused it (it was a plugin or system update, not the Jenkinsfile itself).
I was able to work around it by changing an option on the S3BucketPublisher (running it via step()) from:
sourceFile: "${env.BRANCH_NAME}.jenkins.tar.gz"To:
sourceFile: env.BRANCH_NAME + '.jenkins.tar.gz'That full step invocation with the fixed `sourceFile`:
The trace: