-
Bug
-
Resolution: Won't Do
-
Minor
-
Jenkins 2.103, Groovy Postbuild 2.3.1, Build Flow 0.20
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.
- is duplicated by
-
-
- Open
-
-
-
- Resolved
-
[JENKINS-49144] JEP-200 Issues when in Build Flow Plugin
Nathan Jackels
created issue -
Nathan Jackels
added a comment - IIUC There is no issue of Groovy PostBuild itself though I confirm the issue
Correct - When Build Flow plugin is not involved I have not observed any issues with the Groovy PostBuild plugin.
I would say we won't fix Build Flow plugin since we have no way to release it.
As a user I am okay with applying this same patch each time I upgrade the cluster (waiting on some enhancements to pipeline before converting everything).
Something else I just noticed is that when this happens the build.xml and injectedEnvVars.txt for the build disappear from disk (removing this run from history after a restart).
Perhaps a change to something in this stack is warranted to make backup files then restore if there is an error:
Caused: java.io.IOException
at hudson.XmlFile.write(XmlFile.java:201)
at hudson.model.Run.save(Run.java:1923)
at org.jvnet.hudson.plugins.groovypostbuild.GroovyPostbuildRecorder.perform(GroovyPostbuildRecorder.java:370)
...
Nathan Jackels
added a comment - IIUC There is no issue of Groovy PostBuild itself though I confirm the issue
Correct - When Build Flow plugin is not involved I have not observed any issues with the Groovy PostBuild plugin.
I would say we won't fix Build Flow plugin since we have no way to release it.
As a user I am okay with applying this same patch each time I upgrade the cluster (waiting on some enhancements to pipeline before converting everything).
Something else I just noticed is that when this happens the build.xml and injectedEnvVars.txt for the build disappear from disk (removing this run from history after a restart).
Perhaps a change to something in this stack is warranted to make backup files then restore if there is an error:
Caused: java.io.IOException
at hudson.XmlFile.write(XmlFile.java:201)
at hudson.model.Run.save(Run.java:1923)
at org.jvnet.hudson.plugins.groovypostbuild.GroovyPostbuildRecorder.perform(GroovyPostbuildRecorder.java:370)
...
com.cloudbees.plugins.flow.JobInvocation#lock and com.cloudbees.plugins.flow.JobInvocation#finalizedCond certainly sound like mistakes. Maybe they were supposed to be transient? Or maybe something deeper is wrong with this plugin. Whatever the case, it is depublished so we are not going to even spend time investigating it; you are advised to uninstall the plugin.
| Component/s | Original: core [ 15593 ] | |
| Component/s | Original: groovy-postbuild-plugin [ 15685 ] |
I will update JIRA and plugin Wiki and then leave it to whomever wants to naintain the plugin
| Assignee | Original: Craig Rodrigues [ rodrigc ] | New: Oleg Nenashev [ oleg_nenashev ] |
| Summary | Original: JEP-200 Issues when both Build-Flow and Groovy-Postbuild used | New: JEP-200 Issues when in Build Flow Plugin |
| Link |
New:
This issue is duplicated by |
| Labels | Original: JEP-200 | New: JEP-200 JEP-200-rejected |
Here is my analysis:
I would say we won't fix Build Flow plugin since we have no way to release it. WDYT jglick danielbeck?