[JIRA] [conditional-buildstep] (JENKINS-20292) Option to specify an else-block
Gergely Nagy commented on JENKINS-20292 Option to specify an else-block I absolutely agreed, some of much conditions are so much messier due to the repetition - that I've fallen back to edit the XML. (BTW, if there was a way to copy/paste buildsteps between outside and insider the condition (and in general in Jenkins, it would make this less painful.) I'm considering working on this - unless experts owners disagree or think it's really tricky to do. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [conditional-buildstep] (JENKINS-20292) Option to specify an else-block
Gergely Nagy edited a comment on JENKINS-20292 Option to specify an else-block I absolutely agreed, some of my conditions are so much messier due to the repetition - that I've fallen back to edit the XML. (BTW, if there was a way to copy/paste buildsteps between outside and insider the condition (and in general in Jenkins, it would make this less painful.) I'm considering working on this - unless experts owners disagree or think it's really tricky to do. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [conditional-buildstep] (JENKINS-20292) Option to specify an else-block
Gergely Nagy edited a comment on JENKINS-20292 Option to specify an else-block I absolutely agreed, some of my conditions are so much messier due to the repetition - that I've fallen back to edit the config.xml via API. (BTW, if there was a way to copy/paste buildsteps between outside and insider the condition (and in general in Jenkins, it would make this less painful.) I'm considering working on this - unless experts owners disagree or think it's really tricky to do. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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-17344) No such property: compressBuildLog
Gergely Nagy created JENKINS-17344 No such property: compressBuildLog Issue Type: Bug Assignee: Alex Earl Components: email-ext Created: 25/Mar/13 4:53 PM Description: Since an upgrade of Email-Ext plugin v2.25 - v2.27.1, I cannot open same Configuration pages. They are stuck at the LOADING stage, and throw an exception stack trace (500). So this breaks not just email related configuration of those jobs completely. the only "workaround" I found is hacking into the config.xml on server to remove the element related to ext-email config, then restart server (not an option for me), so had to downgrade to 2.25. javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.480.3.jar!/lib/form/hetero-list.jelly:112:94: st:include org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.480.3.jar!/lib/form/optionalBlock.jelly:84:23: d:invokeBody org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.480.3.jar!/lib/form/entry.jelly:73:23: d:invokeBody No such property: compressBuildLog for class: hudson.plugins.emailext.ExtendedEmailPublisher at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) Side question: could Jenkins be improved so that plugin bugs like this would isolated have such a disastrous effect (e.g in this case, handle the exception gracefully). Project: Jenkins Priority: Critical Reporter: Gergely Nagy This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-17344) Config pages broken by No such property: compressBuildLog
Gergely Nagy
updated JENKINS-17344
Config pages broken by No such property: compressBuildLog
Change By:
Gergely Nagy
(25/Mar/13 4:58 PM)
Description:
SinceanupgradeofEmail-Extpluginv2.25-v2.27.1,IcannotopensameConfigurationpages.TheyarestuckattheLOADINGstage,andthrowanexceptionstacktrace(500).Sothisbreaks-notjustemail-relatedconfigurationofthosejobscompletely.theonlyworkaroundIfoundishackingintotheconfig.xmlonservertoremovetheelementrelatedtoext-emailconfig,thenrestartserver(notanoptionforme),sohadtodowngradeto2.25.{code}javax.servlet.ServletException:org.apache.commons.jelly.JellyTagException:jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.480.3.jar!/lib/form/hetero-list.jelly:112:94:st:includeorg.apache.commons.jelly.JellyTagException:jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.480.3.jar!/lib/form/optionalBlock.jelly:84:23:d:invokeBodyorg.apache.commons.jelly.JellyTagException:jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.480.3.jar!/lib/form/entry.jelly:73:23:d:invokeBodyNosuchproperty:compressBuildLogforclass:hudson.plugins.emailext.ExtendedEmailPublisher atorg.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103){code}Sidequestion:couldJenkinsbeimprovedsothatpluginbugslikethiswould
be
isolated
have
toavoid
suchadisastrouseffect
?
(e.ginthiscase,handletheexception
gracefully
whileviewingthepage
).
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
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/groups/opt_out.
[JIRA] (JENKINS-17344) Config pages broken by No such property: compressBuildLog
Gergely Nagy commented on JENKINS-17344 Config pages broken by No such property: compressBuildLog Yes, I have restarted Jenkins after upgrading. BTW, the install is a standard .deb(Debian Linux) one. Attaching config.xml. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-17344) Config pages broken by No such property: compressBuildLog
Gergely Nagy updated JENKINS-17344 Config pages broken by No such property: compressBuildLog Change By: Gergely Nagy (25/Mar/13 5:06 PM) Attachment: config.xml This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-17344) Config pages broken by No such property: compressBuildLog
Gergely Nagy commented on JENKINS-17344 Config pages broken by No such property: compressBuildLog Yes it's the latest LTS: 1.480.3. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-17344) Config pages broken by No such property: compressBuildLog
Gergely Nagy commented on JENKINS-17344 Config pages broken by No such property: compressBuildLog In the meantime, I had to downgrade to 2.25. I found 'plugins/email-ext.jpi', but this is the working version now. Can I still find the previous .jpi hanging around? If not I'll have to try again later in the week. Thanks. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
Gergely Nagy commented on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Thank you very much for this - it would fix an important regression for me (my long running tests are flooding the queue with the current version). Any way to release it soon? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
Gergely Nagy edited a comment on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Thank you very much for this - it would fix an important regression for me (my long running tests are flooding the queue with the current version - this started to happen with the latest upgrade). Any way to release it soon? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
Gergely Nagy reopened JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times combineQueuedCommits=true does not seem to work = reopening. See my previous comment. Change By: Gergely Nagy (11/Feb/13 11:53 AM) Resolution: Fixed Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
Gergely Nagy commented on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Should combineQueuedCommits=true result in a single long downstream build (even if its upstream job is frequent and fast)? If so, it does not appear to work for me. My simple test with Jenkins 1.480.2 (LTE), Git plugin 1.1.26, Paramtrigger plugin: 2.16: 1) new job: try-combinecommits-downstream scm: a tiny git repo build step: shell "sleep 120" 2) new job: try-combinecommits-base, scm: the same repo, trigger by push notification build step: shell "sleep 10" trigger parametrized build: try-combinecommits-downstream, param: Git SHA1 combineQueuedCommits: yes 3) a simple bash loop to pushed dummy changes dozens of times Result: the short upstream job triggers the downsteam one for each build - no sign of "combining" them, ie. to pick the last build. I'd expect a second trigger should remove the first one off the queue. Do I miss anything? Thanks. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
Gergely Nagy edited a comment on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Should combineQueuedCommits=true result in a single long downstream build (even if its upstream ran multiple times)? If so, it does not appear to work for me. My simple test with Jenkins 1.480.2 (LTE), Git plugin 1.1.26, Paramtrigger plugin: 2.16: 1) new job: try-combinecommits-downstream scm: a tiny git repo build step: shell "sleep 120" 2) new job: try-combinecommits-base, scm: the same repo, trigger by push notification build step: shell "sleep 10" trigger parametrized build: try-combinecommits-downstream, param: Git SHA1 combineQueuedCommits: yes 3) a simple bash loop to pushed dummy changes dozens of times Result: the short upstream job triggers the downsteam one for each build - no sign of "combining" them, ie. to pick the last build. I'd expect a second trigger should remove the first one off the queue. Do I miss anything? Thanks. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
Gergely Nagy edited a comment on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Should combineQueuedCommits=true result in a single long downstream build (even if its upstream ran multiple times)? If so, it does not appear to work for me. My simple test with Jenkins 1.480.2 (LTE), Git plugin 1.1.26, Paramtrigger plugin: 2.16: 1) new job: try-combinecommits-downstream scm: a tiny git repo build step: shell "sleep 120" 2) new job: try-combinecommits-base, scm: the same repo, trigger by push notification build step: shell "sleep 10" trigger parametrized build: try-combinecommits-downstream, param: Git SHA1 combineQueuedCommits: yes 3) a simple bash loop to pushed dummy changes dozens of times Result: the short upstream job triggers the downsteam one for each build, flooding the queue - no sign of "combining" them, ie. to pick the last build. I'd expect a second trigger should remove the first one off the queue. Do I miss anything? Thanks. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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/groups/opt_out.
[JIRA] (JENKINS-10131) Git polling shouldn't need a workspace on a slave.
Gergely Nagy commented on JENKINS-10131 Git polling shouldnt need a workspace on a slave. Seeing this with 1.1.25, with a single repo single branch (so it should work according to the above). Started on 24-Jan-2013 00:24:57 No workspace is available, so can't check for updates. Scheduling a new build to get a workspace. Done. Took 1 ms Changes found This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13464) Using Other Views filter, I'm getting a stack overflow error after update to Jenkins 1.459
[ https://issues.jenkins-ci.org/browse/JENKINS-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163246#comment-163246 ] Gergely Nagy commented on JENKINS-13464: We were hit by this too - thanks for reporting. It basically cause intermittent hungs, the no HTTP reply kind (https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+is+hanging). I haven't found a good way to reproduce this yet, but I'm getting a slightly different log for the endless recursion - attaching. Using Other Views filter, I'm getting a stack overflow error after update to Jenkins 1.459 -- Key: JENKINS-13464 URL: https://issues.jenkins-ci.org/browse/JENKINS-13464 Project: Jenkins Issue Type: Bug Components: sectioned-view, view-job-filters Reporter: Vincent Latombe Assignee: Jacob Robertson Priority: Blocker Attachments: StackOverflow.txt Due to https://github.com/jenkinsci/jenkins/commit/85e13303f8cfbebeb7dab347fda8ccf4069070b6 , any view using Other Views filter now gets a StackOverflowError. The reason is that it uses a wrong way of retrieving the referenced view, by getting first 'all' the views. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13464) Using Other Views filter, I'm getting a stack overflow error after update to Jenkins 1.459
[ https://issues.jenkins-ci.org/browse/JENKINS-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163246#comment-163246 ] Gergely Nagy edited comment on JENKINS-13464 at 5/28/12 9:52 PM: - We were hit by this too - thanks for reporting. It basically cause intermittent hungs, the no HTTP reply kind (https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+is+hanging). I haven't found a good way to reproduce this yet, but I'm getting a slightly different log for the endless recursion - attaching. Extract: at hudson.model.ListView.getItems(ListView.java:138) at hudson.model.ListView.getItems(ListView.java:58) at hudson.security.AuthorizationStrategy$1.hasPermission(AuthorizationStrategy.java:103) at hudson.security.ACL.hasPermission(ACL.java:65) at hudson.model.View.hasPermission(View.java:503) at hudson.model.ViewGroupMixIn.getViews(ViewGroupMixIn.java:115) at jenkins.model.Jenkins.getViews(Jenkins.java:1370) at hudson.views.OtherViewsFilter.getAllViews(OtherViewsFilter.java:148) at hudson.views.UnclassifiedJobsFilter.doFilter(UnclassifiedJobsFilter.java:27) at hudson.views.AbstractIncludeExcludeJobFilter.filter(AbstractIncludeExcludeJobFilter.java:57) at hudson.model.ListView.getItems(ListView.java:162) at hudson.model.ListView.getItems(ListView.java:58) was (Author: inger): We were hit by this too - thanks for reporting. It basically cause intermittent hungs, the no HTTP reply kind (https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+is+hanging). I haven't found a good way to reproduce this yet, but I'm getting a slightly different log for the endless recursion - attaching. Using Other Views filter, I'm getting a stack overflow error after update to Jenkins 1.459 -- Key: JENKINS-13464 URL: https://issues.jenkins-ci.org/browse/JENKINS-13464 Project: Jenkins Issue Type: Bug Components: sectioned-view, view-job-filters Reporter: Vincent Latombe Assignee: Jacob Robertson Priority: Blocker Attachments: StackOverflow.txt Due to https://github.com/jenkinsci/jenkins/commit/85e13303f8cfbebeb7dab347fda8ccf4069070b6 , any view using Other Views filter now gets a StackOverflowError. The reason is that it uses a wrong way of retrieving the referenced view, by getting first 'all' the views. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13464) Using Other Views filter, I'm getting a stack overflow error after update to Jenkins 1.459
[ https://issues.jenkins-ci.org/browse/JENKINS-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163246#comment-163246 ] Gergely Nagy edited comment on JENKINS-13464 at 5/28/12 9:54 PM: - We were hit by this too - thanks for reporting. It basically cause intermittent hungs, the no HTTP reply kind (https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+is+hanging). I haven't found a good way to reproduce this yet, but I'm getting a slightly different log for the endless recursion - attaching. Extract: at hudson.views.AbstractIncludeExcludeJobFilter.filter(AbstractIncludeExcludeJobFilter.java:57) at hudson.model.ListView.getItems(ListView.java:162) at hudson.model.ListView.getItems(ListView.java:58) at hudson.security.AuthorizationStrategy$1.hasPermission(AuthorizationStrategy.java:103) at hudson.security.ACL.hasPermission(ACL.java:65) at hudson.model.View.hasPermission(View.java:503) at hudson.model.ViewGroupMixIn.getViews(ViewGroupMixIn.java:115) at jenkins.model.Jenkins.getViews(Jenkins.java:1370) at hudson.views.OtherViewsFilter.getAllViews(OtherViewsFilter.java:148) at hudson.views.UnclassifiedJobsFilter.doFilter(UnclassifiedJobsFilter.java:27) at hudson.views.AbstractIncludeExcludeJobFilter.filter(AbstractIncludeExcludeJobFilter.java:57) was (Author: inger): We were hit by this too - thanks for reporting. It basically cause intermittent hungs, the no HTTP reply kind (https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+is+hanging). I haven't found a good way to reproduce this yet, but I'm getting a slightly different log for the endless recursion - attaching. Extract: at hudson.model.ListView.getItems(ListView.java:138) at hudson.model.ListView.getItems(ListView.java:58) at hudson.security.AuthorizationStrategy$1.hasPermission(AuthorizationStrategy.java:103) at hudson.security.ACL.hasPermission(ACL.java:65) at hudson.model.View.hasPermission(View.java:503) at hudson.model.ViewGroupMixIn.getViews(ViewGroupMixIn.java:115) at jenkins.model.Jenkins.getViews(Jenkins.java:1370) at hudson.views.OtherViewsFilter.getAllViews(OtherViewsFilter.java:148) at hudson.views.UnclassifiedJobsFilter.doFilter(UnclassifiedJobsFilter.java:27) at hudson.views.AbstractIncludeExcludeJobFilter.filter(AbstractIncludeExcludeJobFilter.java:57) at hudson.model.ListView.getItems(ListView.java:162) at hudson.model.ListView.getItems(ListView.java:58) Using Other Views filter, I'm getting a stack overflow error after update to Jenkins 1.459 -- Key: JENKINS-13464 URL: https://issues.jenkins-ci.org/browse/JENKINS-13464 Project: Jenkins Issue Type: Bug Components: sectioned-view, view-job-filters Reporter: Vincent Latombe Assignee: Jacob Robertson Priority: Blocker Attachments: StackOverflow.txt Due to https://github.com/jenkinsci/jenkins/commit/85e13303f8cfbebeb7dab347fda8ccf4069070b6 , any view using Other Views filter now gets a StackOverflowError. The reason is that it uses a wrong way of retrieving the referenced view, by getting first 'all' the views. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13464) Using Other Views filter, I'm getting a stack overflow error after update to Jenkins 1.459
[ https://issues.jenkins-ci.org/browse/JENKINS-13464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gergely Nagy updated JENKINS-13464: --- Attachment: stacktraceflow.txt Using Other Views filter, I'm getting a stack overflow error after update to Jenkins 1.459 -- Key: JENKINS-13464 URL: https://issues.jenkins-ci.org/browse/JENKINS-13464 Project: Jenkins Issue Type: Bug Components: sectioned-view, view-job-filters Reporter: Vincent Latombe Assignee: Jacob Robertson Priority: Blocker Attachments: StackOverflow.txt, stacktraceflow.txt Due to https://github.com/jenkinsci/jenkins/commit/85e13303f8cfbebeb7dab347fda8ccf4069070b6 , any view using Other Views filter now gets a StackOverflowError. The reason is that it uses a wrong way of retrieving the referenced view, by getting first 'all' the views. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4431) remote file operation failed because of OutOfMemoryError
[ https://issues.jenkins-ci.org/browse/JENKINS-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162913#comment-162913 ] Gergely Nagy commented on JENKINS-4431: --- ??bigger heap on the slave JVM?? Hmm, interesting - I started getting these after decreasing the _master_ Xmx from 1024m to 512m. BTW part of the reason for this was to diagnose frequent freezes @ 130%CPU. Was guessing it might be too using too much virtual memory, so ends up swapping.. not sure if this theory makes any sense, but that I might have traded freezing/hanging to a nice OOM: at least other jobs are intact now. remote file operation failed because of OutOfMemoryError Key: JENKINS-4431 URL: https://issues.jenkins-ci.org/browse/JENKINS-4431 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Platform: All, OS: All Reporter: nhb BUILD SUCCESSFUL Total time: 51 minutes 35 seconds Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed at hudson.FilePath.act(FilePath.java:672) at hudson.FilePath.act(FilePath.java:660) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:480) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:466) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:454) at hudson.model.Build$RunnerImpl.post2(Build.java:146) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:438) at hudson.model.Run.run(Run.java:1129) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:93) at hudson.model.Executor.run(Executor.java:122) Caused by: java.io.IOException: Remote call failed at hudson.remoting.Channel.call(Channel.java:524) at hudson.FilePath.act(FilePath.java:667) ... 12 more Caused by: java.lang.OutOfMemoryError: Java heap space -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4431) remote file operation failed because of OutOfMemoryError
[ https://issues.jenkins-ci.org/browse/JENKINS-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162913#comment-162913 ] Gergely Nagy edited comment on JENKINS-4431 at 5/18/12 12:59 PM: - ??bigger heap on the slave JVM?? Hmm, interesting - I started getting these after decreasing the _master_ Xmx from 1024m to 512m. BTW part of the reason for this was to diagnose frequent freezes @ 130%CPU. Was guessing it might be too using too much virtual memory, so ends up swapping.. not sure if this theory makes any sense, but that I might have traded freezing/hanging to a nice OOM: at least other jobs are intact now. Shall I increase the Slave Xmx? Could the above 2 problems related? Do you have any other suggestions to try? Thank you! was (Author: inger): ??bigger heap on the slave JVM?? Hmm, interesting - I started getting these after decreasing the _master_ Xmx from 1024m to 512m. BTW part of the reason for this was to diagnose frequent freezes @ 130%CPU. Was guessing it might be too using too much virtual memory, so ends up swapping.. not sure if this theory makes any sense, but that I might have traded freezing/hanging to a nice OOM: at least other jobs are intact now. remote file operation failed because of OutOfMemoryError Key: JENKINS-4431 URL: https://issues.jenkins-ci.org/browse/JENKINS-4431 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Platform: All, OS: All Reporter: nhb BUILD SUCCESSFUL Total time: 51 minutes 35 seconds Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed at hudson.FilePath.act(FilePath.java:672) at hudson.FilePath.act(FilePath.java:660) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:480) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:466) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:454) at hudson.model.Build$RunnerImpl.post2(Build.java:146) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:438) at hudson.model.Run.run(Run.java:1129) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:93) at hudson.model.Executor.run(Executor.java:122) Caused by: java.io.IOException: Remote call failed at hudson.remoting.Channel.call(Channel.java:524) at hudson.FilePath.act(FilePath.java:667) ... 12 more Caused by: java.lang.OutOfMemoryError: Java heap space -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4431) remote file operation failed because of OutOfMemoryError
[ https://issues.jenkins-ci.org/browse/JENKINS-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162913#comment-162913 ] Gergely Nagy edited comment on JENKINS-4431 at 5/18/12 1:03 PM: ??bigger heap on the slave JVM?? Hmm, interesting - I started getting these after decreasing the _master_ Xmx from 1024m to 512m. BTW part of the reason for this was to diagnose frequent freezes @ 130%CPU. Was guessing it might be too using too much virtual memory, so ends up swapping.. not sure if this theory makes any sense, but that I might have traded in the freezing/hanging for a nice OOM: at least other jobs are not affected now. Shall I increase the Slave Xmx? Could the above 2 problems be related? Do you have any other suggestions to try? Thank you! was (Author: inger): ??bigger heap on the slave JVM?? Hmm, interesting - I started getting these after decreasing the _master_ Xmx from 1024m to 512m. BTW part of the reason for this was to diagnose frequent freezes @ 130%CPU. Was guessing it might be too using too much virtual memory, so ends up swapping.. not sure if this theory makes any sense, but that I might have traded freezing/hanging to a nice OOM: at least other jobs are intact now. Shall I increase the Slave Xmx? Could the above 2 problems related? Do you have any other suggestions to try? Thank you! remote file operation failed because of OutOfMemoryError Key: JENKINS-4431 URL: https://issues.jenkins-ci.org/browse/JENKINS-4431 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Platform: All, OS: All Reporter: nhb BUILD SUCCESSFUL Total time: 51 minutes 35 seconds Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed at hudson.FilePath.act(FilePath.java:672) at hudson.FilePath.act(FilePath.java:660) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:480) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:466) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:454) at hudson.model.Build$RunnerImpl.post2(Build.java:146) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:438) at hudson.model.Run.run(Run.java:1129) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:93) at hudson.model.Executor.run(Executor.java:122) Caused by: java.io.IOException: Remote call failed at hudson.remoting.Channel.call(Channel.java:524) at hudson.FilePath.act(FilePath.java:667) ... 12 more Caused by: java.lang.OutOfMemoryError: Java heap space -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4431) remote file operation failed because of OutOfMemoryError
[ https://issues.jenkins-ci.org/browse/JENKINS-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162913#comment-162913 ] Gergely Nagy edited comment on JENKINS-4431 at 5/18/12 1:06 PM: ??bigger heap on the slave JVM?? Hmm, interesting - I started getting these after decreasing the _master_ Xmx from 1024m to 512m. BTW part of the reason for this was to diagnose frequent freezes @ 130%CPU. Was guessing it might be too using too much virtual memory, so ends up swapping.. not sure if this theory makes any sense, but that I might have traded in the freezing/hanging for a nice OOM: at least other jobs are not affected now. Shall I increase the slave Xmx (it's currently 1500m)? Could the above 2 problems be related? Do you have any other suggestions to try? Thank you! was (Author: inger): ??bigger heap on the slave JVM?? Hmm, interesting - I started getting these after decreasing the _master_ Xmx from 1024m to 512m. BTW part of the reason for this was to diagnose frequent freezes @ 130%CPU. Was guessing it might be too using too much virtual memory, so ends up swapping.. not sure if this theory makes any sense, but that I might have traded in the freezing/hanging for a nice OOM: at least other jobs are not affected now. Shall I increase the Slave Xmx? Could the above 2 problems be related? Do you have any other suggestions to try? Thank you! remote file operation failed because of OutOfMemoryError Key: JENKINS-4431 URL: https://issues.jenkins-ci.org/browse/JENKINS-4431 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Platform: All, OS: All Reporter: nhb BUILD SUCCESSFUL Total time: 51 minutes 35 seconds Recording test results ERROR: Failed to archive test reports hudson.util.IOException2: remote file operation failed at hudson.FilePath.act(FilePath.java:672) at hudson.FilePath.act(FilePath.java:660) at hudson.tasks.junit.JUnitResultArchiver.perform(JUnitResultArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:480) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:466) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:454) at hudson.model.Build$RunnerImpl.post2(Build.java:146) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:438) at hudson.model.Run.run(Run.java:1129) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:93) at hudson.model.Executor.run(Executor.java:122) Caused by: java.io.IOException: Remote call failed at hudson.remoting.Channel.call(Channel.java:524) at hudson.FilePath.act(FilePath.java:667) ... 12 more Caused by: java.lang.OutOfMemoryError: Java heap space -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12974) Use hard links if possible, for local copies
Gergely Nagy created JENKINS-12974: -- Summary: Use hard links if possible, for local copies Key: JENKINS-12974 URL: https://issues.jenkins-ci.org/browse/JENKINS-12974 Project: Jenkins Issue Type: Improvement Components: copyartifact Environment: *nix Reporter: Gergely Nagy Assignee: Alan Harder Priority: Minor Please consider using hard links on systems which allow it, for transfers on local filesystems. My motivation: save space. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12974) Use hard links if possible, for local copies
[ https://issues.jenkins-ci.org/browse/JENKINS-12974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gergely Nagy updated JENKINS-12974: --- Description: Please consider using hard links on systems which allow it, for transfers on local filesystems. This behaviour could be configurable. My motivation is to save space. Thanks for listening, let me know what you think.. and if I could help. was: Please consider using hard links on systems which allow it, for transfers on local filesystems. My motivation: save space. Use hard links if possible, for local copies Key: JENKINS-12974 URL: https://issues.jenkins-ci.org/browse/JENKINS-12974 Project: Jenkins Issue Type: Improvement Components: copyartifact Environment: *nix Reporter: Gergely Nagy Assignee: Alan Harder Priority: Minor Please consider using hard links on systems which allow it, for transfers on local filesystems. This behaviour could be configurable. My motivation is to save space. Thanks for listening, let me know what you think.. and if I could help. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
