[JIRA] (JENKINS-15852) Unable to delete workspace
markewaite commented on JENKINS-15852 Unable to delete workspace Windows refuses to remove a directory which is busy, either because there is a file open in the directory, or a program is using that directory as its current working directory. One possible solution in this case is to choose to not clean the workspace from the git plugin, but rather perform the clean operation from within your build scripts where you can intentionally ignore this failure case. 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-16495) Saving global settings causes cross site request forgery option to be disabled
Youssuf ElKalay commented on JENKINS-16495 Saving global settings causes cross site request forgery option to be disabled The obvious fix to this is to modify the post-commit hook not to pass the crumb in the HTTP header which is what I've done but it would be nice to get this issue resolved. 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-16495) Saving global settings causes cross site request forgery option to be disabled
Youssuf ElKalay created JENKINS-16495 Saving global settings causes cross site request forgery option to be disabled Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 26/Jan/13 12:19 AM Description: If the "Prevent cross site forgery request exploit" option is selected in the "Configure global" security page and a change is made and saved on the global settings page - the cross site forgery prevention option is deactivated. This is causing issues with post-commit hooks that pass the API token as well as the crumb in the HTTP header when making RESTful calls to Jenkins. Environment: CentOS 6.3 x86-64 Jenkins 1.498 Tomcat 6 Java 6 Project: Jenkins Labels: core security Priority: Minor Reporter: Youssuf ElKalay 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-16494) Jenkins Grails Plugin 1.6.3 does not install a runtime correctly
Dan Dowma created JENKINS-16494 Jenkins Grails Plugin 1.6.3 does not install a runtime correctly Issue Type: Bug Assignee: jeffg2one Attachments: build_failed.png, build_with_grails_war.png, grails_plugin_no_installer.png Components: grails Created: 25/Jan/13 10:26 PM Description: I'm attempting to install grails from the Jenkins Grails Plugin (1.6.3). The plugin seemed to install just fine. When I try to install a version of grails, it isn't working as I would expect. When I'm on the "Manage Jenkins"->"Configure System" screen, the Grails Plugin doesn't have a drop-down of grails versions to choose from when I attempt to install from mirrors. Instead I see a text box that I can type in (see my attached screen shot 'grails_plugin_no_installer.png', where the red arrow is pointing). As you can see from the screen shot, I also tried to install it directly from a binary archive. In both cases, after filling out the info as you see it and pressing the 'save' button. Then when I run my job that uses the grail build step (attached screen shot 'build_with_grails_war.png'), I get the error message in attached screen shot 'build_failed.png'. My first guess was that the server didn't have access to the internet - which might explain why it couldn't find any mirrors to display - but telnet and curl are able to hit internet sights just fine. I have another instance of Jenkins (also Redhat) where an older version of the Grails Plugin works just fine (1.5). The only notable difference between those instances of Jenkins is that the one that does not work has CloudBees installed, and the one where it works does not have CloudBees installed. I'm hoping that I'm missing something simple here. Please help me identify the issue and get a version of grails installed on this server. What other info do you need to help debug this? Thank you. Environment: Jenkins Grails Plugin 1.6.3 Attempting to install onto a Jenkins instance running on Red Hat 4.1.2-51 Project: Jenkins Labels: grails installer Priority: Major Reporter: Dan Dowma 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-13287) Error on apply configuration when changing job name
Leo Li commented on JENKINS-13287 Error on apply configuration when changing job name Seeing this in 1.480.2 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-16493) FactoryConfigurationError when parsing XML on IBM J9 JVM master and Oracle JVM slave
Brant Bobby created JENKINS-16493 FactoryConfigurationError when parsing XML on IBM J9 JVM master and Oracle JVM slave Issue Type: Bug Affects Versions: current Assignee: peterkittreilly Components: violations Created: 25/Jan/13 9:31 PM Description: Our Jenkins master executes an MSBuild job on a Windows slave, and the Violations plugin is throwing an exception when parsing FxCop's XML results. The plugin can parse the XML successfully when the job isn't being executed on a slave. (Tested using a "faux project path" on the master's local file system) Full stack trace from build console log: ERROR: Publisher hudson.plugins.violations.ViolationsPublisher aborted due to exception hudson.util.IOException2: remote file operation failed: c:\jenkins\workspace\TestBuild at hudson.remoting.Channel@36c136c1:wpg-lt-24-cs9t1 at hudson.FilePath.act(FilePath.java:848) at hudson.FilePath.act(FilePath.java:825) at hudson.plugins.violations.ViolationsPublisher.perform(ViolationsPublisher.java:74) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:810) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:785) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:732) at hudson.model.Run.execute(Run.java:1568) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: java.io.IOException: Remote call on wpg-lt-24-cs9t1 failed at hudson.remoting.Channel.call(Channel.java:681) at hudson.FilePath.act(FilePath.java:841) ... 11 more Caused by: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.DocumentBuilderFactoryImpl not found at javax.xml.parsers.DocumentBuilderFactory.newInstance(Unknown Source) at hudson.plugins.violations.types.fxcop.FxCopParser.parse(FxCopParser.java:41) at hudson.plugins.violations.ViolationsCollector.doType(ViolationsCollector.java:187) at hudson.plugins.violations.ViolationsCollector.invoke(ViolationsCollector.java:114) at hudson.plugins.violations.ViolationsCollector.invoke(ViolationsCollector.java:25) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2309) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at hudson.remoting.Engine$1$1.run(Engine.java:58) at java.lang.Thread.run(Unknown Source) Environment: Jenkins version: 1.499 Violations plugin version: 0.7.11 Master: IBM J9 VM 2.4 (JRE 1.6.0) (Linux: SLES 11 SP2) Slave: Oracle JVM 1.7.0_11 (Windows 2008 Server R2) Project: Jenkins Labels: plugin slave Priority: Major Reporter: Brant Bobby This message is automatically generated by JIRA. If you think it was sent incorrectly, please
[JIRA] (JENKINS-15704) Incomplete list of builds when I go to JobName/api/json
Eduardo Gonzalez commented on JENKINS-15704 Incomplete list of builds when I go to JobName/api/json I also have the same problem, in api/xml. I upgraded from 1.479 to 1.499 to find this issue. It bothers me a lot since I use the API from another web pages to obtain data. Now it's no good. I am seriously thinking in downgrade jenkins. 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-16240) Problem with NOT_BUILT build result
ThiagoC resolved JENKINS-16240 as Won't Fix Problem with NOT_BUILT build result Resolved by manually setting the build status to SUCCESS before the build starts. Change By: ThiagoC (25/Jan/13 8:23 PM) Status: Open Resolved Resolution: Won't Fix 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-12379) Archive the artifacts should allow specifying the target artifacts path
Iristyle commented on JENKINS-12379 Archive the artifacts should allow specifying the target artifacts path I would much prefer being able to structure the dir layout somehow when the artifacts are created. I get unnecessary nesting of archive/foo/*. 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-15961) Add "ignore Push notification" option
Christian Höltje commented on JENKINS-15961 Add "ignore Push notification" option Here are some alternatives to adding an "ignore Push notification" option: Add a "Build Trigger" that if selected will let a build be kicked off by the git plugin on a push notification. (This is the inverse of the above, which I think is more obvious). Without this "Build Trigger" then the push will be ignored. Only kick off a build if the polling is more frequent than a certain threshold (such as 30 minutes). 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-16375) show job difference does not work, url escaped twice
Eugen Dinca reopened JENKINS-16375 show job difference does not work, url escaped twice Still happens in 2.1.1. The URL looks like this (note the same double encoding in the name param value): https:///jenkins/job/check_graph%20Build/jobConfigHistory/showDiffFiles?timestamp1=×tamp2=&name=check_graph%2520Build&isJob=true In the system log I get: Caused by: java.lang.IllegalArgumentException: A job with this name could not be found: check_graph%20Build Change By: Eugen Dinca (25/Jan/13 7:36 PM) 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
[JIRA] (JENKINS-14112) The execution (build) of Project will fail on "mkdir" on remote disk.
Whitey zerofour commented on JENKINS-14112 The execution (build) of Project will fail on "mkdir" on remote disk. Jenkins usage of the drive (in svnKit?) is related to this issue. I have the same issue with mkdir fail as a java exception when trying to set a custom workspace as a network drive. Even though all permissions are set and the drive is mounted with a letter (J I still get this error. This is not related to windows permissions. I can set the workspace to be on a local drive and within the job execute a "net USE" command. Without specifying a username/password this uses the current account (whatever Jenkins is running under) and is able to read/write files to the share. 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-16350) "logout" link doesn't work
Peter Miklosko commented on JENKINS-16350 "logout" link doesn't work Yes, it is irritating. I expect to be able to logout just like with github, not to be automatically log in again 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-16492) Upgrade from 0.12 to 0.13 breaks server
Peter Miklosko created JENKINS-16492 Upgrade from 0.12 to 0.13 breaks server Issue Type: Bug Affects Versions: current Assignee: Michael O'Cleirigh Components: github-oauth Created: 25/Jan/13 6:01 PM Description: Got 500 after upgrade from 0.12 to 0.13 Exception: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: java.io.StringReader@5e5e32a1; line: 1, column: 2] Stacktrace: org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code 60)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') at [Source: java.io.StringReader@5e5e32a1; line: 1, column: 2] at org.codehaus.jackson.JsonParser._constructError(JsonParser.java:1433) at org.codehaus.jackson.impl.JsonParserMinimalBase._reportError(JsonParserMinimalBase.java:521) at org.codehaus.jackson.impl.JsonParserMinimalBase._reportUnexpectedChar(JsonParserMinimalBase.java:442) at org.codehaus.jackson.impl.ReaderBasedParser._handleUnexpectedValue(ReaderBasedParser.java:1198) at org.codehaus.jackson.impl.ReaderBasedParser.nextToken(ReaderBasedParser.java:485) at org.codehaus.jackson.map.ObjectMapper._initForReading(ObjectMapper.java:2770) at org.codehaus.jackson.map.ObjectMapper._readMapAndClose(ObjectMapper.java:2718) at org.codehaus.jackson.map.ObjectMapper.readValue(ObjectMapper.java:1863) at org.kohsuke.github.Requester.parse(Requester.java:300) at org.kohsuke.github.Requester._to(Requester.java:173) at org.kohsuke.github.Requester.to(Requester.java:139) at org.kohsuke.github.GitHub.getMyself(GitHub.java:200) at org.kohsuke.github.GitHub.(GitHub.java:102) at org.kohsuke.github.GitHub.connectUsingOAuth(GitHub.java:149) at org.jenkinsci.plugins.GithubAuthenticationToken.(GithubAuthenticationToken.java:68) at org.jenkinsci.plugins.GithubSecurityRealm.doFinishLogin(GithubSecurityRealm.java:313) 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:616) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487) at org.kohsuke.stapler.Stapler.service(Stapler.java:164) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.d
[JIRA] (JENKINS-16342) asynchPeople very slow when using Gravatar & Subversion plugins
SCM/JIRA link daemon commented on JENKINS-16342 asynchPeople very slow when using Gravatar & Subversion plugins Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/model/View.java http://jenkins-ci.org/commit/jenkins/bd03abbcc0078c2f250c2e3ee2c8d3c4a9d210ca Log: JENKINS-16342 Improving responsiveness of asynchPeople when Gravatar plugin is in use. This change does not necessarily improve total performance, since the avatar is still computed. But (1) the computation is correctly done in the work thread, not in the HTTP response thread; (2) the computation is done just once for a given User, which could reduce load when many AJAX checks are done.(cherry picked from commit c757e65431ad1aec9a3bebe81ac919577e51ac58) Conflicts: changelog.html Compare: https://github.com/jenkinsci/jenkins/compare/cb6f200e8663...bd03abbcc007 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-9679) NoClassDefFoundError on Base64 when launching an headless slave with -jnlpCredential option
SCM/JIRA link daemon commented on JENKINS-9679 NoClassDefFoundError on Base64 when launching an headless slave with -jnlpCredential option Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html pom.xml http://jenkins-ci.org/commit/jenkins/7bc441d17c67d435c9b5e67dbca236abc124ff54 Log: [FIXED JENKINS-9679] integrated remoting 2.21 that contains the fix. (cherry picked from commit 8a4bedd0df9b5d642945eb601ddb99bb75e87131) Conflicts: changelog.html pom.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
[JIRA] (JENKINS-16491) Changes since last successfull build Plugin - "View Detail" links are broken
Richard Geiger created JENKINS-16491 Changes since last successfull build Plugin - "View Detail" links are broken Issue Type: Bug Assignee: Unassigned Components: plugin Created: 25/Jan/13 5:45 PM Description: After a list of changes is brought up, clicking the View Details link for any change gets a 404 error in return. This capability is not critical for us, but it's a rough edge that should be fixed. Environment: Jenkins ver. 1.466.10.1 (Jenkins Enterprise by CloudBees 12.11) Changes since last successfull build Plugin 0.5 Project: Jenkins Priority: Minor Reporter: Richard Geiger 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-16089) Standard view columns interact force builds to be eagerly loaded
Justin Santa Barbara commented on JENKINS-16089 Standard view columns interact force builds to be eagerly loaded I hit this issue myself. I whipped up a quick proof-of-concept of using caching to fix: https://github.com/justinsb/jenkins/commit/d539c6680ea1fb14f45c63ec21ecf8df046f3352 I debated caching the jobs themselves, but they're not Serializable , so that would eliminate many of the more advanced caching solutions. Instead, I just memoize the function results, recording against each (completed) build the build number of e.g. lastFailure. To retrieve, we walk the build chain as normal, but we can short-circuit as soon as we come across a memoized result. When we find a result, we cache it against the most recent completed build, it isn't already there. This relies on an LRU cache to expire old entries. Currently this is only in-memory, but if we agree that caching is a good answer, I think we'd want to implement a persistent cache so that this survives across restarts. I suspect this memoization approach could well prove helpful for performance in many places in Jenkins. I know the patch is not ready to merge . If someone wants to take the idea and run with it, feel free; otherwise, comments/criticism welcome. If this does have broader applicability, should I post to the Jenkins-dev mail-list? 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-14575) SCM checkout retry count not working
Richard Merrill edited a comment on JENKINS-14575 SCM checkout retry count not working I tried testing the "Retry Count" feature with Jenkins 1.499 on a Windows Server 2008 R2 Enterprise server using Subversion and it never retried the checkout with the retry count set to 1. The Quiet Period value was set to 10 seconds. I tried it again with the Retry Count set to 2 and it still failed to try the checkout again. 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-14575) SCM checkout retry count not working
Richard Merrill commented on JENKINS-14575 SCM checkout retry count not working I tried testing the "Retry Count" feature with Jenkins 1.499 on a Windows Server 2008 R2 Enterprise server and it never retried the checkout with the retry count set to 1. The Quiet Period value was set to 10 seconds. I tried it again with the Retry Count set to 2 and it still failed to try the checkout again. 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-15992) Don't skip jobs when earlier job failed
Tanguy Bayard commented on JENKINS-15992 Don't skip jobs when earlier job failed Hi Ben, ignore feature has been added in 0.7 (released Jan. 11, 2013) --> does this solve your issue ? 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-16342) asynchPeople very slow when using Gravatar & Subversion plugins
vjuranek commented on JENKINS-16342 asynchPeople very slow when using Gravatar & Subversion plugins +1 to remove MailAddressResolvers or at least make them optional 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-9679) NoClassDefFoundError on Base64 when launching an headless slave with -jnlpCredential option
Jesse Glick resolved JENKINS-9679 as Fixed NoClassDefFoundError on Base64 when launching an headless slave with -jnlpCredential option Reclosing; filed JENKINS-16490 to capture the cache issue, which is really independent. Change By: Jesse Glick (25/Jan/13 5:04 PM) Status: Reopened Resolved Resolution: 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
[JIRA] (JENKINS-16490) New versions of slave.jar not reliably pushed via JNLP
Jesse Glick created JENKINS-16490 New versions of slave.jar not reliably pushed via JNLP Issue Type: Bug Assignee: Unassigned Components: core Created: 25/Jan/13 5:04 PM Description: As described in JENKINS-9679, merely updating the version of slave.jar served from Jenkins master does not cause JNLP agents to use the new version; they persist in using the JNLP cache. This makes debugging changes difficult, and can result in bug fixes seeming to not take effect in user deployments. We do set an immediate Expires header on /jnlpJars/slave.jar but apparently this does not suffice. Project: Jenkins Labels: slave jnlp Priority: Major Reporter: Jesse Glick 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-16209) Promoted builds plugin can't promote a build earlier than an existing promoted build
Bruce Edge commented on JENKINS-16209 Promoted builds plugin can't promote a build earlier than an existing promoted build A workaround is described here: http://overwatering.org/blog/2012/04/promotions-with-jenkins/ where they also describe the copy-artifacts mechanism as not working. 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-16467) Error 500 - No Protocol
Brad Gignac resolved JENKINS-16467 as Fixed Error 500 - No Protocol https://github.com/jenkinsci/github-oauth-plugin/commit/ff357acc9cf379cbb8bc40a014b2c201456bd735 Change By: Brad Gignac (25/Jan/13 4:42 PM) Status: Open Resolved Fix Version/s: current Resolution: 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
[JIRA] (JENKINS-16467) Error 500 - No Protocol
Brad Gignac commented on JENKINS-16467 Error 500 - No Protocol This was fixed by this commit. https://github.com/jenkinsci/github-oauth-plugin/commit/ff357acc9cf379cbb8bc40a014b2c201456bd735 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-16426) Backup fails while copying a file from the jobs folder
Thomas Fürer resolved JENKINS-16426 as Fixed Backup fails while copying a file from the jobs folder problem is fix and workaround for special case is to move files to the userContent folder. if this is still a problem for you do not hesitate to reopen this issue. Than I will implement the inclution of these files. Change By: Thomas Fürer (25/Jan/13 4:04 PM) Status: Open Resolved Resolution: 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
[JIRA] (JENKINS-16426) Backup fails while copying a file from the jobs folder
Thomas Fürer edited a comment on JENKINS-16426 Backup fails while copying a file from the jobs folder problem is fix and workaround for special case is to move files to the userContent folder. if this is still a problem for you do not hesitate to reopen this issue. Than I will implement the inclution of these files. Thanks for your feedback! 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-16489) Current thinBackup doesn't copy build artifacts from sub-folders
Thomas Fürer resolved JENKINS-16489 as Fixed Current thinBackup doesn't copy build artifacts from sub-folders fixed by pull request from richard nichols Change By: Thomas Fürer (25/Jan/13 3:53 PM) Status: Open Resolved Resolution: 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
[JIRA] (JENKINS-16487) Promotion Level being set to INITIAL
Ronan Mulvaney reopened JENKINS-16487 Promotion Level being set to INITIAL Hi Jens, We are changing this, the problem seems to be that the plugin is changing it back upon processing the baseline via a poll scm. This is only happening since the latest release if that helps. Here is a more complete view on VOB log: These steps are our internal build process - --01-25T11:05 make attribute "PromotionLevel" on baseline "LP_MAIN_20130125_110252" "Added attribute "PromotionLevel" with value "CIBUILD_PASSED"." --01-25T11:05 remove attribute "master_process_started" from baseline "LP_MAIN_20130125_110252" Then Jenkins picks up the baseline - --01-25T11:11 make hyperlink "UseBaseline" on baseline "LP_MAIN_20130125_110252" "Attached hyperlink "UseBaseline@10960@\LP-PVOB"." --01-25T11:21 make attribute "PromotionLevel" on baseline "LP_MAIN_20130125_110252" "Added attribute "PromotionLevel" with value "INITIAL"." As such Jenkins is changing a PromotionLevel that our internal build process is relying upon. Thanks. Change By: Ronan Mulvaney (25/Jan/13 3:52 PM) Resolution: Not A Defect 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
[JIRA] (JENKINS-16489) Current thinBackup doesn't copy build artifacts from sub-folders
SCM/JIRA link daemon commented on JENKINS-16489 Current thinBackup doesn't copy build artifacts from sub-folders Code changed in jenkins User: Thomas Fuerer Path: src/main/java/org/jvnet/hudson/plugins/thinbackup/backup/HudsonBackup.java http://jenkins-ci.org/commit/thin-backup-plugin/9b940cb5daba379bb6f6ef77f0f60d125ecca4ea Log: Merge pull request #1 from rjnichols/master JENKINS-16489 Current thinBackup doesn't copy build artifacts from sub-folders Compare: https://github.com/jenkinsci/thin-backup-plugin/compare/31b27f241e34...9b940cb5daba 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-16426) Backup fails while copying a file from the jobs folder
Christian Apel commented on JENKINS-16426 Backup fails while copying a file from the jobs folder Thanks for your detailed explanation. These files are more related to the job configurations but not to the global Jenkins configuration. I think that it's a good idea to move them to the userContent folder. 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-16489) Current thinBackup doesn't copy build artifacts from sub-folders
Thomas Fürer created JENKINS-16489 Current thinBackup doesn't copy build artifacts from sub-folders Issue Type: Bug Affects Versions: current Assignee: Thomas Fürer Components: thinBackup Created: 25/Jan/13 3:22 PM Description: by Richard Nichols: This occurs in multi-module Maven projects with manual artifact archiving. I have changed the filter to also include sub-folders for build artifacts. Project: Jenkins Priority: Major Reporter: Thomas Fürer 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-16319) Failure to delete old config files during rekeying on Windows
SCM/JIRA link daemon commented on JENKINS-16319 Failure to delete old config files during rekeying on Windows Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/util/SecretRewriter.java http://jenkins-ci.org/commit/jenkins/cb6f200e8663101533f08821adc471b4f6b54fe5 Log: [FIXED JENKINS-16319] Stream ordering problem prevented SecretRewriter from working on Windows.(cherry picked from commit 8b8231108fb5930bab5c7e2f20685c9a9d237749) Conflicts: changelog.html Compare: https://github.com/jenkinsci/jenkins/compare/5f7ad6e5feee...cb6f200e8663 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-16273) Slaves forbidden to request JNLP anonymously but -jnlpCredentials not offered
SCM/JIRA link daemon commented on JENKINS-16273 Slaves forbidden to request JNLP anonymously but -jnlpCredentials not offered Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/resources/hudson/slaves/JNLPLauncher/main.jelly http://jenkins-ci.org/commit/jenkins/17f0161e56dc2eb213415528061d8c8792694960 Log: JENKINS-16273 Improved instructions for passing -jnlpCredentials. First, display instructions when the user has CONNECT, not necessarily ADMINISTER. Second, when anonymous users cannot CONNECT, show how to use -jnlpCredentials (and do not bother showing javaws, since it does not work in this case).(cherry picked from commit a1e709ddf0ca48b25ad07ee13a2fbdb0a6d97c0e) Conflicts: changelog.html 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-6604) Possible race condition in RemoteClassLoader renders slave unusable
SCM/JIRA link daemon commented on JENKINS-6604 Possible race condition in RemoteClassLoader renders slave unusable Code changed in jenkins User: olivier lamy Path: changelog.html http://jenkins-ci.org/commit/jenkins/4b1a73f16567d812a0e9af5ebb0e5bcb5e8c5b0d Log: changelog entry for JENKINS-6604 (cherry picked from commit b80789474cacc64be4954f0f4473759311e80580) Conflicts: changelog.html 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-6604) Possible race condition in RemoteClassLoader renders slave unusable
SCM/JIRA link daemon commented on JENKINS-6604 Possible race condition in RemoteClassLoader renders slave unusable Code changed in jenkins User: olivier lamy Path: pom.xml http://jenkins-ci.org/commit/jenkins/8cbe3f5ab6cc6289481cc13784952802392129e5 Log: use last remoting 2.19 fix for JENKINS-6604 (cherry picked from commit 76e31a3a5c039e317a84b4c3331e15c284d44435) Conflicts: pom.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
[JIRA] (JENKINS-16278) "Remember me on this computer" does not work, cookie is not accepted in new session
SCM/JIRA link daemon commented on JENKINS-16278 "Remember me on this computer" does not work, cookie is not accepted in new session Code changed in jenkins User: Olivier Lamy Path: changelog.html http://jenkins-ci.org/commit/jenkins/fa6a84c54506fc25531a039f931870880f6fa182 Log: changelog entry for JENKINS-16278(cherry picked from commit 0b5a4a3550dcff91b1bedeb77415f683b659634b) Conflicts: changelog.html 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-16397) Loading asynchPeople calls (synch) People constructor
SCM/JIRA link daemon commented on JENKINS-16397 Loading asynchPeople calls (synch) People constructor Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/model/View.java http://jenkins-ci.org/commit/jenkins/991158b1f6266403c7e5377388827f73aacd3d2f Log: [FIXED JENKINS-16397] Just displaying /asynchPeople constructed the expensive People object merely to decide whether or not to display the “REST API” link. (cherry picked from commit 063acce1e1886b8f30ba8657b1dbe7c7804e7796) Conflicts: changelog.html 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-16278) "Remember me on this computer" does not work, cookie is not accepted in new session
SCM/JIRA link daemon commented on JENKINS-16278 "Remember me on this computer" does not work, cookie is not accepted in new session Code changed in jenkins User: Hendrik Millner Path: core/src/main/java/hudson/security/TokenBasedRememberMeServices2.java http://jenkins-ci.org/commit/jenkins/83c95d51bae57fc328e5b1fb080875234a1b0429 Log: [FIXED JENKINS-16278] Fixed RememberMe cookie signature generation (bugfix on SECURITY-49) New cookie signature generation was not implemented in creation of RememberMe cookie, but only in its verification. Fixed by new override TokenBasedRememberMeServices2.loginSuccess (cherry picked from commit 91bbae3c35230734fd2cf6926a7ac1239119fc6e) 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-16244) View.hasPeople too slow to use in sidepanel.jelly
SCM/JIRA link daemon commented on JENKINS-16244 View.hasPeople too slow to use in sidepanel.jelly Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/model/View.java core/src/main/java/jenkins/model/Jenkins.java core/src/main/resources/hudson/model/View/sidepanel.jelly http://jenkins-ci.org/commit/jenkins/4998a373c831665814233b2b330392299bdc101b Log: [FIXED JENKINS-16244] View.hasPeople too slow to use in sidepanel.jelly.(cherry picked from commit 73aac1073983e1f667d801387571d31857253ffc) Conflicts: changelog.html 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-16488) doNotifyCommit fails after update to 1.45
Jan Klass created JENKINS-16488 doNotifyCommit fails after update to 1.45 Issue Type: Bug Assignee: Unassigned Attachments: stacktrace.log Components: subversion Created: 25/Jan/13 3:14 PM Description: After updating the SVNPlugin to version 1.45 our doNotifyCommit (post commit) setup does not work anymore. The masters log seems to point out an issue: 25.01.2013 15:55:25 hudson.scm.SubversionRepositoryStatus doNotifyCommit WARNUNG: Failed to handle Subversion commit notification org.tmatesoft.svn.core.SVNCancelException: svn: E200015: No credential to try. Authentication failed Other jobs, manual builds, and the cron-poll-checked builds on the same job and repository continue to work fine. Project: Jenkins Priority: Major Reporter: Jan Klass 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-14965) Instance limits improvement
max allan commented on JENKINS-14965 Instance limits improvement I like the idea of the node cap applying only to instances that Jenkins has started itself. Simply ignore any other instances. 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-14843) OpenID SSO should use POST to submit details to google apps endpoint
Open English Infrastructure Team commented on JENKINS-14843 OpenID SSO should use POST to submit details to google apps endpoint Is there any chance this bug could be fixed soon? 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
[JIRA] (JENKINS-16487) Promotion Level being set to INITIAL
Jens Brejner resolved JENKINS-16487 as Not A Defect Promotion Level being set to INITIAL It is not the plugin that creates the attribute. ClearCase does it always to each newly created baseline. Later in the process the value of it can be changed to the other values that are available in the PVOB. To test, you can create a new pvob - or a component and stream which is not found by ccucm plugin. Then create a baseline, and run cleartool lshist -l -min baseline: Change By: Jens Brejner (25/Jan/13 2:28 PM) Status: Open Resolved Resolution: Not A Defect 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-16487) Promotion Level being set to INITIAL
Jens Brejner commented on JENKINS-16487 Promotion Level being set to INITIAL It is not the plugin that creates the attribute. ClearCase does it always to each newly created baseline. Later in the process the value of it can be changed to the other values that are available in the PVOB. 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... And - setting prio of Job2 to 50 leads to the expected result. 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... And - setting prio of Job2 leads to the expected result. 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-16487) Promotion Level being set to INITIAL
Jens Brejner assigned JENKINS-16487 to Jens Brejner Promotion Level being set to INITIAL Change By: Jens Brejner (25/Jan/13 2:17 PM) Assignee: Praqma Support Jens Brejner 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-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 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-7883) Stopped (as opposed to terminated) slaves are counted against the active instance count for the purpose of launching; can prevent launching of instances
max allan commented on JENKINS-7883 Stopped (as opposed to terminated) slaves are counted against the active instance count for the purpose of launching; can prevent launching of instances Agree with @akostadinov. Our VPC is used by developers so we have a completely variable number of instances. Currently about 120 and we only really want a handful of Jenkins instances. But if someone decides they need a new dev cluster, we'll have 130 in a few minutes. Or if they decide they don't need a cluster we'll be down to 110. So how can I set my cap? If someone tries to start a load of builds during the day, they could exhaust the free IP addresses / hit EC2's limit on instances without realising if we disable the cap completely. If a new ticket was raised, please let me know the ID so I can +1 it! If I don't hear anything I'll try to remember to raise one 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
[JIRA] (JENKINS-16487) Promotion Level being set to INITIAL
Ronan Mulvaney created JENKINS-16487 Promotion Level being set to INITIAL Issue Type: Bug Affects Versions: current Assignee: Praqma Support Components: clearcase-ucm Created: 25/Jan/13 1:42 PM Description: With a Job which polls the SCM repository we are finding that after polling and working with a new baseline that the plugin is setting the following on our repository: --01-25T11:21 username make attribute "PromotionLevel" on baseline "LP_MAIN_20130125_110252" "Added attribute "PromotionLevel" with value "INITIAL"." We have the following set on the Job: Promotion Level - Any Load Modules - All Polling - Poll Self Create Baseline - unchecked Recommend Baseline - unchecked Make Tag - unchecked Set description - unchecked I have marked this as blocker as this invalidates our whole SCM process which Jenkins is just a small part of and we cannot have Jenkins interact like this here i.e. it should not set anything on the repository. Environment: Windows 2008 64Bit RC2 Project: Jenkins Priority: Blocker Reporter: Ronan Mulvaney 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-16486) Links broken when user-defined axis values contain comma
Mickael Istria updated JENKINS-16486 Links broken when user-defined axis values contain comma Change By: Mickael Istria (25/Jan/13 1:28 PM) Description: Links are broken when a user-defined axis values contain comma.Steps to reproduce 1. # Create matrix job 2. # create user-defined axis with value "a,b" without quotes 3. # Run job 4. # Click configurationExpected: configuration build pageResult: 404. 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-16486) Links broken when user-defined axis values contain comma
Mickael Istria created JENKINS-16486 Links broken when user-defined axis values contain comma Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: matrix Created: 25/Jan/13 1:26 PM Description: Links are broken when a user-defined axis values contain comma. Steps to reproduce 1. Create matrix job 2. create user-defined axis with value "a,b" without quotes 3. Run job 4. Click configuration Expected: configuration build page Result: 404. Project: Jenkins Priority: Major Reporter: Mickael Istria 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-7957) Hudson Parsing POMs Hanging
Innokenty Shuvalov commented on JENKINS-7957 Hudson Parsing POMs Hanging Same issue. I changed the entire module structure of maven project, wiped out the source, loaded the new one from my git-repo. But jenkins didn't recognize my new modules, he tries to build the old ones, even though even their source code is gone! Of course, the fact that locally on my pc I have no troubles running "mvn clean install" in console goes without saying. 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-16485) Plugin throws exception in dev mode.
Ratn Dwivedi created JENKINS-16485 Plugin throws exception in dev mode. Issue Type: Bug Assignee: Francis Upton Components: ec2 Created: 25/Jan/13 1:01 PM Description: Steps to produce bug : 1.mvn hpi:run 2.Set access keys , Then it throws following exception - 2013-01-25 18:29:38.039::WARN: /descriptorByName/hudson.plugins.ec2.AmazonEC2Cloud/fillRegionItems java.lang.IllegalStateException: Connection not obtained from this manager at org.apache.http.util.Asserts.check(Asserts.java:34) at org.apache.http.impl.conn.tsccm.ThreadSafeClientConnManager.releaseConnection(ThreadSafeClientConnManager.java:252) at org.apache.http.impl.conn.AbstractClientConnAdapter.abortConnection(AbstractClientConnAdapter.java:338) at org.apache.http.impl.client.DefaultRequestDirector.abortConnection(DefaultRequestDirector.java:1119) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:590) at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:858) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:76) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:97) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:58) at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:262) at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:169) at com.amazonaws.services.ec2.AmazonEC2Client.invoke(AmazonEC2Client.java:5684) at com.amazonaws.services.ec2.AmazonEC2Client.describeRegions(AmazonEC2Client.java:768) at com.amazonaws.services.ec2.AmazonEC2Client.describeRegions(AmazonEC2Client.java:4534) at hudson.plugins.ec2.AmazonEC2Cloud$DescriptorImpl.doFillRegionItems(AmazonEC2Cloud.java:96) 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:282) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:104) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:234) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) at org.kohsuke.stapler.Stapler.service(Stapler.java:159) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1074) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1065) at org.mortba
[JIRA] (JENKINS-16482) SSH slave connection issues after Jenkins update
tiainpa commented on JENKINS-16482 SSH slave connection issues after Jenkins update I tried to downgrade using 1.451 deb file but really similar symptoms with the old version too, we are in big trouble now 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-2673) Invalid CRON Warnings
Richard Bradley commented on JENKINS-2673 Invalid CRON Warnings I had the same issue. I have made a patch to improve the wording of the warning, and to not issue the warning in the "poll every minute" case. See https://github.com/jenkinsci/jenkins/pull/676 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-15199) Slaves turns to "Dead" state after connecting to remote machine
taksan edited a comment on JENKINS-15199 Slaves turns to "Dead" state after connecting to remote machine We are having this problem as well on v1.499. I already installed the latest ssh slave plugin, but it didn't work. At least, the workaround proposed by Aerts (removing matrix jobs from the queue and restarting the slave thread) worked. 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-15199) Slaves turns to "Dead" state after connecting to remote machine
taksan commented on JENKINS-15199 Slaves turns to "Dead" state after connecting to remote machine We are having this problem as well on v1.499. I already installed the latest ssh slave plugin, but it didn't work. At lease, the workaround proposed by Aerts (removing matrix jobs from the queue and restarting the slave thread) worked. 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-16484) allow sidebar links to be exposed by the api
liamjbennett created JENKINS-16484 allow sidebar links to be exposed by the api Issue Type: New Feature Assignee: Unassigned Components: sidebar-link Created: 25/Jan/13 11:32 AM Description: It would be useful to have a sidebar-link name and link exposed in the main project api. Project: Jenkins Priority: Minor Reporter: liamjbennett 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-16481) Make it configurable if new findbugs for unstable builds should be computed by comparison to the reference build (last stable build)
Ulli Hafner resolved JENKINS-16481 as Duplicate Make it configurable if new findbugs for unstable builds should be computed by comparison to the reference build (last stable build) Change By: Ulli Hafner (25/Jan/13 11:29 AM) 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
[JIRA] (JENKINS-16482) SSH slave connection issues after Jenkins update
tiainpa commented on JENKINS-16482 SSH slave connection issues after Jenkins update Okay, even though I got some slaves connecting via Java web start, they don't run any jobs. Jobs are just waiting for the next available executor forever. 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-16483) Cant use VPC, error says all SGs must be VPC SGs - and they are
max allan created JENKINS-16483 Cant use VPC, error says all SGs must be VPC SGs - and they are Issue Type: Bug Affects Versions: current Assignee: Francis Upton Components: ec2 Created: 25/Jan/13 11:16 AM Description: I use a VPC and if I try to create a new instance within the VPC (by choosing a VPC subnet) and specifying 2 security groups it fails. I can specify no groups or either group individually and it works fine. But with both, I get an error. The group names are "all-vpc-basic dev1-basic" Error says (with sensitive information replaced with ...) : Launching AMI ERROR: Security groups must all be VPC security groups to work in a VPC context [8mha:AAA4P0.Vc87DzH.iWA=[0mcom.amazonaws.AmazonClientException: Security groups must all be VPC security groups to work in a VPC context at hudson.plugins.ec2.SlaveTemplate.provision(SlaveTemplate.java:247) at hudson.plugins.ec2.EC2Cloud.doProvision(EC2Cloud.java:207) 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:616) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487) at org.kohsuke.stapler.Stapler.service(Stapler.java:164) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at winstone.RequestDispatcher.forward(RequestDispatcher.java:331) at winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:215) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.F
[JIRA] (JENKINS-9450) Addition of package-level maven-metadata.xml
kutzi updated JENKINS-9450 Addition of package-level maven-metadata.xml Change By: kutzi (25/Jan/13 10:56 AM) Summary: Addition of package-level maven-metadata.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
[JIRA] (JENKINS-14893) scm sync configuration causes memory leak
SCM/JIRA link daemon resolved JENKINS-14893 as Fixed scm sync configuration causes memory leak Change By: SCM/JIRA link daemon (25/Jan/13 10:45 AM) Status: Open Resolved Resolution: 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
[JIRA] (JENKINS-14893) scm sync configuration causes memory leak
SCM/JIRA link daemon commented on JENKINS-14893 scm sync configuration causes memory leak Code changed in jenkins User: Johno Crawford Path: src/main/resources/hudson/plugins/scm_sync_configuration/extensions/ScmSyncConfigurationPageDecorator/footer.jelly http://jenkins-ci.org/commit/scm-sync-configuration-plugin/0ae511a949b15b51aaff555278c0b633abba1fee Log: Merge pull request #10 from mhelff/master [FIXED JENKINS-14893] reduce memory consumption / OOME Compare: https://github.com/jenkinsci/scm-sync-configuration-plugin/compare/c8b1696ece75...0ae511a949b1 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-14893) scm sync configuration causes memory leak
SCM/JIRA link daemon commented on JENKINS-14893 scm sync configuration causes memory leak Code changed in jenkins User: Martin Helff Path: src/main/resources/hudson/plugins/scm_sync_configuration/extensions/ScmSyncConfigurationPageDecorator/footer.jelly http://jenkins-ci.org/commit/scm-sync-configuration-plugin/b94d13ee111a3a10e4473d50bfe9d7f38d67ef83 Log: JENKINS-14893 only read logfiles if displayStatus is enabled 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-16482) SSH slave connection issues after Jenkins update
tiainpa updated JENKINS-16482 SSH slave connection issues after Jenkins update Change By: tiainpa (25/Jan/13 10:43 AM) Component/s: master-slave 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-16482) SSH slave connection issues after Jenkins update
tiainpa created JENKINS-16482 SSH slave connection issues after Jenkins update Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: core, ssh-slaves Created: 25/Jan/13 10:42 AM Description: After Jenkins update from 1.451 to 1.499 all our SSH slaves stay in offline state, and the connection log doesn't show anything at all. Here's a couple of stacktraces if there's any clue about this: java.io.IOException: Cannot run program "arp": java.io.IOException: error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) at java.lang.Runtime.exec(Runtime.java:593) at java.lang.Runtime.exec(Runtime.java:431) at java.lang.Runtime.exec(Runtime.java:328) at controller.WakeUpServlet.getmac(WakeUpServlet.java:62) at controller.Controller.getLog(Controller.java:200) at controller.Controller.doRefresh(Controller.java:130) at sun.reflect.GeneratedMethodAccessor223.invoke(Unknown Source) 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:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487) at org.kohsuke.stapler.Stapler.service(Stapler.java:164) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:206) at net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:179) at net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86) at org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.jav
[JIRA] (JENKINS-12553) Error '?' is an unsafe character
evernat commented on JENKINS-12553 Error '?' is an unsafe character Is it reproduced with a recent Jenkins version? 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-16481) Make it configurable if new findbugs for unstable builds should be computed by comparison to the reference build (last stable build)
Harald Reingruber created JENKINS-16481 Make it configurable if new findbugs for unstable builds should be computed by comparison to the reference build (last stable build) Issue Type: Improvement Assignee: Ulli Hafner Components: findbugs Created: 25/Jan/13 10:06 AM Description: We want to configure an email notification to the commiters for unstable builds, as soon as new bugs are detected. Therefore, we set the threshold for unstable builds to 0 new bugs. The problem is, that the build stays unstable until all new bugs are fixed, which would mean that even if no new bugs have been detected, the commiters will receive an email notification anyhow. Environment: Findbugs Plugin v4.45 Project: Jenkins Priority: Major Reporter: Harald Reingruber 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-12543) CLI permissions
evernat commented on JENKINS-12543 CLI permissions Is it reproduced with a recent Jenkins version? 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-16480) Klockwork Plugin is not uploading anything on klocwork server.
bhupender singh updated JENKINS-16480 Klockwork Plugin is not uploading anything on klocwork server. Change By: bhupender singh (25/Jan/13 9:13 AM) Summary: Klockwork Plugin is not uploading anything on klocwork server. 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-16480) Klockwork
bhupender singh created JENKINS-16480 Klockwork Issue Type: Bug Affects Versions: current Assignee: Gregory Boissinot Attachments: klocwork_result.xml Components: klocwork Created: 25/Jan/13 9:09 AM Description: 1) Is it mandatory to configure klockwork installation in jenkin's global configurations? if yes what is the meaning of project port (default 1106)? is it server port that we need to fill here? 2) we have upgraded the klocwork plugin for jenkins to 1.41.1 and if we configure it for "Klocwork v9.6 or later" then it doesn't do anything on klockwork server (i.e updating database for this new build) and also klocwork reports are not available for klocwork 9.6 but only klocwork review is available. 3) As we are using Klocwork version 9.6 and it doesn't generate xml file for reports automatically, manually we have generated report file but when we try to use it, it gives error as below: Starting the klocwork analysis. Processing 1 files with the pattern 'klocwork_result.xml'. FATAL: javax/xml/bind/JAXBException java.lang.NoClassDefFoundError: javax/xml/bind/JAXBException at com.thalesgroup.hudson.plugins.klocwork.parser.KloParserResult.invoke(KloParserResult.java:78) at com.thalesgroup.hudson.plugins.klocwork.parser.KloParserResult.invoke(KloParserResult.java:37) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at com.thalesgroup.hudson.plugins.klocwork.KloPublisher.perform(KloPublisher.java:104) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:711) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:686) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:633) at hudson.model.Run.run(Run.java:1463) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Due Date: 25/Jan/13 12:00 AM Environment: Windows Xp, Jenkins 1.467, Klocwork plugin version 1.41.1 Fix Versions: current Project: Jenkins Labels: plugin jenkins Priority: Major Reporter: bhupender singh 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-16339) Jobname truncated in next-executions
Ignacio Albors assigned JENKINS-16339 to Ignacio Albors Jobname truncated in next-executions Change By: Ignacio Albors (25/Jan/13 9:03 AM) Assignee: Ignacio Albors 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-12676) next-executions: Support evenly distributed crontab
Ignacio Albors closed JENKINS-12676 as Fixed next-executions: Support evenly distributed crontab Change By: Ignacio Albors (25/Jan/13 9:02 AM) Status: Resolved Closed 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-16479) SVN Check Out Hung
kutzi commented on JENKINS-16479 SVN Check Out Hung See http://stackoverflow.com/questions/224756/java-application-hang-on-linux-at-java-io-unixfilesystem-getbooleanattributes0 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