Details
-
Bug
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Won't Do
-
Jenkins 2.103, Groovy Postbuild 2.3.1, Build Flow 0.20
Description
When a build that uses groovy-postbuild is started by build-flow the GroovyPostbuildRecorder is unable to update the build.xml while serializing com.cloudbees.plugins.flow.FlowCause.
These two must be used together - a job started by build flow without groovy does not have issues, or the same project started directly by a user.
I was able to resolve this by adding the three following entries to whitelisted-classes.txt:
java.util.concurrent.locks.ReentrantLock java.util.concurrent.locks.ReentrantLock$NonfairSync java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject
I do not know what changes may be needed in either of the plugins to correctly resolve this - I'll leave it up to others to create those tickets.
Attached is the console output for four builds - one for each marshal failure, and the final success run at the end.
Attachments
Issue Links
- is duplicated by
-
-
- Open
-
-
-
- Resolved
-
Activity
Lars
added a comment - I need the BuildFlow jobs to be working again and I don't have time to replace them with whatever suits the needs. So what can I do? Why can't I disable what's preventing the jobs from working correctly? I don't care about security since the Jenkins instance is not accessible from outside. But I do care about working jobs. Moreover, I would expect a Jenkins update not to break jobs completely.
Lars
added a comment - I need the BuildFlow jobs to be working again and I don't have time to replace them with whatever suits the needs. So what can I do? Why can't I disable what's preventing the jobs from working correctly? I don't care about security since the Jenkins instance is not accessible from outside. But I do care about working jobs. Moreover, I would expect a Jenkins update not to break jobs completely. wolterhis There are 2 workarounds:
- Suppress particular classes using standard properties. See https://jenkins.io/blog/2018/01/13/jep-200/#for-jenkins-administrators
- Suppress the entire whitelist by using "-Djenkins.security.ClassFilterImpl.SUPPRESS_WHITELIST=true"
> Moreover, I would expect a Jenkins update not to break jobs completely.
We have to do some breaking changes: Security fixes, Java requirement updates, etc. This is required to move the project forward though I admit it causes frustration sometimes. In the case of all such changes we try to offer workarounds or killswitches when possible.
This change has been announced in advance. https://jenkins.io/changelog/ also explicitly warns about the risk of regressions in the plugins. If you update Jenkins weekly to 2.102+, as a Jenkins admin you accept a risk of possible regressions. When you use Weekly releases, you also accept a slight risk of regressions. LTS releases are much more stable.
LTS is not really relevant in this context since presumably Build Flow will not work on the next LTS, either. The plugin has long since been depublished and is no longer maintained. If you have a working environment and have no time to change things, stick with it and continue using an old version of Jenkins too, or see if one of the posted workarounds keeps the plugin limping along for now.
oleg_nenashev - How can I suppress the entire whitelist for Jenkins which is on Linux. I could not find any way. In which file I need to make changes and how? if possible can you make changes for Build Flow plugin because most of my Jobs are on Build flow only and will require huge effort to change it with the alternative plugins
Jagjeet Chadha
added a comment - - edited oleg_nenashev - How can I suppress the entire whitelist for Jenkins which is on Linux. I could not find any way. In which file I need to make changes and how? if possible can you make changes for Build Flow plugin because most of my Jobs are on Build flow only and will require huge effort to change it with the alternative plugins 
I have updated the document. Closing with "Won't do" for now. If anybody is interested to revive the plugin, please feel free to reopen the issue