[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko commented on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
I've said this before in this thread, but as I keep getting notifications about new comments in this issue from people who refuse to admin their pipelines design sucks - I have prepared this detailed walkthrough. Using this technique, I've been able to run 100 stages in both scripted and declarative mode before I'm hitting this issue. I didn't tried the workaround by Liam Newman which might improve Declarative one even further. I want to emphasize on the fact if you are having even half of that many stages - you are doing CICD wrong. You need to fix your process. Jenkins just happens to be a first bottleneck you've faced down that path. That discussion can get really philosophical as we will need to properly redefine what's CI and what's CD, what is a Pipeline and why Jenkins is not a Cron with web-interface. I really have no desire to be doing it here. Exception might be matrix jobs, but, even then I'm not so sure though I admit there might be a valid use case with that many stages in that space. But even then - execute your scripted pipeline in chunks (details below) - and there is no limits at all, I've been able to run a pipeline with 1 stages! Thought then my Jenkins fails to render that many stages in UI. But more on that later. Now, getting into the right way of doing Jenkins. First and foremost - your Jenkinsfile, no matter where it stored, must be small and simple. It doesn't have to tell WHAT to do, nor define any stages. All that is implementation details that you want to hide from your users. An example of such a Jenkinsfile:
library 'method-code-too-large-demo'
loopStagesScripted(100)
Note it doesn't matter if you're going to use scripted or declarative pipelines at this point. Here, you just collecting a user input. In my example I have just one - a number that defines how many stages I want in my pipeline. In real world example it might be any input you need from the user - type of project, platform version, any package/dependency details, etc. Just collect that input in any form and shape you want and pass it to your library. In my example a demo library lives here https://github.com/llibicpep/method-code-too-large-demo and loopStagesScripted is a step I have defined in it. Now, it is up to the library to read the user input, do whatever calculations, and generate your pipeline on the fly and then execute it. But the trick is - the pipeline is just a skeleton, defines the stages and does not actually performs any steps. For the steps it will fall back to the library again. Resulting pipeline from that Jenkinsfile will be looking like this:
stage('Stage 1') {
podTemplate(yaml: getPod(1)) {
node(POD_LABEL) {
doSomethingBasedOnStageNameOrWhatever(1)
}
}
}
stage('Stage 2') {
podTemplate(yaml: getPod(2)) {
node(POD_LABEL) {
doSomethingBasedOnStageNameOrWhatever(2)
}
}
}
...
[JIRA] (JENKINS-60054) Wrong umask? Containers with non-root user don't have permissions to agent durable script folders
Title: Message Title
Dmytro Kryvenko updated an issue
Jenkins / JENKINS-60054
Wrong umask? Containers with non-root user don't have permissions to agent durable script folders
Change By:
Dmytro Kryvenko
This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:{code} process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba (running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer){code}Doing that reveals:{code} LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied{code}I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.Just to summarize, expected behaviour would be: as long as{code} securityContext: fsGroup: 1000 supplementalGroups: - 1000{code}is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.I found another workaround, which is applying this on jnlp container:{code} command: - /bin/bash args: - "-c" - "umask 002; jenkins-agent"{code}But I would imagine it wouldn't be secure? Or is it not?
Add Comment
[JIRA] (JENKINS-60054) Wrong umask? Containers with non-root user don't have permissions to agent durable script folders
Title: Message Title
Dmytro Kryvenko updated an issue
Jenkins / JENKINS-60054
Wrong umask? Containers with non-root user don't have permissions to agent durable script folders
Change By:
Dmytro Kryvenko
This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:{code} process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba (running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer){code}Doing that reveals:{code} LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied{code}I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.Just to summarize, expected behaviour would be: as long as{code} securityContext: fsGroup: 1000 supplementalGroups: - 1000{code}is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.I found another workaround, which is applying this on jnlp container:{code} command: - /bin/bash args: - "-c" - "umask 0002 002 ; jenkins-agent"{code}But I would imagine it wouldn't be secure? Or is it not?
Add Comment
[JIRA] (JENKINS-60054) Wrong umask? Containers with non-root user don't have permissions to agent durable script folders
Title: Message Title
Dmytro Kryvenko updated an issue
Jenkins / JENKINS-60054
Wrong umask? Containers with non-root user don't have permissions to agent durable script folders
Change By:
Dmytro Kryvenko
This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to ` {{ /home/jenkins/agent ` }} .When running container with non-root user (of course having ` {{ fsGroup ` }} / ` {{ supplementalGroups ` }} to ` {{ 1000 ` }} to match jnlp slave GUID) getting the following error: ``` {{code}} process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba(running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer) ``` {{code}} Doing that reveals: ``` {{code}} LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied ``` {{code}} I know there's a lot of similar issues being reported recently, but this one is different and not related to the ` {{ workingDir ` }} in ` {{ jnlp ` }} slave. I am using ` {{ jenkins/jnlp-slave:3.35-5-alpine ` }} image and have ` {{ workingDir ` }} correctly defaulting to ` {{ /home/jenkins/agent ` }} .I've seen mainly two suggested workarounds to the issue - change user/group in the container and use ` {{ runAsUser ` }} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding ` {{ runAsUser: 1000 ` }} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.Just to summarize, expected behaviour would be: as long as ``` {{code}} securityContext:fsGroup: 1000supplementalGroups:- 1000 ``` {{code}} is set on the pod, using containers with non-root and non- {{ /home/jenkins }} home should work just fine like they used to.I found another workaround, which is applying this on jnlp container: ``` {{code}} command: - /bin/bash args: - "-c" - "umask 0002; jenkins-agent" ``` {{code}} But I would imagine it wouldn't be secure? Or is it not?
[JIRA] (JENKINS-60054) Wrong umask? Containers with non-root user don't have permissions to agent durable script folders
Title: Message Title
Dmytro Kryvenko updated an issue
Jenkins / JENKINS-60054
Wrong umask? Containers with non-root user don't have permissions to agent durable script folders
Change By:
Dmytro Kryvenko
This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to {{/home/jenkins/agent}}.When running container with non-root user (of course having {{fsGroup}}/{{supplementalGroups}} to {{1000}} to match jnlp slave GUID) getting the following error:{ { code} } process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba (running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer){ { code} } Doing that reveals:{ { code} } LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied{ { code} } I know there's a lot of similar issues being reported recently, but this one is different and not related to the {{workingDir}} in {{jnlp}} slave. I am using {{jenkins/jnlp-slave:3.35-5-alpine}} image and have {{workingDir}} correctly defaulting to {{/home/jenkins/agent}}.I've seen mainly two suggested workarounds to the issue - change user/group in the container and use {{runAsUser}} in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding {{runAsUser: 1000}} might work in some limited cases but in reality not viable either. A lot of stuff (let's start with git client) will complain the user for that UID doesn't exist and crash.Just to summarize, expected behaviour would be: as long as{ { code} } securityContext: fsGroup: 1000 supplementalGroups: - 1000{ { code} } is set on the pod, using containers with non-root and non-{{/home/jenkins}} home should work just fine like they used to.I found another workaround, which is applying this on jnlp container:{ { code} } command: - /bin/bash args: - "-c" - "umask 0002; jenkins-agent"{ { code} } But I would imagine it wouldn't be secure? Or is it not?
Add Comment
[JIRA] (JENKINS-60054) Wrong umask? Containers with non-root user don't have permissions to agent durable script folders
Title: Message Title Dmytro Kryvenko created an issue Jenkins / JENKINS-60054 Wrong umask? Containers with non-root user don't have permissions to agent durable script folders Issue Type: Bug Assignee: Unassigned Components: kubernetes-plugin Created: 2019-11-05 07:48 Environment: Jenkins: 2.190.2 kubernetes-plugin: 1.21.1 jnlp slave: jenkins/jnlp-slave:3.35-5-alpine Priority: Minor Reporter: Dmytro Kryvenko This setup used to work in older versions, I suspect regression happened somewhere around changing working directory to `/home/jenkins/agent`. When running container with non-root user (of course having `fsGroup`/`supplementalGroups` to `1000` to match jnlp slave GUID) getting the following error: ``` process apparently never started in /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-79996fba (running Jenkins temporarily with -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.LAUNCH_DIAGNOSTICS=true might make the problem clearer) ``` Doing that reveals: ``` LAUNCHER: open /home/jenkins/agent/workspace/ure-xxx-terraform-module_PR-1@tmp/durable-cc0559df/jenkins-log.txt: permission denied ``` I know there's a lot of similar issues being reported recently, but this one is different and not related to the `workingDir` in `jnlp` slave. I am using `jenkins/jnlp-slave:3.35-5-alpine` image and have `workingDir` correctly defaulting to `/home/jenkins/agent`. I've seen mainly two suggested workarounds to the issue - change user/group in the container and use `runAsUser` in pod definition. None of this is relevant. To build a flexible CICD you want users to have an ability to specify a dockerhub image (well, at least a tag to whitelisted images) so change of image is not viable. Adding `runAsUser: 1000` might work in some limited cases but in re
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script I understand your be frustrated but comments like this are not very helpful. Well sometimes truth is not helpful at all. What's your point? Maybe you have a solution or even a PR? Enlighten us. I couldn't disagree more. You didn't seem to read my suggestion careful enough. Declarative approach, indeed, is the future. Particular Jenkinsfile declarative implementation sucks, though. Because you kind of use declarative style but you still have to imperatively define steps. What a bummer! If you read careful enough what I said, you'll see what I opted in for is rather to have a small meta data file in the repository that explains facts about the app inside, so that the library can deal with it and render a pipeline for it. This render body is much easier to work with when it's scripted style, and the fact that it's scripted doesn't matter because users don't directly deal with it. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Well then you may be trying to apply a wrong tool for the job. Try some commercial offers maybe. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Well, if you do something like this but resulting Jenkinsfile produced is still in declarative style, you probably don't solve anything as the size of it will still be huge. But the point is - you just came up with your own declarative style that is simpler, smaller, and better suits your project or organization as being designed specifically for it. So you probably don't need declarative style being produced any more as it becomes nothing more than an intermediate format between the shared library and Jenkins (sort of JIT in Java world, really just a language that machine talking to a machine). There's no point in all that declarative style limits. In turn, if produced result is in scripted format - can be split into chunks and eval() separately, for instance per stage. I guess my point is - declarative style just sucks. From my experience it works only for small and simple projects despite how hard it's being advertised an opposite. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko edited a comment on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
The very basic example is all there [https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-declarative-pipelines]. You don't define parts of the pipeline but entire pipeline inside of the library. Example is pretty primitive, my idea is that the library can implement a number of custom closures to make available a following syntax:{code:java}myPipeline("platform") { foo "bar" deploy "baz " }{code}In other words making the input Jenkinsfile nothing more than a metadata file explaining what's inside of this repository. Shared library in turn can do calculations based on input above and pretty much do a lot of templating work in order to produce real Jenkinsfile to sent it to `eval()` or execute inline.Another example [https://jenkins.io/blog/2017/10/02/pipeline-templates-with-shared-libraries/]
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko edited a comment on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
The very basic example is all there [ https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-declarative-pipelines ] . You don't define parts of the pipeline but entire pipeline inside of the library. Example is pretty primitive, my idea is that the library can implement a number of custom closures to make available a following syntax: { { code:java} myPipeline("platform") { foo "bar" deploy "baz} {code } } In other words making the input Jenkinsfile nothing more than a metadata file explaining what's inside of this repository. Shared library in turn can do calculations based on input above and pretty much do a lot of templating work in order to produce real Jenkinsfile to sent it to `eval()` or execute inline.Another example [ https://jenkins.io/blog/2017/10/02/pipeline-templates-with-shared-libraries/ ]
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko commented on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
The very basic example is all there https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-declarative-pipelines. You don't define parts of the pipeline but entire pipeline inside of the library. Example is pretty primitive, my idea is that the library can implement a number of custom closures to make available a following syntax: {{myPipeline("platform") { foo "bar" deploy "baz } }} In other words making the input Jenkinsfile nothing more than a metadata file explaining what's inside of this repository. Shared library in turn can do calculations based on input above and pretty much do a lot of templating work in order to produce real Jenkinsfile to sent it to `eval()` or execute inline. Another example https://jenkins.io/blog/2017/10/02/pipeline-templates-with-shared-libraries/
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script you can only move your code at the script level in classes but you can't do this at the stage(s) level, which restricts drastically any refactoring. That's not entirely true. What I'm going to say might be too advance level for many users, but pipelines that hitting this limit to me sounds pretty advance. Shared library can provide your own custom declarative syntax (or imperative if you prefer). Shared library then, being a layer of abstraction, can calculate resulting Jenkinsfile (either declarative or scripted) based on your input and send it to `eval()`. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Entire Jenkinsfile effectively becomes a body to some sort of `eval` function under the hood (for the sake of simplification let's forget about CPS and stuff). It's no difference if you split the code into the methods and still keep the methods in Jenkinsfile. Methods needs to be moved into shared library or otherwise made available in the Jenkinsfile scope. No matter declarative or scripted pipeline - it's just directives that are effectively a Groovy closures. Standard java rules still applies no matter what. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Well if a declarative pipeline is so big that it won't fit into the limit - clearly the definition of a step needs some re-thinking. Sounds like a layer of abstraction required to wrap a multiple commonly-reusable steps into one to reduce the amount. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko edited a comment on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Let me re-phrase and sum-up some of the questions in that thread:{quote}I'm writing off my application and even though I moved bunch of the stuff into separate methods I still keep all of my high-level app working flow in my `main()` method and it is still to big and java complains about that. Can you fix it plz?{quote} I think the ticket may now be closed.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Let me re-phrase and sum-up some of the questions in that thread: I'm writing off my application and even though I moved bunch of the stuff into separate methods I still keep all of my high-level app working flow in my `main()` method and it is still to big and java complains about that. Can you fix it plz? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Any `Jenkinsfile` of any complexity can be shortened to just one line that looks like `doStuff()`. Does it makes sense to do it that way? Probably not but hopefully gives an idea as to where to move with this issue. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54277) StackOverflowError: Excessively nested closures/functions
Title: Message Title
Dmytro Kryvenko updated an issue
Jenkins / JENKINS-54277
StackOverflowError: Excessively nested closures/functions
Change By:
Dmytro Kryvenko
The following code:{code:java}abstract class Foo implements Serializable {void init() {println 'Init - Foo'}}abstract class Bar extends Foo implements Serializable { @Override void init() {super.init()println 'Init - Bar'}}class Baz extends Bar implements Serializable { @Override void init() {super.init()println 'Init - Baz'}}new Baz().init(){code}Will cause:{code:java}java.lang.StackOverflowError: Excessively nested closures/functions at Bar.init(WorkflowScript:9) - look for unbounded recursion - call depth: 1025 at com.cloudbees.groovy.cps.impl.CpsFunction.invoke(CpsFunction.java:28) at com.cloudbees.groovy.cps.impl.CpsCallableInvocation.invoke(CpsCallableInvocation.java:40) at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:62) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109) at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixName(FunctionCallBlock.java:77) at sun.reflect.GeneratedMethodAccessor216.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72) at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21) at com.cloudbees.groovy.cps.Next.step(Next.java:83) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:174) at com.cloudbees.groovy.cps.Continuable$1.call(Continuable.java:163) at org.codehaus.groovy.runtime.GroovyCategorySupport$ThreadCategoryInfo.use(GroovyCategorySupport.java:122) at org.codehaus.groovy.runtime.GroovyCategorySupport.use(GroovyCategorySupport.java:261) at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:163) at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:174) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:332) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$200(CpsThreadGroup.java:83) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:244) at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:232) at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:131) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at jenkins.security.ImpersonatingExecutorService$1.run(ImpersonatingExecutorService.java:59) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at
[JIRA] (JENKINS-54277) StackOverflowError: Excessively nested closures/functions
Title: Message Title
Dmytro Kryvenko created an issue
Jenkins / JENKINS-54277
StackOverflowError: Excessively nested closures/functions
Issue Type:
Bug
Assignee:
Unassigned
Components:
workflow-cps-plugin
Created:
2018-10-26 17:49
Environment:
Jenkins v2.121.3
Priority:
Major
Reporter:
Dmytro Kryvenko
The following code:
abstract class Foo implements Serializable {
void init() {
println 'Init - Foo'
}
}
abstract class Bar extends Foo implements Serializable {
void init() {
super.init()
println 'Init - Bar'
}
}
class Baz extends Bar implements Serializable {
void init() {
super.init()
println 'Init - Baz'
}
}
new Baz().init()
Will cause:
java.lang.StackOverflowError: Excessively nested closures/functions at Bar.init(WorkflowScript:9) - look for unbounded recursion - call depth: 1025
at com.cloudbees.groovy.cps.impl.CpsFunction.invoke(CpsFunction.java:28)
at com.cloudbees.groovy.cps.impl.CpsCallableInvocation.invoke(CpsCallableInvocation.java:40)
at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:62)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixName(F
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko edited a comment on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
{quote}I don't have much support so I have to automate as much DevOps stuff myself. Because I have very little resources and stakeholders that require a lot, I'm making the most of the resources I can get my hands on.{quote}That is somewhat twisted conclusion. Shared library as a layer of abstraction helps to maintain and simplify your life, as long as you use it right. Same as the possibility to run unit tests for that code. Otherwise it's just a snowflake, it may look beautiful from a certain angle but that is your first symptom you're getting right there.However, it's a pointless discussion, I am just a user the same as you, I do not making that call, but even then I don't see what Jenkins can possibly do as this is a JVM limitation. The Jenkinsfile essentially is Groovy DSL file which ends up being executed as a method. I can imagine they could possibly do some semantic analysis and try to automatically split it into chunks or obfuscate parts of it into a separate functions, but the level of effort needs to be put in it is nowhere close to the potential benefit. So I wouldn't suggest expecting expect any resolution to that issue.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script I don't have much support so I have to automate as much DevOps stuff myself. Because I have very little resources and stakeholders that require a lot, I'm making the most of the resources I can get my hands on. That is somewhat twisted conclusion. Shared library as a layer of abstraction helps to maintain and simplify your life, as long as you use it right. Same as the possibility to run unit tests for that code. Otherwise it's just a snowflake, it may look beautiful from a certain angle but that is your first symptom you're getting right there. However, it's a pointless discussion, I am just a user the same as you, I do not making that call, but even then I don't see what Jenkins can possibly do as this is a JVM limitation. The Jenkinsfile essentially is Groovy DSL file which ends up being executed as a method. I can imagine they could possibly do some semantic analysis and try to automatically split it into chunks or obfuscate parts of it into a separate functions, but the level of effort needs to be put in it is nowhere close to the potential benefit. So I wouldn't suggest expecting any resolution to that issue. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko edited a comment on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
[~henryborchers], complexity of your pipeline is completely irrelevant. Just to draw a parallel, the fact that you're creating complex Enterprise product does not justify you to put all it's code in a single file, or even in a single method, does it?Parts of your pipeline has to be a reusable functions in the shared library, so your actual jenkins file should consist only simple statements, something like{code}doThis()if (itsTrue()) { doThat()}{code}That applies only for scripted pipelines, of course. Accordingly to https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-declarative-pipelines it sounds like declarative pipelines even more limited that than I thought, so I'm happy I don't use 'em.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Just a quick searching in google reveal there is actually an open source project doing something good enough to demonstrate what I mean: https://github.com/fabric8io/fabric8-pipeline-library https://github.com/fabric8io/fabric8-jenkinsfile-library Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko commented on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Henry Borchers, complexity of your pipeline is completely irrelevant. Just to draw a parallel, the fact that you're creating complex Enterprise product does not justify you to put all it's code in a single file, or even in a single method, does it? Parts of your pipeline has to be a reusable functions in the shared library, so your actual jenkins file should consist only simple statements, something like
doThis()
if (itsTrue()) {
doThat()
}
That applies only for scripted pipelines, of course. Accordingly to https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-declarative-pipelines it sounds like declarative pipelines even more limited that I thought, so I'm happy I don't use 'em.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko edited a comment on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
800 lines of code in one file sounds bad in any language. It definitely needs a refactoring and shared libraries.Just to be clear - in my case above I experienced that issue while already having my libraries, and it was due the way I designed these libraries (they treat Jenkinsfile concept as some sort of JIT, they basically doing some calculations based on the input and spits out resulting long Jenkinsfile that I then eval() ed). I solved my case by splitting what I eval() into chunks exchanging the data through the context singleton object in my library (surprisingly singleton instances were not per Jenkins master JVM but per library instance, i.e. per individual build). So technically my case wasn't even related to Jenkins at all. I was sending too long string into eval() method and it was legitimately (accordingly to JVM) giving me a finger. Just to give an example, my chunks would look like:{code:java}getContext('stages')['Test Stage'] = {echo 'hi'}{code}{code:java}getContext('stages')['Second Test Stage'] = { echo 'hi again'} {code}{code:java} getContext('stages')['Second Test Stage'] = { echo 'hi again'} {code}{code:java} timestamps {ansiColor("xterm") {stage('Test Stage', getContext('stages')['Test Stage'])stage('Second Test Stage', getContext('stages')['Second Test Stage'])}}{code}Given that I think this issue may be closed now.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko edited a comment on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
800 lines of code in one file sounds bad in any language. It definitely needs a refactoring and shared libraries.Just to be clear - in my case above I experienced that issue while already having my libraries, and it was due the way I designed these libraries (they treat Jenkinsfile concept as some sort of JIT, they basically doing some calculations based on the input and spits out resulting long Jenkinsfile that I then eval() ed). I solved my case by splitting what I eval() into chunks exchanging the data through the context singleton object in my library (surprisingly singleton instances were not per Jenkins master JVM but per library instance, i.e. per individual build). So technically my case wasn't even related to Jenkins at all. I was sending too long string into eval() method and it was legitimately (accordingly to JVM) giving me a finger. Just to give an example, my chunks would look like:{code:java}getContext('stages')['Test Stage'] = {echo 'hi'}{code}{code:java}getContext('stages')['Second Test Stage'] = { echo 'hi again'} {code}{code:java}getContext('stages')['Second Test Stage'] = { echo 'hi again'} {code}{code:java}timestamps {ansiColor("xterm") {stage('Test Stage', getContext('stages')['Test Stage'])stage('Second Test Stage', getContext('stages')['Second Test Stage'])}}{code}Given that I think this issue may be closed now.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title
Dmytro Kryvenko commented on JENKINS-37984
Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
800 lines of code sounds bad in any language. It definitely needs a refactoring and shared libraries. Just to be clear - in my case above I experienced that issue while already having my libraries, and it was due the way I designed these libraries (they treat Jenkinsfile concept as some sort of JIT, they basically doing some calculations based on the input and spits out resulting long Jenkinsfile that I then eval() ed). I solved my case by splitting what I eval() into chunks exchanging the data through the context singleton object in my library (surprisingly singleton instances were not per Jenkins master JVM but per library instance, i.e. per individual build). So technically my case wasn't even related to Jenkins at all. I was sending too long string into eval() method and it was legitimately (accordingly to JVM) giving me a finger. Just to give an example, my chunks would look like:
getContext('stages')['Test Stage'] = {
echo 'hi'
}
getContext('stages')['Second Test Stage'] = {
echo 'hi again'
}
getContext('stages')['Second Test Stage'] = {
echo 'hi again'
}
timestamps {
ansiColor("xterm") {
stage('Test Stage', getContext('stages')['Test Stage'])
stage('Second Test Stage', getContext('stages')['Second Test Stage'])
}
}
Given that I think this issue may be closed now.
Add Comment
[JIRA] (JENKINS-53453) k8s volumes user and group
Title: Message Title
Dmytro Kryvenko edited a comment on JENKINS-53453
Re: k8s volumes user and group
I think I found this it :{code}"securityContext": {"supplementalGroups": [XXX],"fsGroup": XXX,"allowPrivilegeEscalation": false}{code}That will essentially make sure volumes belong to group XXX, and also add this group to the user in the container. It will not help when chmod don't give access to the group and only to the user - but this is already something.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53453) k8s volumes user and group
Title: Message Title
Dmytro Kryvenko commented on JENKINS-53453
Re: k8s volumes user and group
I think I found this:
"securityContext": {
"supplementalGroups": [XXX],
"fsGroup": XXX,
"allowPrivilegeEscalation": false
}
That will essentially make sure volumes belong to group XXX, and also add this group to the user in the container. It will not help when chmod don't give access to the group and only to the user - but this is already something.
Add Comment
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-53453) k8s volumes user and group
Title: Message Title
Dmytro Kryvenko created an issue
Jenkins / JENKINS-53453
k8s volumes user and group
Issue Type:
Bug
Assignee:
Carlos Sanchez
Components:
kubernetes-plugin
Created:
2018-09-07 04:20
Priority:
Minor
Reporter:
Dmytro Kryvenko
So here is the chicken-egg challenge I'm having hard times solving. I am not sure if this a bug, so yet to be classified. 1. file created by different container which was root:
env.K8S_POD_LABEL = "test-${BUILD_NUMBER}"
podTemplate(cloud: "k8s.example.com", label: env.K8S_POD_LABEL, yaml: """
{
"apiVersion": "v1",
"kind": "Pod",
"spec": {
"volumes": [
{
"emptyDir": {
},
"name": "aws-credentials"
}
],
"containers": [
{
"name": "jnlp",
"image": "jenkins/jnlp-slave",
"tty": true,
"volumeMounts": [
{
"name": "aws-credentials",
"mountPath": "/home/jenkins/.aws"
}
]
},
{
"name": "aws-cli",
"image": "mesosphere/aws-cli",
"tty": true,
"command": [
"cat"
],
"volumeMounts": [
{
"name": "aws-credentials",
"mountPath": "/root/.aws"
}
]
}
]
}
}
""") {
stage('Debug') {
node(env.K8S_POD_LABEL) {
container("aws-cl
[JIRA] (JENKINS-46145) Groovy Traits are not supported
Title: Message Title Dmytro Kryvenko commented on JENKINS-46145 Re: Groovy Traits are not supported For whoever else run into that issue: good old @Mixin seems to be working fine. It is deprecated in favor to traits, though, so dunno how long is it going to be available in the upcoming groovy versions. http://docs.groovy-lang.org/latest/html/api/groovy/lang/Mixin.html Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-46145) Groovy Traits are not supported
Title: Message Title Dmytro Kryvenko commented on JENKINS-46145 Re: Groovy Traits are not supported All of the sudden, I just ran into that issue. This CPS thing definitely gives a lot of benefits, but there should be a way to choose that I want to use library X with CPS but library Y is just plain Groovy. Would not be a problem, but here and there I ran into things that works in plain Groovy but do not in CPS - ending up blocked while have no benefit being CPS-ed in this particular piece of code. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko edited a comment on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script The thing is I actually don't want to hide this code to the library. My library already does it's thing, I have a custom DSL syntax that my library goes through and generates resulting Jenkinsfile. And I follow TDD, so I got tests, and my tests basically checking the resulting Jenkinsfile vs given my own DSL. Hiding parts of Jenkinsfile into the library going to ruin the whole idea of testing for my project. Again the Jenkinsfile for me is kind of JIT, it's not a code to being read or created by human. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script The thing is I actually don't want to hide this code to the library. My library already does it's thing, I have a custom DSL syntax that my library goes through and generates resulting Jenkinsfile. And I follow TDD, so I got tests, and my tests basically checking the resulting Jenkinsfile vs given my own DSL. Hiding parts of Jenkinsfile into the library going to ruin the whole idea of testing for my project. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Dmytro Kryvenko commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Any workarounds? My scenario is quite specific, we threat Jenkinsfile as some sort of a JIT. No one working with it directly, it rather being generated automatically based on something else. It is essential for the debugging purposes to have a big picture perspective on how the resulting Jenkinsfile going to look like, and there is no benefits into splitting it or moving to the shared library (again this is not for humans and not made by humans). We need a way to increase this limit. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50381) ECS plugin fails to use label expression
Title: Message Title Dmytro Kryvenko updated JENKINS-50381 Jenkins / JENKINS-50381 ECS plugin fails to use label _expression_ Change By: Dmytro Kryvenko Status: In Review Resolved Resolution: Fixed Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50381) ECS plugin fails to use label expression
Title: Message Title Dmytro Kryvenko started work on JENKINS-50381 Change By: Dmytro Kryvenko Status: Open In Progress Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50381) ECS plugin fails to use label expression
Title: Message Title Dmytro Kryvenko updated JENKINS-50381 Jenkins / JENKINS-50381 ECS plugin fails to use label _expression_ Change By: Dmytro Kryvenko Status: In Progress Review Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50381) ECS plugin fails to use label expression
Title: Message Title Dmytro Kryvenko edited a comment on JENKINS-50381 Re: ECS plugin fails to use label _expression_ I think that would do it: [ https://github.com/jenkinsci/amazon-ecs-plugin/pull/55 ]Tested on 2.107.1. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50381) ECS plugin fails to use label expression
Title: Message Title Dmytro Kryvenko assigned an issue to Dmytro Kryvenko Jenkins / JENKINS-50381 ECS plugin fails to use label _expression_ Change By: Dmytro Kryvenko URL: https://github.com/jenkinsci/amazon-ecs-plugin/pull/55 Assignee: Jan Roehrich Dmytro Kryvenko Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50381) ECS plugin fails to use label expression
Title: Message Title Dmytro Kryvenko commented on JENKINS-50381 Re: ECS plugin fails to use label _expression_ I think that would do it: https://github.com/jenkinsci/amazon-ecs-plugin/pull/55 Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-50381) ECS plugin fails to use label expression
Title: Message Title
Dmytro Kryvenko updated an issue
Jenkins / JENKINS-50381
ECS plugin fails to use label _expression_
Change By:
Dmytro Kryvenko
When I have multiple images defined in the same cluster I want to differentiate them by labels, like 'aws&&chef' or 'aws&&terraform'. Unfortunately it seems this plugin fails to handle plugin expressions, see the error stack trace below:{code:java}Mar 23 24 , 2018 10: 03 53 : 28 PM 40 AM WARNING hudson.slaves.NodeProvisioner$2 run Unexpected exception encountered while provisioning agent ECS Slave aws linux foo bar debian java.lang.ClassCastException: hudson.model.labels.LabelExpression$And cannot be cast to hudson.model.labels.LabelAtom at jenkins.model.Jenkins.getLabelAtom(Jenkins.java: 1978 1941 ) at hudson.model.Label.parse(Label.java:592) at hudson.model.Node.getAssignedLabels(Node.java:300) at hudson.model.Slave.(Slave.java:196) at hudson.slaves.AbstractCloudSlave.(AbstractCloudSlave.java:51) at com.cloudbees.jenkins.plugins.amazonecs.ECSSlave.(ECSSlave.java:95) at com.cloudbees.jenkins.plugins.amazonecs.ECSCloud$ProvisioningCallback.call(ECSCloud.java:243) at com.cloudbees.jenkins.plugins.amazonecs.ECSCloud$ProvisioningCallback.call(ECSCloud.java:221) at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748){code}
Add Comment
[JIRA] (JENKINS-50381) ECS plugin fails to use label expression
Title: Message Title Dmytro Kryvenko created an issue Jenkins / JENKINS-50381 ECS plugin fails to use label _expression_ Issue Type: Bug Assignee: Jan Roehrich Components: amazon-ecs-plugin Created: 2018-03-24 02:39 Environment: Tested on 2.107.1 and 2.89.2. Priority: Blocker Reporter: Dmytro Kryvenko When I have multiple images defined in the same cluster I want to differentiate them by labels, like 'aws&&chef' or 'aws&&terraform'. Unfortunately it seems this plugin fails to handle plugin expressions, see the error stack trace below: Mar 23, 2018 10:03:28 PM WARNING hudson.slaves.NodeProvisioner$2 run Unexpected exception encountered while provisioning agent ECS Slave aws linux foo bar java.lang.ClassCastException: hudson.model.labels.LabelExpression$And cannot be cast to hudson.model.labels.LabelAtom at jenkins.model.Jenkins.getLabelAtom(Jenkins.java:1978) at hudson.model.Label.parse(Label.java:592) at hudson.model.Node.getAssignedLabels(Node.java:300) at hudson.model.Slave.(Slave.java:196) at hudson.slaves.AbstractCloudSlave.(AbstractCloudSlave.java:51) at com.cloudbees.jenkins.plugins.amazonecs.ECSSlave.(ECSSlave.java:95) at com.cloudbees.jenkins.plugins.amazonecs.ECSCloud$ProvisioningCallback.call(ECSCloud.java:243) at com.cloudbees.jenkins.plugins.amazonecs.ECSCloud$ProvisioningCallback.call(ECSCloud.java:221) at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPool
