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

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Blocker Blocker
    • workflow-cps-plugin
    • None

      Note from the Maintainers

      There is partial fix for this for Declarative pipelines in pipeline-model-definition-plugin v1.4.0 and later, significantly improved in v1.8.4.  Due to the extent to which it change how pipelines are executed it is turned off by default.  It can be turned on by setting a JVM property (either on the command-line or in Jenkins script console):

      org.jenkinsci.plugins.pipeline.modeldefinition.parser.RuntimeASTTransformer.SCRIPT_SPLITTING_TRANSFORMATION=true 

      As noted, this still works best with a Jenkinsfile with pipeline directive as the only root item in the file.
      Since v1.8.2 this workaround reports an informative error for pipelines using `def` variables before the pipeline directive. Add a @Field annotation to those declaration.
      This workaround generally does NOT work if the pipeline directive inside a shared library method. If this is a scenario you want, please come join the pipeline authoring SIG and we can discuss.

      Please give it a try and provide feedback. 

      Hi,

      We are getting below error in Pipeline which has some 495 lines of groovy code. Initially we assumed that one of our methods has an issue but once we remove any 30-40 lines of Pipeline groovy, this issue is not coming.

      Can you please suggest a quick workaround. It's a blocker for us.

      org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
      General error during class generation: Method code too large!
      
      java.lang.RuntimeException: Method code too large!
      	at groovyjarjarasm.asm.MethodWriter.a(Unknown Source)
      	at groovyjarjarasm.asm.ClassWriter.toByteArray(Unknown Source)
      	at org.codehaus.groovy.control.CompilationUnit$16.call(CompilationUnit.java:815)
      	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1053)
      	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
      	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
      	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
      	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
      	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
      	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
      	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
      	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
      	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410)
      	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373)
      	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213)
      	at hudson.model.ResourceController.execute(ResourceController.java:98)
      	at hudson.model.Executor.run(Executor.java:410)
      
      1 error
      
      	at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:310)
      	at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1073)
      	at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:591)
      	at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
      	at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
      	at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
      	at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
      	at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
      	at groovy.lang.GroovyShell.parse(GroovyShell.java:700)
      	at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:67)
      	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:410)
      	at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:373)
      	at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:213)
      	at hudson.model.ResourceController.execute(ResourceController.java:98)
      	at hudson.model.Executor.run(Executor.java:410)
      Finished: FAILURE
      

        1. errorIncomaptiblewithlocalvar.txt
          8 kB
        2. java.png
          java.png
          294 kB
        3. JenkinsCodeTooLarge.groovy
          45 kB
        4. Script_Splitting.groovy
          44 kB
        5. Script_Splittingx10.groovy
          519 kB

          [JENKINS-37984] org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script

          bitwiseman: How is the feature behaving for you? Do you have any feedback, comments, observations?

          With this feature our main declarative multi branch pipeline works only with the SCRIPT_SPLITTING_TRANSFORMATION feature, without it we would have to go to back to classic up-/down-stream approach. We don't use variables outside of the pipeline at the moment. All other pipelines are small enough.

          We use here trunk based development in a monorepo for our main loan application with different backend and frontend technologies. And not all are implemented at till now.

          Despite we try to move a lot of logic to pipeline libraries there remains a lot of stages because of when conditions depending on branching model and repository names (eg. for testing jenkins staging). Furtermore we need different pipeline stages for environments like development, test and production or for different controllers for building on different operating systems.

          One thing we miss at the moment is better parallel support as other systems like UC4 have. Eg. parallel in parallel and the corresponding visualization in blue ocean.

          Torsten Kleiber added a comment - >  bitwiseman : How is the feature behaving for you? Do you have any feedback, comments, observations? With this feature our main declarative multi branch pipeline works only with the SCRIPT_SPLITTING_TRANSFORMATION feature, without it we would have to go to back to classic up-/down-stream approach. We don't use variables outside of the pipeline at the moment. All other pipelines are small enough. We use here trunk based development in a monorepo for our main loan application with different backend and frontend technologies. And not all are implemented at till now. Despite we try to move a lot of logic to pipeline libraries there remains a lot of stages because of when conditions depending on branching model and repository names (eg. for testing jenkins staging). Furtermore we need different pipeline stages for environments like development, test and production or for different controllers for building on different operating systems. One thing we miss at the moment is better parallel support as other systems like UC4 have. Eg. parallel in parallel and the corresponding visualization in blue ocean.

          > bitwiseman: How is the feature behaving for you? Do you have any feedback, comments, observations?

          We are not using the SCRIPT_SPLITTING_TRANSFORMATION set (by default it false, right?).

          Our pipelines mostly use methods/functions from Jenkins Shared library and
          all pipelines contains some global variables before pipeline block (variables with some groovy logic, which used in more than 2 stages, or should be defined as global).
          The example of pipeline you may take from this issue description: JENKINS-64846

          Pipelines are separated from functions, so - no pipeline blocks in call functions for shared library, like it was shown here: JENKINS-64846?focusedCommentId=407258

          bitwiseman, I know, this is beta, but is there any documentation available for description of flags and behavior of pipelines? It would be good to have examples without diving in the plugin source code. Especially with our approach of using groovy outside pipeline block.

          Oleh Moskovych added a comment - > bitwiseman : How is the feature behaving for you? Do you have any feedback, comments, observations? We are not using the SCRIPT_SPLITTING_TRANSFORMATION set (by default it false, right?). Our pipelines mostly use methods/functions from Jenkins Shared library and all pipelines contains some global variables before pipeline block (variables with some groovy logic, which used in more than 2 stages, or should be defined as global). The example of pipeline you may take from this issue description: JENKINS-64846 Pipelines are separated from functions, so - no pipeline blocks in call functions for shared library, like it was shown here: JENKINS-64846?focusedCommentId=407258 bitwiseman , I know, this is beta, but is there any documentation available for description of flags and behavior of pipelines? It would be good to have examples without diving in the plugin source code. Especially with our approach of using groovy outside pipeline block.

          As I want to test a specific library branch I try to use follwing notation: 

           

          @Library('shared-libraries@feature/test-shared-library') _
          
          pipeline {
            // long pipeline here
          }

          Therefore I tried to use following properties combined:

           

          -Dorg.jenkinsci.plugins.pipeline.modeldefinition.parser.RuntimeASTTransformer.SCRIPT_SPLITTING_TRANSFORMATION=true -Dorg.jenkinsci.plugins.pipeline.modeldefinition.parser.RuntimeASTTransformer.SCRIPT_SPLITTING_ALLOW_LOCAL_VARIABLES=true 

          But as soon as I add the second parameter, the first will not work anymore. Is this the intended behavior? So I cannot use local libraries in big pipelines? Or do I have to do this in another way?

           

          Jenkins 2.387.1 on SLES 12.5.

           

          Torsten Kleiber added a comment - As I want to test a specific library branch I try to use follwing notation:    @Library( 'shared-libraries@feature/test-shared-library' ) _ pipeline { // long pipeline here } Therefore I tried to use following properties combined:   -Dorg.jenkinsci.plugins.pipeline.modeldefinition.parser.RuntimeASTTransformer.SCRIPT_SPLITTING_TRANSFORMATION= true -Dorg.jenkinsci.plugins.pipeline.modeldefinition.parser.RuntimeASTTransformer.SCRIPT_SPLITTING_ALLOW_LOCAL_VARIABLES= true But as soon as I add the second parameter, the first will not work anymore. Is this the intended behavior? So I cannot use local libraries in big pipelines? Or do I have to do this in another way?   Jenkins 2.387.1 on SLES 12.5.  

          How is this still an issue in 2024?

          Henry Borchers added a comment - How is this still an issue in 2024?

          > How is this still an issue in 2024?

          Because the issue is the result of a fundamental design decision.

          Brian J Murrell added a comment - > How is this still an issue in 2024? Because the issue is the result of a fundamental design decision.

          Dee Kryvenko added a comment -

          > Because the issue is the result of a fundamental design decision.

          Of using Jenkins in the first place. So glad I moved away from it. And I can finally get work done instead of fighting made up issues all the time. Never been happier.

          Dee Kryvenko added a comment - > Because the issue is the result of a fundamental design decision. Of using Jenkins in the first place. So glad I moved away from it. And I can finally get work done instead of fighting made up issues all the time. Never been happier.

          Within the better part of a decade, I have been using declarative pipelines. I have found that they are very expressive as well as very easy to read  and to maintain.  It's more powerful than GitHub Actions yaml files. However, it sounds like from the latest comments that everyone else has abandoned the declarative pipeline. Am I wrong in this?

          I have used scripted sections within my declarative pipelines for things that I can't easily do within the constrains of the declarative style. However,  the idea of making a purely scripted pipeline seems potentially messy. If you've abandoned the declarative pipeline, what have you moved on to instead?

          Henry Borchers added a comment - Within the better part of a decade, I have been using declarative pipelines. I have found that they are very expressive as well as very easy to read  and to maintain.  It's more powerful than GitHub Actions yaml files. However, it sounds like from the latest comments that everyone else has abandoned the declarative pipeline. Am I wrong in this? I have used scripted sections within my declarative pipelines for things that I can't easily do within the constrains of the declarative style. However,  the idea of making a purely scripted pipeline seems potentially messy. If you've abandoned the declarative pipeline, what have you moved on to instead?

          We further use succesfully declarative pipelines with the workaround configured. 

          Torsten Kleiber added a comment - We further use succesfully declarative pipelines with the workaround configured. 

          Dee Kryvenko added a comment -

          > If you've abandoned the declarative pipeline, what have you moved on to instead?

          Never used declarative pipeline to begin with. Jenkins desperately trying to be a "platform". It is not a "platform". It is a cron server with web interface. It can be turned into a "platform" by "platform" engineers, in which case, pipeline would be generated automatically - it doesn't have to be readable or declarative, as that would only add artificial limitations and made up issues. Which it is. Jenkins can never be a "platform" as everyone's last mile challenges are going to be very unique. Jenkins fails to understand that, but it is very successful at alienating "platform" people who at one point were the biggest advocates and helped organizations to adopt it. No more.

          As Jenkins tries to be a "platform", it also tries to be smart about the confused deputy problem. Which, again, not its to solve - it only getting in the way for those of us who actually need to solve it.

          There might be some amount of users for whom Jenkins does solve last mile issues out of the box, and they do not require "platform" engineers. Good for them - but I would argue they are not doing anything complex to begin with, and would probably be better off with something much simpler and less maintenance heavy, like maybe GitHub Actions ARC. The fact that in 2024 Jenkins still cannot even restart without a downtime, not to mention horizontal scaling, not to mention in-memory state direct serialization into XML on the disk, not to mention crazy IOPS utilization, is a joke. They missed the kubernetes memo. Any relatively large Jenkins deployment becomes a maintenance nightmare. I am running GHA ARC for CI and ArgoCD for CD, for over a year now - I maybe spent 30 mins top on it's maintenance the entire year, and my users had zero service interruptions. State is distributed, everything is scaled horizontally... I have so much free time now, to write this message, for example.

          Dee Kryvenko added a comment - > If you've abandoned the declarative pipeline, what have you moved on to instead? Never used declarative pipeline to begin with. Jenkins desperately trying to be a "platform". It is not a "platform". It is a cron server with web interface. It can be turned into a "platform" by "platform" engineers, in which case, pipeline would be generated automatically - it doesn't have to be readable or declarative, as that would only add artificial limitations and made up issues. Which it is. Jenkins can never be a "platform" as everyone's last mile challenges are going to be very unique. Jenkins fails to understand that, but it is very successful at alienating "platform" people who at one point were the biggest advocates and helped organizations to adopt it. No more. As Jenkins tries to be a "platform", it also tries to be smart about the confused deputy problem. Which, again, not its to solve - it only getting in the way for those of us who actually need to solve it. There might be some amount of users for whom Jenkins does solve last mile issues out of the box, and they do not require "platform" engineers. Good for them - but I would argue they are not doing anything complex to begin with, and would probably be better off with something much simpler and less maintenance heavy, like maybe GitHub Actions ARC. The fact that in 2024 Jenkins still cannot even restart without a downtime, not to mention horizontal scaling, not to mention in-memory state direct serialization into XML on the disk, not to mention crazy IOPS utilization, is a joke. They missed the kubernetes memo. Any relatively large Jenkins deployment becomes a maintenance nightmare. I am running GHA ARC for CI and ArgoCD for CD, for over a year now - I maybe spent 30 mins top on it's maintenance the entire year, and my users had zero service interruptions. State is distributed, everything is scaled horizontally... I have so much free time now, to write this message, for example.

          Heiko Nardmann added a comment -

          Heiko Nardmann added a comment - Others seem to have same problem: https://confluence.atlassian.com/jirakb/groovy-script-cannot-be-executed-due-to-method-code-too-large-error-1063568679.html

            Unassigned Unassigned
            anudeeplalam Anudeep Lalam
            Votes:
            87 Vote for this issue
            Watchers:
            103 Start watching this issue

              Created:
              Updated: