Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-49144

JEP-200 Issues when in Build Flow Plugin

    Details

    • Similar Issues:

      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

            Activity

            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Here is my analysis:

            I would say we won't fix Build Flow plugin since we have no way to release it. WDYT Jesse Glick Daniel Beck?

            Show
            oleg_nenashev Oleg Nenashev added a comment - Here is my analysis: The listed classes are not fine for serialization IMO. I doubt we want to whitelist it in the core IIUC There is no issue of Groovy PostBuild itself though I confirm the issue https://github.com/jenkinsci/build-flow-plugin is deprecated && depublished due to the security issue ( https://github.com/jenkins-infra/backend-update-center2/blob/2ef888007f759c5688f8ae0ddc1df6e9e95b7cca/src/main/resources/artifact-ignores.properties#L201 ) I would say we won't fix Build Flow plugin since we have no way to release it. WDYT Jesse Glick Daniel Beck ?
            Hide
            nathanjackels 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)
               ...
            
            Show
            nathanjackels 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) ...
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            I will update JIRA and plugin Wiki and then leave it to whomever wants to naintain the plugin

            Show
            oleg_nenashev Oleg Nenashev added a comment - I will update JIRA and plugin Wiki and then leave it to whomever wants to naintain the plugin
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            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

            Show
            oleg_nenashev Oleg Nenashev added a comment - 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
            Hide
            wolterhis 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.

            Show
            wolterhis 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.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Lars There are 2 workarounds:

            > 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.

            Show
            oleg_nenashev Oleg Nenashev added a comment - Lars 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.
            Hide
            jglick Jesse Glick added a comment -

            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.

            Show
            jglick Jesse Glick added a comment - 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.

              People

              • Assignee:
                Unassigned
                Reporter:
                nathanjackels Nathan Jackels
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: