[JIRA] (JENKINS-54912) TestResult-Section renders imagemap-div's to body
Title: Message Title Sven Appenrodt created an issue Jenkins / JENKINS-54912 TestResult-Section renders imagemap-div's to body Issue Type: Bug Assignee: Timothy Bingaman Attachments: body.PNG, section.PNG Components: sectioned-view-plugin Created: 2018-11-28 12:29 Environment: jenkins 2.153 (windows) plugin version 2.15 chromium webbrowser on ubuntu Priority: Major Reporter: Sven Appenrodt We derrived the SectionenView class in our own plugin to support updates via ajax refresh (used jelly-includes for minimum dependencies). The usecase is: we're showing some results on a monitor hanging on the wall which is connected with a small banana-pi. This one has no cpu power so normal jenkins-site-refresh will cause displaying blank sites for some millies. Using ajax refresh's will prevent this kind of flickering. We know, there are some memleaks mentionen in JENKINS-41100 for which we found some workarounds. But still, after some time the chromium browser crashes while displaying the site. We figured out: the DOM tree is growing larger and larger over the time until the browser is not able to handle it anymore. Reason: the TestResult-Section renders its view to the normal dom-position (see attachted screenshot: section.png) but for the clickable area overlay at the diagram-image is added as div container to the body element (see picture body.png). Problem: using ajax replaces the "section-div" with the new content, but cannot prevent adding additional divs to the body node. And the your plugin will add more... and more.. and more. The behavior is reproducable under
[JIRA] (JENKINS-41100) Memory leak in web interface (Javascript)
Title: Message Title
Sven Appenrodt edited a comment on JENKINS-41100
Re: Memory leak in web interface (_javascript_)
Maybe as fast workaround you can ignore the problem in IE and fix it for chrome and firefox by canging{code}if (Object.isUndefined(registry)) { CACHE.push(element); registry = Element.retrieve(element, 'prototype_event_registry', $H());}{code}to{code}if (Object.isUndefined(registry)) { if (!Prototype.Browser.IE) {CACHE.push(element); } registry = Element.retrieve(element, 'prototype_event_registry', $H());}{code}This will prevent the elements getting stored in the array for 'not IE' browser... BTW: there is an additional leak in Element.Storage in case of the element is not clearly deleted with the purge command. A workaround may be:{code} getStorage: function(element) {if (!(element = $(element))) return;//var uid;if (element === window) { uid = 0;} else { if (typeof element._prototypeUID === "undefined"){element._prototypeUID = Element.Storage.UID++; } uid = element._prototypeUID;} // --- //PATCHED: do not (!!) use Storage - see below//if (!Element.Storage[uid])// Element.Storage[uid] = $H();//return Element.Storage[uid]; // --- // PATCHED Storage is not cleaned correctly when not calling "purge" and leads to memleaks // for reusage we add the storage directly to the element if (!element._prototypeStorage) element._prototypeStorage = $H(); return element._prototypeStorage; },{code}
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-41100) Memory leak in web interface (Javascript)
Title: Message Title
Sven Appenrodt commented on JENKINS-41100
Re: Memory leak in web interface (_javascript_)
Maybe as fast workaround you can ignore the problem in IE and fix it for chrome and firefox by canging
if (Object.isUndefined(registry)) {
CACHE.push(element);
registry = Element.retrieve(element, 'prototype_event_registry', $H());
}
to
if (Object.isUndefined(registry)) {
if (!Prototype.Browser.IE) {
CACHE.push(element);
}
registry = Element.retrieve(element, 'prototype_event_registry', $H());
}
This will prevent the elements getting stored in the array for 'not IE' browser...
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-7347) Hudson should support absolute paths for junit xml
Title: Message Title Sven Appenrodt commented on JENKINS-7347 Re: Hudson should support absolute paths for junit xml The ticket is old, but i've the same problem. I'm trying to use a workaround, to link (junction) the buildpath to the workspace, but this is an awful way Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-20513) Sorting by jobname in "Sidebar widget (main)"
Title: Message Title Sven Appenrodt commented on JENKINS-20513 Re: Sorting by jobname in "Sidebar widget (main)" This feature we're currently using. But it is hard to get a summary about - lets say all jobs matching "12\d Run Job" in case of one is running at 9:00 AM and others at 9:00 PM where 50 other jobs are between them Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37624) Provide File-Parameter in parameterized-trigger-plugin
Title: Message Title Sven Appenrodt updated an issue Jenkins / JENKINS-37624 Provide File-Parameter in parameterized-trigger-plugin Change By: Sven Appenrodt Summary: Provide File-Parameter in parameterized-trigger-plugin Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37624) Provide File-Parameter
Title: Message Title Sven Appenrodt created an issue Jenkins / JENKINS-37624 Provide File-Parameter Issue Type: New Feature Assignee: huybrechts Components: parameterized-trigger-plugin Created: 2016/Aug/23 12:38 PM Environment: Jenkins v2.11 Plugin 2.31 Priority: Minor Reporter: Sven Appenrodt Our configuration: Job a triggers job B and transfers the build URL. Job B runs on a different slave that has the ability to send mails via ant (required because the cc and to properties are located in a xml file) After adding LDAP security anon has no rights so finally the anon user (in job B running in ant) is not able to get the console-output of the triggered job via URL. A file parameter deployed by the plugin may help, so job A can zip the console log and send it via file-parameter to job B - which now can attach it to the mail Add Comment
[JIRA] [active-directory-plugin] (JENKINS-34426) Changing project-based settings for AD-Groups shows error
Title: Message Title Sven Appenrodt commented on JENKINS-34426 Re: Changing project-based settings for AD-Groups shows error send you a mail. hope it will not be blocked by my company security settings Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [active-directory-plugin] (JENKINS-34426) Changing project-based settings for AD-Groups shows error
Title: Message Title Sven Appenrodt updated an issue Jenkins / JENKINS-34426 Changing project-based settings for AD-Groups shows error Change By: Sven Appenrodt Summary: Changing project-based settings for AD-Groups not possible shows error Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [active-directory-plugin] (JENKINS-34426) Changing project-based settings for AD-Groups not possible
Title: Message Title
Sven Appenrodt updated an issue
Jenkins / JENKINS-34426
Changing project-based settings for AD-Groups not possible
Change By:
Sven Appenrodt
After upgrading Active Directory plugin ver. 1.43 to 1.44 we cannot change any get a message "Failed to test the validity of the user name ..." on project based matrix settings, because our LDAP users and groups cannot be verified anymore.We have an AD-Setup with an entered domain only (in v1.43 this was enough) and the "Test" button returns "success"Do we have to configure something elses after the latest release?{code}hudson.plugins.active_directory.CacheAuthenticationException: Authentication failed caching user ; nested exception is com.google.common.util.concurrent.UncheckedExecutionException: java.lang.IllegalStateException: Recursive load at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:194) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:54) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:731) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName_(GlobalMatrixAuthorizationStrategy.java:336) at hudson.security.GlobalMatrixAuthorizationStrategy$DescriptorImpl.doCheckName(GlobalMatrixAuthorizationStrategy.java:314) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:320) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:163) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:124) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:233) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:135) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:59) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:126) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1482) at
[JIRA] [active-directory-plugin] (JENKINS-34426) Changing project-based settings for AD-Groups not possible
Title: Message Title Sven Appenrodt created an issue Jenkins / JENKINS-34426 Changing project-based settings for AD-Groups not possible Issue Type: Bug Assignee: Félix Belzunce Arcos Components: active-directory-plugin Created: 2016/Apr/25 10:46 AM Environment: Jenkins ver. 1.656 Active Directory plugin ver. 1.44 Priority: Critical Reporter: Sven Appenrodt After upgrading Active Directory plugin ver. 1.43 to 1.44 we cannot change any project based matrix settings, because our LDAP users and groups cannot be verified anymore. We have an AD-Setup with an entered domain only (in v1.43 this was enough) and the "Test" button returns "success" Do we have to configure something elses after the latest release? hudson.plugins.active_directory.CacheAuthenticationException: Authentication failed caching user ; nested exception is com.google.common.util.concurrent.UncheckedExecutionException: java.lang.IllegalStateException: Recursive load at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:194) at
[JIRA] [active-directory-plugin] (JENKINS-34426) Changing project-based settings for AD-Groups not possible
Title: Message Title Sven Appenrodt updated an issue Jenkins / JENKINS-34426 Changing project-based settings for AD-Groups not possible Change By: Sven Appenrodt Environment: Windows 2012 Server Jenkins ver. 1.656Active Directory plugin ver. 1.44 Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [subversion-plugin] (JENKINS-27265) SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' )
Title: Message Title Sven Appenrodt commented on JENKINS-27265 Re: SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' ) We have a Jenkins cloud using several Jenkins installations (different partys) with different slaves (limited system resources with high resource using jobs). On all machines we have to manage the systemcredetials for using cmd line svn-actions (e.g. by cmdline or java-tools) so maintain svn credentials in the system (cmdlinetools, browser etc) is a high efford. Doing this in Jenkins too will increase the efford... Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [subversion-plugin] (JENKINS-27265) SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' )
Title: Message Title Sven Appenrodt updated an issue Jenkins / JENKINS-27265 SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' ) Change By: Sven Appenrodt Priority: Major Minor Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [subversion-plugin] (JENKINS-27265) SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' )
Title: Message Title Sven Appenrodt commented on JENKINS-27265 Re: SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' ) Suggestion is: use a cmdline tool or tortoise to ensure your system has access to your subversion repository. install jenkins, add the subversion plugin and do not store any credetinals In my installation an error occured (see image) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [subversion-plugin] (JENKINS-27265) SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' )
Title: Message Title Sven Appenrodt edited a comment on JENKINS-27265 Re: SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' ) Suggestionis:useacmdlinetoolortortoisetoensureyoursystemhasaccesstoyoursubversionrepository.installjenkins,addthesubversionpluginanddo*not*storeanycredetinals (injenkins) Inmyinstallationanerroroccured(seeimage) Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [subversion-plugin] (JENKINS-27265) SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' )
Title: Message Title Sven Appenrodt updated an issue Jenkins / JENKINS-27265 SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' ) Change By: Sven Appenrodt Attachment: credentials-error.png Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [extensible-choice-parameter-plugin] (JENKINS-22222) Check variable names as Jenkins core expands
Title: Message Title Sven Appenrodt closed an issue as Fixed Works perfect. Thanks Jenkins / JENKINS-2 Check variable names as Jenkins core expands Change By: Sven Appenrodt Status: Resolved Closed Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [extensible-choice-parameter-plugin] (JENKINS-28473) Request: option to insert elements to position 0 instead of appending them
Title: Message Title Sven Appenrodt created an issue Jenkins / JENKINS-28473 Request: option to insert elements to position 0 instead of appending them Issue Type: New Feature Assignee: Unassigned Components: extensible-choice-parameter-plugin Created: 19/May/15 9:02 AM Priority: Trivial Reporter: Sven Appenrodt When using option allow add edited value with default top most value it would be nice to have a configuration to insert the edited value as first element, instead of adding it at the bottom of the list. Might be helpful to have the newest value as default Add Comment
[JIRA] [subversion-plugin] (JENKINS-27265) SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' )
Sven Appenrodt created JENKINS-27265 SvnPlugin ignores system credentials (svn: E175002: SSL handshake failed: Received fatal alert: handshake_failure ) Issue Type: Bug Assignee: Unassigned Components: subversion-plugin Created: 06/Mar/15 11:55 AM Description: Prerequirements: Windows 7, connection with subversion via https (SSL) and server/client certificate (pk12 + crt). Accessing svn via client (e.g. tortoise or sliksvn) and store credentials Create job with SCM-Polling and empty credentials Observed: svn-plugin 2.4.5 Works perfect. "Missing" installed Jenkins-credentials are ignored and the system credentials, set by other clients, are used. svn-plugin 2.5 Does not work. svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' org.tmatesoft.svn.core.SVNException: svn: E175002: SSL handshake failed: 'Received fatal alert: handshake_failure' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:495) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:371) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:359) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:710) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1032) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:94) at hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:2282) at hudson.scm.SubversionSCM$ModuleLocation$DescriptorImpl.checkCredentialsId(SubversionSCM.java:3043) at hudson.scm.SubversionSCM$ModuleLocation$DescriptorImpl.doCheckCredentialsId(SubversionSCM.java:3016) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:298) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:161) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:96) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:121) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:249) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:686) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1494) at
[JIRA] [naginator-plugin] (JENKINS-19576) Build cause is not resetted after failure
Sven Appenrodt resolved JENKINS-19576 as Wont Fix Build cause is not resetted after failure Version 1.14 does not contain the line BUILD_CAUSE_NAGINATORCAUSE=true and the automatically added badges introcuced in 1.14 (or former) does not require the groovy script. Big problem for us: because of the missing NAGINATORCAUSE information we cannot determine if a job has been failed before. Waiting for the unreleased version (according to RN there will be some variables again) so if you like you can close this ticket. Change By: Sven Appenrodt (16/Feb/15 9:37 AM) Status: Open Resolved Resolution: WontFix 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] [envinject] (JENKINS-24777) Build parameter are not overwritten (v1.89 - 1.90
Sven Appenrodt
created JENKINS-24777
Build parameter are not overwritten (v1.89 - 1.90
Issue Type:
Bug
Assignee:
Gregory Boissinot
Components:
envinject
Created:
19/Sep/14 6:45 AM
Description:
Create a parameterized job
Add a textbox parameter (e.g. Comment = ABC newline BCD)
Add a build action: Inject environment variables, in the content field override Comment to e.g. ${WORKSPACE}
- Add a shell/winbatch an prompt 'Comment'
plugin version 1.89 console:
EnvInject - Variables injected successfully.
new comment value = ${WORKSPACE}
plugin version 1.90 console:
EnvInject - Variables injected successfully.
new comment value = ABC
Assume the property 'Comment' is not overwritten anymore.
My personal problem:
I want to give a multiline value via build parameter to an ANT but because of the newlines i permanently get a syntaxerror, so i decided to print te parameter to a file, and give the file to the ant instead.
Environment:
Win7
Jenkins 1.580
Project:
Jenkins
Priority:
Blocker
Reporter:
Sven Appenrodt
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] [envinject] (JENKINS-24777) Build parameter are not overwritten anymore (v1.89 - 1.90)
Sven Appenrodt
updated JENKINS-24777
Build parameter are not overwritten anymore (v1.89 - 1.90)
Change By:
Sven Appenrodt
(19/Sep/14 6:46 AM)
Summary:
Buildparameterarenotoverwritten
anymore
(v1.89-1.90
)
Description:
-Createaparameterizedjob-Addatextboxparameter(e.g.Comment=ABCnewlineBCD)-Addabuildaction:Injectenvironmentvariables,inthecontentfieldoverrideCommenttoe.g.$
{
WORKSPACE
}
-Addashell/winbatchanpromptCommentpluginversion1.89console:[EnvInject]-Variablesinjectedsuccessfully.newcommentvalue=${WORKSPACE}pluginversion1.90console:[EnvInject]-Variablesinjectedsuccessfully.newcommentvalue=ABCAssumethepropertyCommentisnotoverwrittenanymore.Mypersonalproblem:IwanttogiveamultilinevalueviabuildparametertoanANTbutbecauseofthenewlinesipermanentlygetasyntaxerror,soidecidedtoprintteparametertoafile,andgivethefiletotheantinstead.
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] [core] (JENKINS-24353) UI Themes plugin
Sven Appenrodt edited a comment on JENKINS-24353 UI Themes plugin One of the topics: overlapping vs. line wrap in build history. May can be configured as "no wrap and clipped" (see JENKINS-23999) 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] [core] (JENKINS-23829) Layout: Job history may overlap main job status
Sven Appenrodt updated JENKINS-23829 Layout: Job history may overlap main job status Wow - the new version (1.576) looks... lets say - awful. Sorry. I don't reopen the bug because maybe it's only me who want's the no-wrap back Suggest to use no-wrap in combination with overflow styles. When i edit the div class="container-fluid pane-frame" id="buildHistory" with firebug to div class="container-fluid pane-frame no-wrap" id="buildHistory" style="overflow-x:scroll" it looks better in my eyes. (see screenshot). Maybe you can think about this solution?? Change By: Sven Appenrodt (20/Aug/14 11:46 AM) Attachment: suggestion-nowrap-with-overflow.png 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] [core] (JENKINS-23829) Layout: Job history may overlap main job status
Sven Appenrodt
commented on JENKINS-23829
Layout: Job history may overlap main job status
@Daniel - Downloaded version 1.568 and i can see the side-panel was enlarged.
I think it depends on the former definition:
td width="10%" id="side-panel"
and css:
#side-panel {
padding: 4px;
width: 220px;
}
but i'm not an expert in html/css. I already made some experiments with the current jenkins-version like: change class col-lg-6 from width to min-width and col-lg-18 to max-width - and it worked - but i assume this has too much influence to the other pages (which i didn't tests because of the hard configuration with 'firebug').
@Tom
Sorry - maybe "awful" was a to hard word. The was supposed to tame it... I didn't reopen the ticket because it is closed correctly - so normally i should open a new task with a new description, linking this one. And i assume this will happen (and not by me). If you like we can discuss this via mail - i'm open to everything
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] [core] (JENKINS-23829) Layout: Job history may overlap main job status
Sven Appenrodt updated JENKINS-23829 Layout: Job history may overlap main job status Change By: Sven Appenrodt (20/Aug/14 1:39 PM) Attachment: side-panel.1568.PNG 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] [core] (JENKINS-23829) Layout: Job history may overlap main job status
Sven Appenrodt
edited a comment on JENKINS-23829
Layout: Job history may overlap main job status
@Daniel - Downloaded version 1.568 and i can see the side-panel was enlarged. (see screenshot)
I think it depends on the former definition:
td width="10%" id="side-panel"
and css:
#side-panel {
padding: 4px;
width: 220px;
}
but i'm not an expert in html/css. I already made some experiments with the current jenkins-version like: change class col-lg-6 from width to min-width and col-lg-18 to max-width - and it worked - but i assume this has too much influence to the other pages (which i didn't tests because of the hard configuration with 'firebug').
@Tom
Sorry - maybe "awful" was a to hard word. The was supposed to tame it... I didn't reopen the ticket because it is closed correctly - so normally i should open a new task with a new description, linking this one. And i assume this will happen (and not by me). If you like we can discuss this via mail - i'm open to everything
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] [maven] (JENKINS-24198) Frequent Stackoverflow
Sven Appenrodt commented on JENKINS-24198 Frequent Stackoverflow I don't know if it's the same root cause but i get a StackOverflow too. Win7, Jenkins 1.575 - latest plugins. Downgrade to 1.574 with same plugins works perfect... The strange thing - it only affects some freestyle projects. ... Caused by: java.lang.StackOverflowError at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:282) at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:104) at java.io.PrintStream.write(PrintStream.java:430) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203) at java.io.Writer.write(Writer.java:140) at java.util.logging.StreamHandler.publish(StreamHandler.java:192) at java.util.logging.ConsoleHandler.publish(ConsoleHandler.java:88) at java.util.logging.Logger.log(Logger.java:478) at java.util.logging.Logger.doLog(Logger.java:500) at java.util.logging.Logger.log(Logger.java:589) at hudson.model.RunMap.retrieve(RunMap.java:235) at hudson.model.RunMap.retrieve(RunMap.java:56) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:671) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:470) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:547) at jenkins.model.lazy.LazyBuildMixIn.getBuildByNumber(LazyBuildMixIn.java:235) at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:956) at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:144) at hudson.model.Cause$UpstreamCause.onLoad(Cause.java:189) at hudson.model.CauseAction.onLoad(CauseAction.java:124) at hudson.model.Run.onLoad(Run.java:342) at hudson.model.RunMap.retrieve(RunMap.java:219) at hudson.model.RunMap.retrieve(RunMap.java:56) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:671) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:470) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:547) at jenkins.model.lazy.LazyBuildMixIn.getBuildByNumber(LazyBuildMixIn.java:235) at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:956) at hudson.model.AbstractProject.getBuildByNumber(AbstractProject.java:144) at hudson.model.Cause$UpstreamCause.onLoad(Cause.java:189) at hudson.model.CauseAction.onLoad(CauseAction.java:124) at hudson.model.Run.onLoad(Run.java:342) at hudson.model.RunMap.retrieve(RunMap.java:219) at hudson.model.RunMap.retrieve(RunMap.java:56) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:688) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:671) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:470) at jenkins.model.lazy.AbstractLazyLoadRunMap.getByNumber(AbstractLazyLoadRunMap.java:547) at jenkins.model.lazy.LazyBuildMixIn.getBuildByNumber(LazyBuildMixIn.java:235) ... 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] [groovy-postbuild] (JENKINS-23999) UI problem: build history with groovy post build data overlapps permalinks
Sven Appenrodt created JENKINS-23999 UI problem: build history with groovy post build data overlapps permalinks Issue Type: Bug Assignee: wolfs Components: groovy-postbuild, ui-changes Created: 28/Jul/14 8:09 AM Description: Precondition: 1) Create a job containing a groovy-post-build step and add a text-badge with a text of 20-40char-length 2) run the job (ping or echo - doesn't care 3) open je job-overwiew-page (the one with the build history on the left side and the permalinks in the middle Expected: normal display of all elements Actual: the build history widget expands the box because of the text badge, but the main-page part is not made smaller, so the build history overlapps the main-part. Same with configuration page. Environment: Jenkins ver. 1.574 Groovy Postbuild Plugin 1.10 Firefox 30.0 Internet Explorer 9 Win7 x64 Project: Jenkins Priority: Minor Reporter: Sven Appenrodt 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] [next-executions] (JENKINS-23397) Filter possible next executions with Job-Generators
Sven Appenrodt
created JENKINS-23397
Filter possible next executions with Job-Generators
Issue Type:
Improvement
Assignee:
Ignacio Albors
Components:
next-executions
Created:
11/Jun/14 7:33 AM
Description:
First of all - thanks for the "possible next executions" widget - this was a really good idea.
But:
This widget also shows Job-Generators (see plugin https://wiki.jenkins-ci.org/display/JENKINS/Job+Generator+Plugin)
These jobs are listed in the next execution widget but they will never be executed by SCM-polls.
Please provide a filter like:
if(topLevelItem instanceof AbstractProject !isGenerator(topLevelItem)){
...
}
where
private boolean isGenerator(TopLevelItem item){
String gn = "org.jenkinsci.plugins.jobgenerator.JobGenerator";
return project.getClass().getQualifiedName().equals(gn)
}
or something like that.
Environment:
plugin 1.0.7
Jenkins 1.567
Project:
Jenkins
Priority:
Minor
Reporter:
Sven Appenrodt
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] [next-executions] (JENKINS-23397) Filter possible next executions with Job-Generators
Sven Appenrodt commented on JENKINS-23397 Filter possible next executions with Job-Generators No - you are right. My configuration was to configure the timeout in the job without SCM-data. After calling the generator by groovy i added scm-url and workingfolders. So it looks like the generator is not running. So finally - it is a misconfiguration of my job. Thanks for fast supply 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] [build-user-vars] (JENKINS-23269) NPE when getting upstreambuild after starting a rebuild
Sven Appenrodt
created JENKINS-23269
NPE when getting upstreambuild after starting a rebuild
Issue Type:
Bug
Assignee:
Unassigned
Components:
build-user-vars
Created:
02/Jun/14 11:44 AM
Description:
Precondition:
install rebuild plugin
create a Job A that triggers a Job B
Job A has a log rotation set to "keep 2 builds", Job B has no log rotation set
run Job A several times (let say 5 times)
Actual:
Job A - history: build 4 and build 5
Job B - history: build 1,2,3,4 and 5
Action:
Select Job B build 2 and run "rebuild" via "rebuild plugin"
Currently:
java.lang.NullPointerException
at org.jenkinsci.plugins.builduser.BuildUser.makeUserBuildVariables(BuildUser.java:73)
at org.jenkinsci.plugins.builduser.BuildUser.makeUserBuildVariables(BuildUser.java:77)
at org.jenkinsci.plugins.builduser.BuildUser.makeBuildVariables(BuildUser.java:64)
at hudson.model.AbstractBuild.getBuildVariables(AbstractBuild.java:984)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
Problem:
org.jenkinsci.plugins.builduser.BuildUser.makeUserBuildVariables(Run build, MapString, String variables)
// If build has been triggered form an upstream build, get UserCause from there to set user build variables
Cause.UpstreamCause upstreamCause = (Cause.UpstreamCause) build.getCause(Cause.UpstreamCause.class);
if (upstreamCause != null) {
Job job = Jenkins.getInstance().getItemByFullName(upstreamCause.getUpstreamProject(), Job.class);
Run upstream = job.getBuildByNumber(upstreamCause.getUpstreamBuild());
makeUserBuildVariables(upstream, variables);
}
The problem is that the upstreamCause is checked for null, but in case of logrotation (or maybe also an manual delete) has deleted the upstream-run - the variable "upstream" is not checked to null. That leads to a recursive-call where method-argument "build" is null which is also not checked.
Suggestion:
either return on "build == null"
or check Run upstream = job.getBuildByNumber(upstreamCause.getUpstreamBuild()); for null too
Environment:
Plugin v1.3
Project:
Jenkins
Priority:
Major
Reporter:
Sven Appenrodt
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] [build-user-vars] (JENKINS-23269) NPE when getting upstreambuild after starting a rebuild
Sven Appenrodt resolved JENKINS-23269 as Duplicate NPE when getting upstreambuild after starting a rebuild Duplicate to JENKINS-22974. Found this one too late - sry Change By: Sven Appenrodt (02/Jun/14 12:03 PM) Status: Open Resolved Resolution: Duplicate 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] [core] (JENKINS-15799) loosing matrix sub builds
Sven Appenrodt commented on JENKINS-15799 loosing matrix sub builds Never lost any subbuild again so i suggest to close this ticket and the related one. If there are still problems, we can reopen this bug or create a new one. 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] [extensible-choice-parameter] (JENKINS-22282) Extensible choice parameter greyed out in Internet Explorer
Sven Appenrodt commented on JENKINS-22282 Extensible choice parameter greyed out in Internet Explorer Did you also test it with reduced rights? I assume the reporter has logged on with a user, which has permission to run a build, but not to configure the job (or jenkins-settings). It's just an idea... 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] [extensible-choice-parameter] (JENKINS-22222) Extend name pattern to use dots too
Sven Appenrodt commented on JENKINS-2 Extend name pattern to use dots too Thanks for asking. I assume there is no guideline but asking doesn't cost anything than a little time In that case - can we make a compromise that you continue checking the names but display the result (if any) as warning? Maybe many users will missinterpret your "error", but a warning like "use bash like names a-zA-Z_-, there might be problems with using this parameter in actions" or something like this might be better. It's just to warn the user using that kind of name, not to forbid it. Thanks a lot 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] [extensible-choice-parameter] (JENKINS-22222) Extend name pattern to use dots too
Sven Appenrodt created JENKINS-2 Extend name pattern to use dots too Issue Type: Task Affects Versions: current Assignee: Unassigned Components: extensible-choice-parameter Created: 17/Mar/14 1:09 PM Description: After the parameterized trigger plugin wants to exchange all choices to extensible choices we have to change many properties in our jobs. But that's OK. Problem: Because of many of our properties containing dots we have to overwork half of our build process. Suggestion: Please check if the name of a property can contain . too. Environment: rely on https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin#ParameterizedTriggerPlugin-Backwardcompatibilitywithversion2.22 Project: Jenkins Priority: Minor Reporter: Sven Appenrodt 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] [extensible-choice-parameter] (JENKINS-22222) Extend name pattern to use dots too
Sven Appenrodt commented on JENKINS-2 Extend name pattern to use dots too Hint: getting triggerd by the parameterized trigger plugin whith having a choice "foo.bar" works, only the validation check for this field fails. Didn't tested accessing the choice via e.g. groovy... 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] [nodelabelparameter] (JENKINS-21828) java.lang.IllegalArgumentException: Malformed \uxxxx encoding.
Sven Appenrodt created JENKINS-21828 java.lang.IllegalArgumentException: Malformed \u encoding. Issue Type: Bug Affects Versions: current Assignee: Dominik Bartholdi Components: nodelabelparameter Created: 17/Feb/14 11:02 AM Description: Message for locale de contains "ü" See: file:/...Jenkins/plugins/nodelabelparameter/WEB-INF/lib/nodelabelparameter.jar!/org/jvnet/jenkins/plugins/nodelabelparameter/Messages_de.properties Property: NodeListBuildParameterFactory.skippOfflineNode This causes any donwnstream project triggered on any slave/master to fail with an exception: FATAL: Malformed \u encoding. java.lang.IllegalArgumentException: Malformed \u encoding. at java.util.Properties.loadConvert(Properties.java:552) at java.util.Properties.load0(Properties.java:375) at java.util.Properties.load(Properties.java:325) at java.util.PropertyResourceBundle.init(PropertyResourceBundle.java:111) at org.jvnet.localizer.ResourceBundleHolder$ResourceBundleImpl.init(ResourceBundleHolder.java:114) at org.jvnet.localizer.ResourceBundleHolder.get(ResourceBundleHolder.java:88) at org.jvnet.localizer.ResourceBundleHolder.get(ResourceBundleHolder.java:102) at org.jvnet.localizer.ResourceBundleHolder.format(ResourceBundleHolder.java:139) at org.jvnet.jenkins.plugins.nodelabelparameter.Messages.LabelBadgeAction_label_tooltip_node(Messages.java:101) at org.jvnet.jenkins.plugins.nodelabelparameter.LabelParameterValue.addBadgeToBuild(LabelParameterValue.java:253) at org.jvnet.jenkins.plugins.nodelabelparameter.LabelParameterValue.createBuildWrapper(LabelParameterValue.java:205) at hudson.model.ParametersAction.createBuildWrappers(ParametersAction.java:78) at hudson.model.Build$BuildExecution.doRun(Build.java:151) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:565) at hudson.model.Run.execute(Run.java:1670) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Please replace the "ü" with the correspondung \uxxx code. Thx Environment: Jenkins version: 1.550 nodelabel parameter plugin version: 1.5.0 Project: Jenkins Priority: Critical Reporter: Sven Appenrodt 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] [nodelabelparameter] (JENKINS-21828) java.lang.IllegalArgumentException: Malformed \uxxxx encoding.
Sven Appenrodt updated JENKINS-21828 java.lang.IllegalArgumentException: Malformed \u encoding. There are 2 additional problems in this file, so please diff and/or use this one. Change By: Sven Appenrodt (17/Feb/14 12:25 PM) Attachment: Messages_de.properties 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] [matrix] (JENKINS-16638) child builds going missing from matrix jobs
Sven Appenrodt commented on JENKINS-16638 child builds going missing from matrix jobs Upgraded to Jenkins version 1.539 several days (or months ago). LogRotation is set to X days and Y builds and another job is set to Y builds only. Problem does not occur anymore on both machines. Please can anyone confirm this? Then also bug 15799 can be set to "fixed".. 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] [core] (JENKINS-15799) loosing matrix sub builds
Sven Appenrodt commented on JENKINS-15799 loosing matrix sub builds Upgraded to Jenkins version 1.539 several days (or months ago). LogRotation is set to X days and Y builds and another job is set to Y builds only. Problem does not occur anymore on both machines. Please can anyone confirm this? 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] [prioritysorter] (JENKINS-8597) Deal with matrix builds better
Sven Appenrodt commented on JENKINS-8597 Deal with matrix builds better No i don't. And no idea Sorry. And i afraid it will not be integrated the next time because the last action of "bklarson" is older than 1 year... 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] [next-executions] (JENKINS-20513) Sorting by jobname in Sidebar widget (main)
Sven Appenrodt assigned JENKINS-20513 to Ignacio Albors Sorting by jobname in Sidebar widget (main) Change By: Sven Appenrodt (11/Nov/13 11:46 AM) Assignee: IgnacioAlbors 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] [next-executions] (JENKINS-20513) Sorting by jobname in Sidebar widget (main)
Sven Appenrodt created JENKINS-20513 Sorting by jobname in Sidebar widget (main) Issue Type: New Feature Assignee: Unassigned Components: next-executions Created: 11/Nov/13 11:42 AM Description: The next executions in the sidebar widget are sorted by next excution time. If you have many time-triggered jobs and you want to find a special one, the search for it is hard. All our jobs have prefixes like H for helper, T for test builds R for release builds and so on. It would be helpful to sort the widget by name for faster search and better overview. Environment: Jenkins ver. 1.538 next-executions v1.0.5 Project: Jenkins Priority: Minor Reporter: Sven Appenrodt 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] [core] (JENKINS-16660) Environment variable replacement/resolving
Sven Appenrodt commented on JENKINS-16660 Environment variable replacement/resolving It is Thx 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] [envinject] (JENKINS-16882) Job-B ${WORKSPACE} has value of Job-A WORKSPACE
Sven Appenrodt
commented on JENKINS-16882
Job-B ${WORKSPACE} has value of Job-A WORKSPACE
Seems the problem can be reproduced only after the second run (but i'm not sure)
The biggest problem is, the workspace of each job triggered by the fsp will be overwritten permanently. Example:
Job A (fstrigger) - Job B - Job C
Job 1 (normal time trigger) - Job 2 - Job C
It doesnt matter if Job C is triggered by Job A or 1 - the WORKSPACE variable is set to "workspace\Job A" everytime.
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] [logging] (JENKINS-7773) Matrix sub jobs do not keep n+1 builds, when n is specified.
Sven Appenrodt updated JENKINS-7773 Matrix sub jobs do not keep n+1 builds, when n is specified. Its not as easy. I definied a matrixbuild keeping builds 28 days. The matrix contains 8x8 fields. The main job keeps all builds 28 days. But all subjobs just 4 days. Each subbuild can have up to 30MB logs so we cannot switch off logrotation. - set prio to major Change By: Sven Appenrodt (25/Apr/13 12:30 PM) Environment: Jenkinsver.1.512 Priority: Minor Major Component/s: logging 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] [naginator] (JENKINS-17626) Retry count resets when job with other parameters is successful
Sven Appenrodt created JENKINS-17626 Retry count resets when job with other parameters is successful Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: naginator Created: 16/Apr/13 8:11 AM Description: Create a parameterized job, append naginator plugin, set fix retry time to e.g. 2 minutes and retry count to 3. Then and add a short action which can fail the build depending on the parametervalue. 1) Launch the job with a parametervalue which causes the job to fail. 2) Wait until naginator has started the job again (1. retry) 3) Wait until naginator has started the job again (2. retry) 4) during the waiting time for the third retry, start the job with parametervalue for a successful build. 5) Wait until naginator has started the first (failing) job again (3. retry) Expected: The first job which fails all the time will not be started again after the third retry. Actually: Seems the successful build in (4) was resetting the count of (3) because the failed job is rebuild two times again. Environment: jenkins 1.510, naginator plugin v 1.8 Project: Jenkins Priority: Minor Reporter: Sven Appenrodt 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-8597) Deal with matrix builds better
Sven Appenrodt
edited a comment on JENKINS-8597
Deal with matrix builds better
I agree. Nice idea to sort the prio of jobs but we're handling with many axis-jobs which can run on a slave too, so reducing their prio will improve our builds because the slave will be used better.
To fix the problem the code has to be fixed in the following way.
In PrioritySorterQueue.java the method getPriority has to be changed
from:
..
AbstractProject?, ? project = (AbstractProject?, ?) buildable.task;
priority = project.getProperty(PrioritySorterJobProperty.class);
..
to:
..
AbstractProject?, ? project = (AbstractProject?, ?) buildable.task;
PrioritySorterJobProperty priority = null;
if (project instanceof MatrixConfiguration) {
ItemGroup? parent = project.getParent();
if (parent instanceof AbstractProject?, ?){
priority = ((AbstractProject?, ?)(parent)).getProperty(PrioritySorterJobProperty.class);
}
} else {
priority = project.getProperty(PrioritySorterJobProperty.class);
}
..
Then the priority from the axises are resolved from the parent matrix because the axis itself does not have the property attached.
According to the higher number - job starts first - problem the comparitor (same java-file) has to be changed
to:
..
public int compare(BuildableItem arg0, BuildableItem arg1) {
// Note that we sort these backwards because we want to return
// higher-numbered items first.
Integer priority1 = getPriority(arg0);
return priority1.compareTo(getPriority(arg1));
}
..
then the comment is correct - jobs with higher numbers are started first...
And also the adjusting-method has to be changed to adjustedPriority -= ... but this i've never tested
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-8597) Deal with matrix builds better
Sven Appenrodt
edited a comment on JENKINS-8597
Deal with matrix builds better
I agree. Nice idea to sort the prio of jobs but we're handling with many axis-jobs which can run on a slave too, so reducing their prio will improve our builds because the slave will be used better.
To fix the problem the code has to be fixed in the following way.
In PrioritySorterQueue.java the method getPriority has to be changed
from:
..
AbstractProject?, ? project = (AbstractProject?, ?) buildable.task;
priority = project.getProperty(PrioritySorterJobProperty.class);
..
to:
..
AbstractProject?, ? project = (AbstractProject?, ?) buildable.task;
PrioritySorterJobProperty priority = null;
if (project instanceof MatrixConfiguration) {
ItemGroup? parent = project.getParent();
if (parent instanceof AbstractProject?, ?){
priority = ((AbstractProject?, ?)(parent)).getProperty(PrioritySorterJobProperty.class);
}
} else {
priority = project.getProperty(PrioritySorterJobProperty.class);
}
..
Then the priority from the axises are resolved from the parent matrix because the axis itself does not have the property attached.
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-16660) Environment variable replacement/resolving
Sven Appenrodt created JENKINS-16660 Environment variable replacement/resolving Issue Type: Bug Assignee: Unassigned Components: core Created: 06/Feb/13 10:17 AM Description: The function hudson.Util.replaceMacro(String, ...) does not resolve properties with '.' E.g. many java properties or build parameters do/can have a dot in their names which cannot be expanded by this method which seems to be used by some plugins. Please add the dot to hudson.Util.VARIABLE pattern. Thx Environment: Jenkins ver. 1.500 Project: Jenkins Priority: Trivial Reporter: Sven Appenrodt 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-16661) Rebuild plugin crashes when used in conjuction with Random String Parameter Plugin
Sven Appenrodt created JENKINS-16661 Rebuild plugin crashes when used in conjuction with Random String Parameter Plugin Issue Type: Bug Affects Versions: current Assignee: ragesh_nair Components: parameters, rebuild Created: 06/Feb/13 10:48 AM Description: Running a parameterized build containing a RandomStringParameter and hitting rebuild-action it fails with an exception: Status Code: 500 Exception: org.apache.commons.jelly.JellyTagException: file:/D:/Jenkins/plugins/rebuild/WEB-INF/classes/com/sonyericsson/rebuild/RebuildAction/parameterized.jelly:55:75: st:include No page found 'RandomStringParameterValue.jelly' for class com.sonyericsson.rebuild.RebuildAction Stacktrace: javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: file:/D:/Jenkins/plugins/rebuild/WEB-INF/classes/com/sonyericsson/rebuild/RebuildAction/parameterized.jelly:55:75: st:include No page found 'RandomStringParameterValue.jelly' for class com.sonyericsson.rebuild.RebuildAction at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) ... Environment: Jenkins ver. 1.499 Project: Jenkins Priority: Major Reporter: Sven Appenrodt 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-8597) Deal with matrix builds better
Sven Appenrodt commented on JENKINS-8597 Deal with matrix builds better I agree. Nice idea to sort the prio of jobs but we're handling with many axis-jobs which can run on a slave too, so reducing their prio will improve our builds because the slave will be used better. My Test: Job1(100) triggers Job2 Job2 is Matrix with 20 axises doing sleep for a minute+-some random seconds each Job3(100) triggers Job2 too Result: even if Job2 has prio 50 or 150, Job 3 is the last one in the build queue. Expected: after the first axis-job has finished, lauch Job3 instead of the next axis-job. 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-8597) Deal with matrix builds better
Sven Appenrodt edited a comment on JENKINS-8597 Deal with matrix builds better I agree. Nice idea to sort the prio of jobs but we're handling with many axis-jobs which can run on a slave too, so reducing their prio will improve our builds because the slave will be used better. My Test: Job1(100) triggers Job2 Job2(xx) is Matrix with 20 axises doing sleep for a minute+-some random seconds each Job3(100) triggers Job2 too Result: even if Job2 has prio 50 or 150, Job 3 is the last one in the build queue. Expected: after the first axis-job has finished, lauch Job3 instead of the next axis-job. 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-8597) Deal with matrix builds better
Sven Appenrodt edited a comment on JENKINS-8597 Deal with matrix builds better I agree. Nice idea to sort the prio of jobs but we're handling with many axis-jobs which can run on a slave too, so reducing their prio will improve our builds because the slave will be used better. My Test: Job1(100) triggers Job2 Job2(xx) is Matrix with 20 axises doing sleep for a minute+-some random seconds each Job3(100) triggers Job2 too Result: even if Job2 has prio 50 or 150, Job 3 is the last one in the build queue. Expected: after the first axis-job has finished, lauch Job3 instead of the next axis-job. Edit: OK - patching the config.xml in each subconfiguration is working but just a workaround... 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-6230) Display job-description also on parameters page when starting a parametrized job
Sven Appenrodt commented on JENKINS-6230 Display job-description also on parameters page when starting a parametrized job This improvement is useful fur me too. I'm working with different security-settings and different 'launcher-jobs', but for some jobs it will be nice having the html-based job-description when launching the build (e.g. red letter hint). But i don't know if the prio should be Major 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-13972) Concurrent matrix builds abort
Sven Appenrodt updated JENKINS-13972 Concurrent matrix builds abort Change By: Sven Appenrodt (15/Jun/12 6:56 AM) Priority: Minor Major 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-13972) Concurrent matrix builds abort
Sven Appenrodt commented on JENKINS-13972 Concurrent matrix builds abort This seems to be a side effect of the fix of issue 6747. The problem only appears when starting the matrix jobs in concurrent mode. Starting the job in serial mode will not abort the axis-jobs Next problem: the workaround given in issue 6747 is not working anymore. So there is no possibility to patch the job to run them concurrent anymore. 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-6747) Support concurrent runs of matrix builds
[ https://issues.jenkins-ci.org/browse/JENKINS-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162530#comment-162530 ] Sven Appenrodt commented on JENKINS-6747: - OK - seems, this problem ist not popular so i tested several changes in the configuration. Seems it is a display-problem only. If you browse to the job-configuration, open all config.xml files (also in all!! sub folders) and change the entry: concurrentBuildfalse/concurrentBuild to 'true' then you can use parallel builds with this kind of job, after reloading the configuration. Maybe using this knowlege, this bug can be handled, so the configurations can be saved in a official way... Support concurrent runs of matrix builds Key: JENKINS-6747 URL: https://issues.jenkins-ci.org/browse/JENKINS-6747 Project: Jenkins Issue Type: Improvement Components: concurrent-build Reporter: Eric Smalling Assignee: Kohsuke Kawaguchi I'd like to be able to run matrix builds in parallel, currently that option doesn't appear in the configuration so I'm assuming it's not implemented yet. :) -- 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-6747) Support concurrent runs of matrix builds
[ https://issues.jenkins-ci.org/browse/JENKINS-6747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159386#comment-159386 ] Sven Appenrodt commented on JENKINS-6747: - Indeed - the problem is not fixed at all. Running a multi-configuration task having 1 user defined axis with 2 values (e.g. job1 and job2) executing a permanent-ping to localhost will block the same, again started task. There are enough build slots available. For us it will save much time, because our builds currently starting two processes and each uses only a single CPU's on a I7-machine and we need to build two of them. That means - we have enough system resources (CPU-time and RAM) to start the second task parallel... Please, can you have a look at the problem? Thx Support concurrent runs of matrix builds Key: JENKINS-6747 URL: https://issues.jenkins-ci.org/browse/JENKINS-6747 Project: Jenkins Issue Type: Improvement Components: concurrent-build Reporter: Eric Smalling Assignee: Kohsuke Kawaguchi I'd like to be able to run matrix builds in parallel, currently that option doesn't appear in the configuration so I'm assuming it's not implemented yet. :) -- 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
