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.
- relates to
-
JENKINS-43934 GString kept unevaluated as long as StepDescriptor.newInstance (was: Pipeline build fails with serialization error when using string interpolation)
-
- Closed
-
-
JENKINS-44873 UnsupportedOperationException - Refusing to marshal org.codehaus.groovy.runtime.GStringImpl
-
- Reopened
-
- links to
[JENKINS-42524] Don't blacklist GStringImpl from XStream serialization
Link |
New:
This issue relates to |
Link | New: This issue relates to JENKINS-44873 [ JENKINS-44873 ] |
Component/s | New: core [ 15593 ] |
Remote Link | New: This issue links to "CloudBees Internal CD-347 (Web Link)" [ 18987 ] |
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: