[JIRA] (JENKINS-13959) StackOverflowException on Job Finish
Simon Schlachter created JENKINS-13959: -- Summary: StackOverflowException on Job Finish Key: JENKINS-13959 URL: https://issues.jenkins-ci.org/browse/JENKINS-13959 Project: Jenkins Issue Type: Bug Components: cvs, notification Affects Versions: current Reporter: Simon Schlachter Since upgrading to jenkins 1.465 we get in some of our jobs the following stacktrace: {noformat} FATAL: null java.lang.StackOverflowError at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:266) at sun.util.calendar.ZoneInfo.getOffsets(ZoneInfo.java:243) at java.util.GregorianCalendar.computeFields(GregorianCalendar.java:2041) at java.util.GregorianCalendar.computeTime(GregorianCalendar.java:2489) at java.util.Calendar.updateTime(Calendar.java:2495) at java.util.Calendar.getTimeInMillis(Calendar.java:1104) at java.util.Calendar.getMillisOf(Calendar.java:2512) at java.util.Calendar.equals(Calendar.java:1892) at java.util.GregorianCalendar.equals(GregorianCalendar.java:811) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:409) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) at java.util.AbstractList.equals(AbstractList.java:524) at hudson.scm.CVSChangeLogSet$CVSChangeLog.equals(CVSChangeLogSet.java:416) at hudson.scm.CVSChangeLogSet$File.equals(CVSChangeLogSet.java:608) ... {noformat} The Exception happens when the Job itself has finished and is about to report results to e-mail receivers. We were able to workaround the issue by removing the "send email notification" setting, storing the configuration and then re-add the notification setting, so perhaps it has something to do with the notification part in jenkins itself. PS: The concerned Jobs to not all use CVS, some of them are git-only but get the exact same stacktrace as reported above. -- 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-13954) Add an option so that the build doesn't fail if cppcheck can't find the XML file.
[ https://issues.jenkins-ci.org/browse/JENKINS-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163344#comment-163344 ] Gregory Boissinot commented on JENKINS-13954: - I understand your use case. I am not sure if your proposal is the right solution. Maybe a combination of the Flexible Publisher Plugin (https://wiki.jenkins-ci.org/display/JENKINS/Flexible+Publish+Plugin) and the Run Condition plugin (https://wiki.jenkins-ci.org/display/JENKINS/Run+Condition+Plugin) could achieve your target. I have not ever tested but could you try and let me know. > Add an option so that the build doesn't fail if cppcheck can't find the XML > file. > - > > Key: JENKINS-13954 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13954 > Project: Jenkins > Issue Type: Improvement > Components: cppcheck >Affects Versions: current >Reporter: Verbitan >Assignee: Gregory Boissinot >Priority: Minor > > I've got a multi-configuration job which compiles on both Linux and Solaris. > The cppcheck binary I use is compiled for Solaris and not Linux, so in the > job configuration I only generate the cppcheck XML if the build is being run > on Solaris. > I want to publish out the cppcheck results, but this always causes the Linux > build to fail as it hasn't generated the XML file. > Is it possible to add a setting that ignores the file not existing? There's > already something similar for when the file is blank... -- 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-13954) Add an option so that the build doesn't fail if cppcheck can't find the XML file.
[ https://issues.jenkins-ci.org/browse/JENKINS-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13954 started by Gregory Boissinot. > Add an option so that the build doesn't fail if cppcheck can't find the XML > file. > - > > Key: JENKINS-13954 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13954 > Project: Jenkins > Issue Type: Improvement > Components: cppcheck >Affects Versions: current >Reporter: Verbitan >Assignee: Gregory Boissinot >Priority: Minor > > I've got a multi-configuration job which compiles on both Linux and Solaris. > The cppcheck binary I use is compiled for Solaris and not Linux, so in the > job configuration I only generate the cppcheck XML if the build is being run > on Solaris. > I want to publish out the cppcheck results, but this always causes the Linux > build to fail as it hasn't generated the XML file. > Is it possible to add a setting that ignores the file not existing? There's > already something similar for when the file is blank... -- 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-13810) Maven modules marked to wrong build when running concurrent job
[ https://issues.jenkins-ci.org/browse/JENKINS-13810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jyrki Puttonen updated JENKINS-13810: - Description: I have a Maven project build with one module, named jenkins-test. This module contains one test, which fails everytime (assertTrue(false) :)). There is a problem when this project is executed with "Execute concurrent builds if necessary" turned on and when multiple jobs are started at same time. Multiple builds start and finish, but some of these jobs are completed succesfully and some are marked as failed. What I see in the build status page is something like this: {quote} (Success) Build #180 (May 12, 2012 8:17:09 PM) ... Module Builds jenkins-test (didn't run) {quote} {quote} (Success) Build #181 (May 12, 2012 8:17:12 PM) ... Module Builds (disabled) jenkins-test (didn't run) {quote} {quote} (Unstable) Build #182 (May 12, 2012 8:17:19 PM) ... Module Builds jenkins-test (Unstable) #182 (Unstable) #183 (Unstable) #184 {quote} Logs show that the builds were executed properly (commit ids are right, and "[ERROR] There are test failures." is there). The next build then gets build number #187. In my setup I'm using Gerrit and Gerrit Trigger to launch jobs, so when I push multiple commits into Gerrit in one push, Jenkins starts multiple jobs at same time. I don't know if you can duplicate this behavior without Gerrit, though. Currently MavenModule and MavenModuleSet have their own build numbers, which are increment when a new module is built. These might get mixed up when multiple builds are executed concurrently. Multiple MavenModuletSets are built starting at the same time, and some how the numbering of MavenModules gets out of sync. The commit in https://github.com/jyrkiput/jenkins/commit/0d076e610b39b215ed34c35a5d4840e56183d5e4 fixes this, but I haven't tested it other cases than mine and I don't think that I'm qualified to change something that is this deeply on the jenkins core :) The commit probably has some unnecessary bits in it too at the moment. So I don't think that it should be merged :) was: I have a Maven project build with one module, named jenkins-test. This module contains one test, which fails everytime (assertTrue(false) :)). There is a problem when this project is executed with "Execute concurrent builds if necessary" turned on and when multiple jobs are started at same time. Multiple builds start and finish, but some of these jobs are completed succesfully and some are marked as failed. What I see in the build status page is something like this: (Success) Build #180 (May 12, 2012 8:17:09 PM) ... Module Builds jenkins-test (didn't run) (Success) Build #181 (May 12, 2012 8:17:12 PM) ... Module Builds (disabled) jenkins-test (didn't run) (Unstable) Build #182 (May 12, 2012 8:17:19 PM) ... Module Builds jenkins-test (Unstable) #182 (Unstable) #183 (Unstable) #184 Logs show that the builds were executed properly (commit ids are right, and "[ERROR] There are test failures." is there). The next build then gets build number #187. In my setup I'm using Gerrit and Gerrit Trigger to launch jobs, so when I push multiple commits into Gerrit in one push, Jenkins starts multiple jobs at same time. I don't know if you can duplicate this behavior without Gerrit, though. Currently MavenModule and MavenModuleSet have their own build numbers, which are increment when a new module is built. These might get mixed up when multiple builds are executed concurrently. Multiple MavenModuletSets are built starting at the same time, and some how the numbering of MavenModules gets out of sync. The commit in https://github.com/jyrkiput/jenkins/commit/0d076e610b39b215ed34c35a5d4840e56183d5e4 fixes this, but I haven't tested it other cases than mine and I don't think that I'm qualified to change something that is this deeply on the jenkins core :) The commit probably has some unnecessary bits in it too at the moment. So I don't think that it should be merged :) > Maven modules marked to wrong build when running concurrent job > --- > > Key: JENKINS-13810 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13810 > Project: Jenkins > Issue Type: Bug > Components: concurrent-build, maven >Reporter: Jyrki Puttonen >Assignee: Kohsuke Kawaguchi > > I have a Maven project build with one module, named jenkins-test. This module > contains one test, which fails everytime (assertTrue(false) :)). There is a > problem when this project is executed with "Execute concurrent builds if > necessary" turned on and when multiple jobs are started at same time. > Multiple builds start and finish, but some of these jobs are completed > succesfully and some are marked as failed. What I see in the build status > page i
[JIRA] (JENKINS-13629) When creating a new build in TestLink, plugin should automatically assign test case execution to a user
[ https://issues.jenkins-ci.org/browse/JENKINS-13629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13629 started by Bruno P. Kinoshita. > When creating a new build in TestLink, plugin should automatically assign > test case execution to a user > --- > > Key: JENKINS-13629 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13629 > Project: Jenkins > Issue Type: Improvement > Components: testlink >Affects Versions: current >Reporter: Robert Campbell >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: jenkins, plugins, testlink > > TestLink only reports some statistics correctly when executed test cases have > been assigned to a user. Although it is possible to change the assignment > manually post-execution it would be better if the TestLink plugin did this > automatically when creating a new build e.g. assign all test cases (to be) > executed by Jenkins to a jenkins-ci TestLink user. > This may also require changes to the TestLink API. -- 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-13836) Stable release issues|Loading All Build History Fails in stable release 1.447.1
[ https://issues.jenkins-ci.org/browse/JENKINS-13836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163343#comment-163343 ] hiteswar kumar commented on JENKINS-13836: -- community is working on this . hope they will release it soon :) > Stable release issues|Loading All Build History Fails in stable release > 1.447.1 > --- > > Key: JENKINS-13836 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13836 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Prodution >Reporter: Arvind Ramalingam >Priority: Blocker > > Hi I have upgraded my Production Jenkins to 1.447.1 and I am not able to see > my build history.When I try to view more of my build history I get the below > error.Please let me know which stable release should i revert back to and I > was at 1.409 and everything was fine. > HTTP Status 404 - > type Status report > message > description The requested resource () is not available. > Apache Tomcat/6.0.26 -- 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-13630) TestLink plugin does not update test case execution status correctly
[ https://issues.jenkins-ci.org/browse/JENKINS-13630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruno P. Kinoshita resolved JENKINS-13630. -- Resolution: Not A Defect Hi again, looking at TestLink, I believe this is the standard behaviour. I don't think it is a bug in TestLink either. You set the result of a test case, and the page refreshes. Then now it shows you the options to set another result. The combo box doesn't show the last execution status, from what I could understand. In case you believe this is a bug, and you can confirm this is the standard behaviour, feel free to file an issue at mantis.testlink.org. Thank you! > TestLink plugin does not update test case execution status correctly > > > Key: JENKINS-13630 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13630 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current > Environment: Windows 2003, TestLink 1.9.3, Jenkins 1.461, TestLink > Plugin 3.1.2 >Reporter: Robert Campbell >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: jenkins, plugins, testlink > Attachments: TestCase_result_bug.jpg > > > Using the jenkins-testlink-plugin-tutorial example, the test case is executed > correctly and is passed as part of the Jenkins job. Under Test Execution in > TestLink the test case Status is reported as Passed yet the Result is still > set to "Not Run". See attached screenshot. -- 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-13953) can't Deploy artifacts to Artifactory
[ https://issues.jenkins-ci.org/browse/JENKINS-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163341#comment-163341 ] Jason Hickey commented on JENKINS-13953: looks like I'm having the same issue: Jenkins ver. 1.466 Jenkins Artifactory Plugin 2.1.0 ERROR: null java.lang.NullPointerException at org.jfrog.hudson.util.BuildUniqueIdentifierHelper.getUpstreamIdentifier(BuildUniqueIdentifierHelper.java:106) at org.jfrog.hudson.maven2.ArtifactsDeployer.deployArtifact(ArtifactsDeployer.java:170) at org.jfrog.hudson.maven2.ArtifactsDeployer.deploy(ArtifactsDeployer.java:127) at org.jfrog.hudson.ArtifactoryRedeployPublisher.perform(ArtifactoryRedeployPublisher.java:300) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:994) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1463) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) > can't Deploy artifacts to Artifactory > - > > Key: JENKINS-13953 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13953 > Project: Jenkins > Issue Type: Bug > Components: artifactdeployer >Affects Versions: current >Reporter: maritzabell suarez > Labels: plugin > Attachments: ArtifactoryConfigurationOnJenkins.jpg, > ArtifactoryConfigurationOnJenkinsTask.jpg > > > hi! > i'm trying to deploy artifacts to artifactory and i followed the tutorial, > however, i got the same problem no matter what: > Waiting for Jenkins to finish collecting data > channel stopped > Deploying artifacts to http://192.168.1.22/artifactory > Deploying artifacts of module: > etask.components.security:COM-SecurityGuardEntities > ERROR: null > java.lang.NullPointerException > at > org.jfrog.hudson.util.BuildUniqueIdentifierHelper.getUpstreamIdentifier(BuildUniqueIdentifierHelper.java:106) > at > org.jfrog.hudson.maven2.ArtifactsDeployer.deployArtifact(ArtifactsDeployer.java:170) > at > org.jfrog.hudson.maven2.ArtifactsDeployer.deploy(ArtifactsDeployer.java:127) > at > org.jfrog.hudson.ArtifactoryRedeployPublisher.perform(ArtifactoryRedeployPublisher.java:300) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:994) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) > at hudson.model.Run.run(Run.java:1463) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:239) > Build step 'Deploy artifacts to Artifactory' changed build result to FAILURE > Finished: FAILURE > it doesn't say anything i can use to resolve the problem. > i attached the configuration of jenkins > thank you so much for the help, > Maritzabell Suarez -- 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-13934) Make it possible to delete all except latest 'n' archived artifacts
[ https://issues.jenkins-ci.org/browse/JENKINS-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] OHTAKE Tomohiro updated JENKINS-13934: -- Attachment: Max_number_of_builds_to_keep_with_artifacts.png > Make it possible to delete all except latest 'n' archived artifacts > --- > > Key: JENKINS-13934 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13934 > Project: Jenkins > Issue Type: Improvement > Components: postbuild-task >Affects Versions: current > Environment: Sun/Solaris 9 ; Java 1.6.0_10; Jenkins ver. 1.466 >Reporter: Paul Croome >Assignee: OHTAKE Tomohiro >Priority: Minor > Attachments: Max_number_of_builds_to_keep_with_artifacts.png > > > In the job configuration page, under Post-build Actions > Archive the > Artifacts > Advanced > it's possible to select the checkbox "Discard all but the last > successful/stable artifact to save disk space". > It would be useful if I could choose "Discard all but the last 'n' > successful/stable artifacts to save disk space". > (By comparison: The option "Discard Old Builds" allows me to specify "Max # > of builds to keep". A similar feature for archived artifacts would be nice.) -- 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-13934) Make it possible to delete all except latest 'n' archived artifacts
[ https://issues.jenkins-ci.org/browse/JENKINS-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163340#comment-163340 ] OHTAKE Tomohiro commented on JENKINS-13934: --- (1) and (2) can be specified independently. See screenshot attached. > Make it possible to delete all except latest 'n' archived artifacts > --- > > Key: JENKINS-13934 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13934 > Project: Jenkins > Issue Type: Improvement > Components: postbuild-task >Affects Versions: current > Environment: Sun/Solaris 9 ; Java 1.6.0_10; Jenkins ver. 1.466 >Reporter: Paul Croome >Assignee: OHTAKE Tomohiro >Priority: Minor > Attachments: Max_number_of_builds_to_keep_with_artifacts.png > > > In the job configuration page, under Post-build Actions > Archive the > Artifacts > Advanced > it's possible to select the checkbox "Discard all but the last > successful/stable artifact to save disk space". > It would be useful if I could choose "Discard all but the last 'n' > successful/stable artifacts to save disk space". > (By comparison: The option "Discard Old Builds" allows me to specify "Max # > of builds to keep". A similar feature for archived artifacts would be nice.) -- 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-13341) Upgrading to 1.458 with Jenkins on Ubuntu with OpenJDK cause Maven build to fail
[ https://issues.jenkins-ci.org/browse/JENKINS-13341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163339#comment-163339 ] Austin Adam commented on JENKINS-13341: --- Also on 1.466/Ubuntu 12.04 [JENKINS] Archiving site from /var/lib/jenkins/jobs/XX/workspace/target/site to /var/lib/jenkins/jobs/XX/site Failed to load native POSIX impl; falling back on Java impl. Stacktrace follows. java.lang.UnsatisfiedLinkError: Unable to load library 'libc.so.6': com.sun.jna.Native.open(Ljava/lang/String;)J at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:166) at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:239) at com.sun.jna.Library$Handler.(Library.java:140) at com.sun.jna.Native.loadLibrary(Native.java:366) at org.jruby.ext.posix.POSIXFactory.loadLibC(POSIXFactory.java:96) at org.jruby.ext.posix.POSIXFactory.loadLinuxPOSIX(POSIXFactory.java:65) at org.jruby.ext.posix.POSIXFactory.getPOSIX(POSIXFactory.java:24) at hudson.os.PosixAPI.(PosixAPI.java:40) at hudson.Util.resolveSymlink(Util.java:1067) at hudson.Util.resolveSymlink(Util.java:1030) at hudson.util.DirScanner$Glob.scan(DirScanner.java:115) at hudson.FilePath.writeToTar(FilePath.java:1804) at hudson.FilePath.copyRecursiveTo(FilePath.java:1731) at hudson.FilePath.copyRecursiveTo(FilePath.java:1660) at hudson.maven.reporters.MavenSiteArchiver.postExecute(MavenSiteArchiver.java:82) at hudson.maven.Maven3Builder$MavenExecutionListener.recordMojoEnded(Maven3Builder.java:421) at hudson.maven.Maven3Builder$MavenExecutionListener.mojoSucceeded(Maven3Builder.java:403) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:87) at org.apache.maven.lifecycle.internal.DefaultExecutionEventCatapult.fire(DefaultExecutionEventCatapult.java:42) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:228) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79) 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.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239) at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158) at hudson.maven.Maven3Builder.call(Maven3Builder.java:98) at hudson.maven.Maven3Builder.call(Maven3Builder.java:64) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) > Upgrading to 1.458 with Jenkins on Ubuntu with OpenJDK cause Maven build to > fail > > > Key: JENKINS-13341 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13341 > Project: Jenkins > Issue Type: Bug > Components: maven >Reporter: ravn > > After upgrading Ubuntu packaged Jenkins to 1.458 (using OpenJDK as installed > by apt-get) I receive the following failures: > > Failed to load native POSIX impl; falling back on Java impl. Sta
[JIRA] (JENKINS-13928) bad version number at offiset=6
[ https://issues.jenkins-ci.org/browse/JENKINS-13928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163338#comment-163338 ] Carl Chen commented on JENKINS-13928: - May 31, 2012 9:41:50 AM hudson.ExtensionFinder$GuiceFinder$4$1 get WARNING: Failed to instantiate. Skipping this component com.google.inject.ProvisionException: Guice provision errors: 1) Error injecting constructor, java.lang.UnsupportedClassVersionError: Bad version number in .class file at net.praqma.hudson.scm.CCUCMScm$CCUCMScmDescriptor.(CCUCMScm.java:1416) 1 error at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52) at com.google.inject.Scopes$1$1.get(Scopes.java:59) at hudson.ExtensionFinder$GuiceFinder$4$1.get(ExtensionFinder.java:420) at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41) at com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965) > bad version number at offiset=6 > --- > > Key: JENKINS-13928 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13928 > Project: Jenkins > Issue Type: Bug > Components: clearcase-ucm >Affects Versions: current > Environment: windows xp , tomcat 6.0.35, jenkins 1.465, > clearcase-ucm-plugin 1.0.7 >Reporter: Carl Chen >Assignee: Christian Wolfgang > Labels: plugin > > jenkins runs well, but after install this plugin, it reports bad version > number error. -- 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-10593) Project-based Matrix Authorization Strategy: allow a job to not inherit from global ACL
[ https://issues.jenkins-ci.org/browse/JENKINS-10593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-10593 started by Joe Hansche. > Project-based Matrix Authorization Strategy: allow a job to not inherit from > global ACL > --- > > Key: JENKINS-10593 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10593 > Project: Jenkins > Issue Type: New Feature > Components: core >Affects Versions: current > Environment: Jenkins 1.424 >Reporter: oeuftete >Assignee: Joe Hansche >Priority: Minor > > It would be excellent if the Project-based Matrix Authorization Strategy > allowed for a project to start its authorizations from zero instead of > inheriting from the main configuration. > For example, while the vast majority of projects may only need the default > ACL, a restricted access project may need to be limited to only a few users > or groups. As I understand it, the Project-based Matrix Authorization > Strategy is additive. So to do this now. the global config would need to > have the barest set of authorizations, and every job (except the very > restricted one) would have to have the "Enable project-based security" > configuration specified. -- 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-10593) Project-based Matrix Authorization Strategy: allow a job to not inherit from global ACL
[ https://issues.jenkins-ci.org/browse/JENKINS-10593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Hansche reassigned JENKINS-10593: - Assignee: Joe Hansche > Project-based Matrix Authorization Strategy: allow a job to not inherit from > global ACL > --- > > Key: JENKINS-10593 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10593 > Project: Jenkins > Issue Type: New Feature > Components: core >Affects Versions: current > Environment: Jenkins 1.424 >Reporter: oeuftete >Assignee: Joe Hansche >Priority: Minor > > It would be excellent if the Project-based Matrix Authorization Strategy > allowed for a project to start its authorizations from zero instead of > inheriting from the main configuration. > For example, while the vast majority of projects may only need the default > ACL, a restricted access project may need to be limited to only a few users > or groups. As I understand it, the Project-based Matrix Authorization > Strategy is additive. So to do this now. the global config would need to > have the barest set of authorizations, and every job (except the very > restricted one) would have to have the "Enable project-based security" > configuration specified. -- 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-13957) Matrix builds disappear after Jenkins upgrade
jspohr created JENKINS-13957: Summary: Matrix builds disappear after Jenkins upgrade Key: JENKINS-13957 URL: https://issues.jenkins-ci.org/browse/JENKINS-13957 Project: Jenkins Issue Type: Bug Components: matrix Environment: Jenkins 1.458, Tomcat 6, Ubuntu 10.4 Reporter: jspohr I'm currently stuck with Jenkins 1.458, because whenever I upgrade to any version after that one, most previous matrix builds are no longer accessible. On every matrix job's page, the configuration table shows all configurations as "Pending" or "Skipped". When I select a "Skipped" configuration, Jenkins opens a build that's about 2 months old. All builds before that date are accessible, but newer ones have vanished. I can't tell which version I used back then, maybe there was a change in respect to matrix build configurations? When I select a build node, its build history shows no matrix builds at all, only matrix parent builds. -- 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-13956) FitNesse : Connection reset
[ https://issues.jenkins-ci.org/browse/JENKINS-13956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163337#comment-163337 ] Pierre-Olivier Dubé commented on JENKINS-13956: --- Here is the classic console output I get from Jenkins : Started by upstream project "07 Engines" build number 7 Building in workspace C:\Documents and Settings\a350user\.jenkins\jobs\08 Repos Air Work Fl100\workspace hudson.plugins.fitnesse.FitnesseBuilder: {fitnessePortLocal=8080, fitnesseTargetPage=A350AutomatedTesting.Ata00Tests.Test1000RegressionTestSuite.Test1120ReposAirWorkFl100 , fitnessePathToJar=C:\cae\ATest\Fitnesse\fitnesse.jar, fitnesseTargetIsSuite=true, additionalFitnesseOptions=, fitnesseJavaOpts=, fitnesseHttpTimeout=600, fitnesseJavaWorkingDirectory=C:\cae\ATest\Fitnesse, fitnessePathToRoot=C:\cae\ATest\Fitnesse\FitNesseRoot, fitnessePathToXmlResultsOut=C:\AutoBuilder_FitNesse\Test1120ReposAirWorkFl100.xml, fitnesseStart=True} Starting new Fitnesse instance... [Fitnesse] $ java -jar C:\cae\ATest\Fitnesse\fitnesse.jar -d C:\cae\ATest\Fitnesse -r FitNesseRoot -p 8080 FitNesse (v20111026) Started... port: 8080 root page: fitnesse.wiki.FileSystemPage at C:\cae\ATest\Fitnesse/FitNesseRoot logger:none authenticator: fitnesse.authentication.PromiscuousAuthenticator html page factory: fitnesse.html.HtmlPageFactory page version expiration set to 14 days. Connnecting to http://localhost:8080/A350AutomatedTesting.Ata00Tests.Test1000RegressionTestSuite.Test1120ReposAirWorkFl100 ?suite&format=xml&includehtml Connected: 200/OK 4k... 5k... Xml results saved as windows-1252 to C:\AutoBuilder_FitNesse\Test1120ReposAirWorkFl100.xml Reading results as windows-1252 from C:\AutoBuilder_FitNesse\Test1120ReposAirWorkFl100.xml Parsing results... javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at hudson.plugins.fitnesse.NativePageCountsParser.transformRawResults(NativePageCountsParser.java:25) at hudson.plugins.fitnesse.NativePageCountsParser.parse(NativePageCountsParser.java:17) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:129) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:107) at hudson.plugins.fitnesse.FitnesseResultsRecorder.perform(FitnesseResultsRecorder.java:73) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1459) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source) ... 16 more Caused by: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source) ... 17 more - javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at hudson.plugins.fitnesse.NativePageCountsParser.transformRawResults(NativePageCountsParser.java:25) at hudson.plugins.fitnesse.NativePageCountsParser.parse(NativePageCountsParser.java:17) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:129) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:107) at hudson.plugins.fitnesse.FitnesseResultsRecorder.perform(FitnesseResultsRecorder.java:73) a
[JIRA] (JENKINS-13956) FitNesse : Connection reset
Pierre-Olivier Dubé created JENKINS-13956: - Summary: FitNesse : Connection reset Key: JENKINS-13956 URL: https://issues.jenkins-ci.org/browse/JENKINS-13956 Project: Jenkins Issue Type: Bug Components: fitnesse Affects Versions: current Reporter: Pierre-Olivier Dubé Fix For: current In a number of about 10 build (FitNesse tests) jobs ran every night, Jenkins "decides" not to run one of the jobs (not always the same job every day) correctly thus passing to the next job without running the FitNesse tests. Here is the classic console output I get from Jenkins : Started by upstream project "07 Engines" build number 7 Building in workspace C:\Documents and Settings\a350user\.jenkins\jobs\08 Repos Air Work Fl100\workspace hudson.plugins.fitnesse.FitnesseBuilder: {fitnessePortLocal=8080, fitnesseTargetPage=A350AutomatedTesting.Ata00Tests.Test1000RegressionTestSuite.Test1120ReposAirWorkFl100 , fitnessePathToJar=C:\cae\ATest\Fitnesse\fitnesse.jar, fitnesseTargetIsSuite=true, additionalFitnesseOptions=, fitnesseJavaOpts=, fitnesseHttpTimeout=600, fitnesseJavaWorkingDirectory=C:\cae\ATest\Fitnesse, fitnessePathToRoot=C:\cae\ATest\Fitnesse\FitNesseRoot, fitnessePathToXmlResultsOut=C:\AutoBuilder_FitNesse\Test1120ReposAirWorkFl100.xml, fitnesseStart=True} Starting new Fitnesse instance... [Fitnesse] $ java -jar C:\cae\ATest\Fitnesse\fitnesse.jar -d C:\cae\ATest\Fitnesse -r FitNesseRoot -p 8080 FitNesse (v20111026) Started... port: 8080 root page: fitnesse.wiki.FileSystemPage at C:\cae\ATest\Fitnesse/FitNesseRoot logger:none authenticator: fitnesse.authentication.PromiscuousAuthenticator html page factory: fitnesse.html.HtmlPageFactory page version expiration set to 14 days. Connnecting to http://localhost:8080/A350AutomatedTesting.Ata00Tests.Test1000RegressionTestSuite.Test1120ReposAirWorkFl100 ?suite&format=xml&includehtml Connected: 200/OK 4k... 5k... Xml results saved as windows-1252 to C:\AutoBuilder_FitNesse\Test1120ReposAirWorkFl100.xml Reading results as windows-1252 from C:\AutoBuilder_FitNesse\Test1120ReposAirWorkFl100.xml Parsing results... javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at hudson.plugins.fitnesse.NativePageCountsParser.transformRawResults(NativePageCountsParser.java:25) at hudson.plugins.fitnesse.NativePageCountsParser.parse(NativePageCountsParser.java:17) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:129) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:107) at hudson.plugins.fitnesse.FitnesseResultsRecorder.perform(FitnesseResultsRecorder.java:73) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1459) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source) ... 16 more Caused by: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source) ... 17 more - javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at hudson.plugins.fitnesse.NativePageCountsParser.transformRawResults(NativePageCountsParser.java:25) at hudson.p
[JIRA] (JENKINS-13956) FitNesse : Connection reset
[ https://issues.jenkins-ci.org/browse/JENKINS-13956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Olivier Dubé updated JENKINS-13956: -- Description: In a number of about 10 build (FitNesse tests) jobs ran every night, Jenkins "decides" not to run one of the jobs (not always the same job every day) correctly thus passing to the next job without running the FitNesse tests. An example of a classic console output can be found in the issue's comments. was: In a number of about 10 build (FitNesse tests) jobs ran every night, Jenkins "decides" not to run one of the jobs (not always the same job every day) correctly thus passing to the next job without running the FitNesse tests. Here is the classic console output I get from Jenkins : Started by upstream project "07 Engines" build number 7 Building in workspace C:\Documents and Settings\a350user\.jenkins\jobs\08 Repos Air Work Fl100\workspace hudson.plugins.fitnesse.FitnesseBuilder: {fitnessePortLocal=8080, fitnesseTargetPage=A350AutomatedTesting.Ata00Tests.Test1000RegressionTestSuite.Test1120ReposAirWorkFl100 , fitnessePathToJar=C:\cae\ATest\Fitnesse\fitnesse.jar, fitnesseTargetIsSuite=true, additionalFitnesseOptions=, fitnesseJavaOpts=, fitnesseHttpTimeout=600, fitnesseJavaWorkingDirectory=C:\cae\ATest\Fitnesse, fitnessePathToRoot=C:\cae\ATest\Fitnesse\FitNesseRoot, fitnessePathToXmlResultsOut=C:\AutoBuilder_FitNesse\Test1120ReposAirWorkFl100.xml, fitnesseStart=True} Starting new Fitnesse instance... [Fitnesse] $ java -jar C:\cae\ATest\Fitnesse\fitnesse.jar -d C:\cae\ATest\Fitnesse -r FitNesseRoot -p 8080 FitNesse (v20111026) Started... port: 8080 root page: fitnesse.wiki.FileSystemPage at C:\cae\ATest\Fitnesse/FitNesseRoot logger:none authenticator: fitnesse.authentication.PromiscuousAuthenticator html page factory: fitnesse.html.HtmlPageFactory page version expiration set to 14 days. Connnecting to http://localhost:8080/A350AutomatedTesting.Ata00Tests.Test1000RegressionTestSuite.Test1120ReposAirWorkFl100 ?suite&format=xml&includehtml Connected: 200/OK 4k... 5k... Xml results saved as windows-1252 to C:\AutoBuilder_FitNesse\Test1120ReposAirWorkFl100.xml Reading results as windows-1252 from C:\AutoBuilder_FitNesse\Test1120ReposAirWorkFl100.xml Parsing results... javax.xml.transform.TransformerException: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at hudson.plugins.fitnesse.NativePageCountsParser.transformRawResults(NativePageCountsParser.java:25) at hudson.plugins.fitnesse.NativePageCountsParser.parse(NativePageCountsParser.java:17) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:129) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:107) at hudson.plugins.fitnesse.FitnesseResultsRecorder.perform(FitnesseResultsRecorder.java:73) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1459) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source) ... 16 more Caused by: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.dom.XSLTCDTMManager.getDTM(Unknown Source) ... 17 more - javax.xml.transform.TransformerException: com.sun.org.apache.xml.internal.utils.WrappedRuntimeException: Connection reset at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.getDOM(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(Unknown Source) at hudson.plu
[JIRA] (JENKINS-13227) CVS plugin 2.1 does not detect changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163336#comment-163336 ] Amir Isfy commented on JENKINS-13227: - Brilliant. It works. Thanks Michael. I am only working with 'cvs checkout' since 'cvs update' overwrites the Tag file and screws everything up (issue 13789: this is a huge problem for us since our code is massive and a clean checkout and build from scratch every time kills the turn around times of these projects that deal with branches). Can someone look at this please. > CVS plugin 2.1 does not detect changes > -- > > Key: JENKINS-13227 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13227 > Project: Jenkins > Issue Type: Bug > Components: cvs >Reporter: Guillaume Bilodeau >Assignee: Michael Clarke >Priority: Critical > Labels: cvs > Attachments: rlog.txt > > > As presented in the user group: > https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Dvv0I3FBNW4 > We've been running Jenkins 1.451 and 1.454 on Windows XP against a CVS > repository for a few weeks now, without any problems. The CVS plugin (v1.6) > was using the local cvsnt install. > We've since upgraded the CVS plugin to version 2.1 (by manually pinning the > plugin) and since then, CVS changes are not detected. The CVS polling log is > triggered properly, tons of "cvs rlog" instructions are sent, but at the end > "No changes" is displayed. > Using CVS plugin 1.6 the cvs polling command looked like this (executed at > 5:26:21 PM EDT): > cvs -q -z3 -n update -PdC -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D > "Thursday, March 22, 2012 9:26:21 PM UTC" > Using CVS plugin 2.1, the last cvs checkout command looked like this > (executed at 11:56:16 AM EDT): > cvs checkout -P -r d-chg00014229_op_brc_preimp-op-2012-02-27 -D 23 Mar 2012 > 11:56:16 EDT -d portailInt portailInt > We're in Montreal, so Eastern Time Zone with Daylight Saving Time in effect. -- 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-5131) Use a regex / replace pair to transform the scm commit message.
[ https://issues.jenkins-ci.org/browse/JENKINS-5131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slide-O-Mix resolved JENKINS-5131. -- Resolution: Fixed You can do this with the groovy scripting templates. > Use a regex / replace pair to transform the scm commit message. > --- > > Key: JENKINS-5131 > URL: https://issues.jenkins-ci.org/browse/JENKINS-5131 > Project: Jenkins > Issue Type: New Feature > Components: email-ext >Affects Versions: current >Reporter: philippebourgau > Fix For: current > > Attachments: regex.diff > > > We are using Hudson, and the email-ext plugin. In order to integrate with our > CRM, we use a special formatting for the comments of the revisions in our > SCM. This makes the comments difficult to read, especially in an email, > that's why we needed a regex/replace mechanism. > Here is a patch to extend it to allow transforming the revision messages sent > by email according to some regex/replace strings. The regex/replace pair are > given as additional parameters to the ${CHANGES} and > ${CHANGES_SINCE_LAST_SUCESS} tokens. > The attached svn patch was made from revision 24135. -- 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-13842) Mercurial poll triggers build due to unrelated changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163334#comment-163334 ] jglick commented on JENKINS-13842: -- A test case would be something like a bundle repo (or a set of Hg commands to create an equivalent repo starting with hg init), plus the SCM snippet from a job config.xml - whatever concrete instructions are needed to reproduce the issue from scratch. (A unit test is of course ideal but more work to prepare if you have not played with the sources.) Regarding Mercurial versions, my own organization runs 1.3.1 on some servers due to a serious regression in the merge algorithm in 1.4. General policy for the plugin is that it should work on 1.0+ unless there is a compelling need to require a newer version; certain optional features are conditionally enabled based on version, such as hg relink. > Mercurial poll triggers build due to unrelated changes > -- > > Key: JENKINS-13842 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13842 > Project: Jenkins > Issue Type: Bug > Components: mercurial >Affects Versions: current >Reporter: Thomas Lotze >Assignee: Kohsuke Kawaguchi > > The current Mercurial poll command is formulated such that it may falsely > detect new changes if there have ever been any branches with the same name as > that relevant to the build, but which are not ancestors of the current > working-directory revision in terms of the revision DAG. > If the repository happens to contain another branch with the same name, > Jenkins will continuously build the project and the only way to stop it is to > push a dummy merge of that other branch into the line of development Jenkins > is supposed to build. > A better way to ask for new descendants of the current working-directory > revision would be this: > hg log --branch $branch --rev "descendants(children($revision))" > The children predicate is needed because descendants always include the named > revision itself. -- 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-13836) Stable release issues|Loading All Build History Fails in stable release 1.447.1
[ https://issues.jenkins-ci.org/browse/JENKINS-13836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16#comment-16 ] Yusuf Burmawala commented on JENKINS-13836: --- Thanks Hiteswar, What is the release schedule for LTS 1.447.2? > Stable release issues|Loading All Build History Fails in stable release > 1.447.1 > --- > > Key: JENKINS-13836 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13836 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Prodution >Reporter: Arvind Ramalingam >Priority: Blocker > > Hi I have upgraded my Production Jenkins to 1.447.1 and I am not able to see > my build history.When I try to view more of my build history I get the below > error.Please let me know which stable release should i revert back to and I > was at 1.409 and everything was fine. > HTTP Status 404 - > type Status report > message > description The requested resource () is not available. > Apache Tomcat/6.0.26 -- 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-9913) Concurrent builds getting batched/nodes not getting released when jobs are completed
[ https://issues.jenkins-ci.org/browse/JENKINS-9913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163332#comment-163332 ] Sergey Smirnov commented on JENKINS-9913: - Do anybody read this ticket? This bug make our work slow. Help! > Concurrent builds getting batched/nodes not getting released when jobs are > completed > > > Key: JENKINS-9913 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9913 > Project: Jenkins > Issue Type: Bug > Components: concurrent-build >Affects Versions: current > Environment: RedHat Enterprise Linux 4.8, Jenkins 1.414 >Reporter: Philip Metting van Rijn >Assignee: Kohsuke Kawaguchi > > We're experiencing an issue with concurrent builds where Jenkins appears to > be associating separate builds (run on different machines) such that they > won't be marked as completed until all jobs are completed. For example, if > we kick off 5 concurrent builds on 5 different nodes, builds 1-4 won't be > marked as completed if build #5 is still running, even though builds 1-4 are > finished. I've seen a report of someone experiencing this issue elsewhere: > http://groups.google.com/group/jenkinsci-users/browse_thread/thread/e477e25910266d2a?fwc=1 > but a solution wasn't posted. We do not have the batch plugin or the locks > and latches plugin installed. We've disabled all post-build processing and > switched between different containers (Glassfish/Tomcat), but the problem > persists. I couldn't find an issue logged for this other than the > aforementioned posting. -- 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-13955) Git should write some file with content of $GIT_COMMIT environment variable
[ https://issues.jenkins-ci.org/browse/JENKINS-13955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Neto updated JENKINS-13955: - Summary: Git should write some file with content of $GIT_COMMIT environment variable (was: Git should write some file with content of $GIT_COMMIT environment) > Git should write some file with content of $GIT_COMMIT environment variable > --- > > Key: JENKINS-13955 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13955 > Project: Jenkins > Issue Type: Bug > Components: git >Affects Versions: current >Reporter: David Neto >Assignee: Nicolas De Loof >Priority: Minor > Labels: git, jenkins, plugin > > I can only reach the environment variable $COMMIT_MESSAGE by the build itself > On SVN plugin it writes a file on $WORKSPACE/../builds/$BUILD_NUMBER/ with > the revision of that build. And then I can get the revision of the build > commit by knowing only the build number anywhere (promotions-build plugin or > any other) > I couldn't find somewhere else to open this "issue". It actually is a feature > request. -- 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-13630) TestLink plugin does not update test case execution status correctly
[ https://issues.jenkins-ci.org/browse/JENKINS-13630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13630 started by Bruno P. Kinoshita. > TestLink plugin does not update test case execution status correctly > > > Key: JENKINS-13630 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13630 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current > Environment: Windows 2003, TestLink 1.9.3, Jenkins 1.461, TestLink > Plugin 3.1.2 >Reporter: Robert Campbell >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: jenkins, plugins, testlink > Attachments: TestCase_result_bug.jpg > > > Using the jenkins-testlink-plugin-tutorial example, the test case is executed > correctly and is passed as part of the Jenkins job. Under Test Execution in > TestLink the test case Status is reported as Passed yet the Result is still > set to "Not Run". See attached screenshot. -- 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-13630) TestLink plugin does not update test case execution status correctly
[ https://issues.jenkins-ci.org/browse/JENKINS-13630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163331#comment-163331 ] Bruno P. Kinoshita commented on JENKINS-13630: -- Successfully reproduced the issue. Thanks for reporting. I will debug TestLink and the plug-in to find out whether it is a bug in the plug-in or in the TestLink XML-RPC API. > TestLink plugin does not update test case execution status correctly > > > Key: JENKINS-13630 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13630 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current > Environment: Windows 2003, TestLink 1.9.3, Jenkins 1.461, TestLink > Plugin 3.1.2 >Reporter: Robert Campbell >Assignee: Bruno P. Kinoshita >Priority: Minor > Labels: jenkins, plugins, testlink > Attachments: TestCase_result_bug.jpg > > > Using the jenkins-testlink-plugin-tutorial example, the test case is executed > correctly and is passed as part of the Jenkins job. Under Test Execution in > TestLink the test case Status is reported as Passed yet the Result is still > set to "Not Run". See attached screenshot. -- 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-13955) Git should write some file with content of $GIT_COMMIT environment
David Neto created JENKINS-13955: Summary: Git should write some file with content of $GIT_COMMIT environment Key: JENKINS-13955 URL: https://issues.jenkins-ci.org/browse/JENKINS-13955 Project: Jenkins Issue Type: Bug Components: git Affects Versions: current Reporter: David Neto Assignee: Nicolas De Loof Priority: Minor I can only reach the environment variable $COMMIT_MESSAGE by the build itself On SVN plugin it writes a file on $WORKSPACE/../builds/$BUILD_NUMBER/ with the revision of that build. And then I can get the revision of the build commit by knowing only the build number anywhere (promotions-build plugin or any other) I couldn't find somewhere else to open this "issue". It actually is a feature request. -- 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-13954) Add an option so that the build doesn't fail if cppcheck can't find the XML file.
Nick James created JENKINS-13954: Summary: Add an option so that the build doesn't fail if cppcheck can't find the XML file. Key: JENKINS-13954 URL: https://issues.jenkins-ci.org/browse/JENKINS-13954 Project: Jenkins Issue Type: Improvement Components: cppcheck Affects Versions: current Reporter: Nick James Assignee: Gregory Boissinot Priority: Minor I've got a multi-configuration job which compiles on both Linux and Solaris. The cppcheck binary I use is compiled for Solaris and not Linux, so in the job configuration I only generate the cppcheck XML if the build is being run on Solaris. I want to publish out the cppcheck results, but this always causes the Linux build to fail as it hasn't generated the XML file. Is it possible to add a setting that ignores the file not existing? There's already something similar for when the file is blank... -- 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-6651) Hudson crashes for unknown reasons
[ https://issues.jenkins-ci.org/browse/JENKINS-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163329#comment-163329 ] SCM/JIRA link daemon commented on JENKINS-6651: --- Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/security/PAMSecurityRealm.java http://jenkins-ci.org/commit/pam-auth-plugin/8c9db12f57587d604073f5e9523a539d023a7be4 Log: [JENKINS-6651] inserting artificial lock in the hope that this will eliminate libpam crash. Originally-Committed-As: 86ec2a30f646d90aa4bbe91e3d4937e5661c409e > Hudson crashes for unknown reasons > -- > > Key: JENKINS-6651 > URL: https://issues.jenkins-ci.org/browse/JENKINS-6651 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Ubuntu 8.10, 4x 3.2 GHz Xeon, 4 GB RAM, sun-java6-jdk-u20 >Reporter: paalnilsen >Priority: Critical > Attachments: backtrace-2010-04-12.gz, backtrace-2010-04-19.gz, > backtrace-2010-04-19.gz, backtrace-2010-05-28.gz, > hudson.log.backtrace-2010-06-09_1.gz, hudson.log.backtrace-2010-06-09_2.gz, > Update_Center__Hudson_.pdf > > > This has happened a couple of times before. Hudson just seems to crash > without any comprehensible evidence in the log. There is a backtrace and > mem-map, but I am not a developer so I don't quite understand exactly what is > going on. I am hoping you have some ideas. > I see some references to libpam-ldap.so. We are not using LDAP directly in > Hudson, but authenticating via the Unix user database. Ubuntu then does the > LDAP auth. All this is working flawless, and the crashes seem very random. > There are not many people logging in and out of Hudson. Users are me + six > developers. > There is the Master server and four slaves. The slaves can build maximum two > jobs each simultaneously. They are all using Ubuntu + one Fedora, and have > about the same specs. Everything connected through Dell enterprise class > switches with gigabit copper. > Let me know if you need more information. List of installed plugins (all > latest version as of Hudson 1.359) and the last 5000 lines from three logs > attached. -- 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-9094) Remember me box doesn't work with unix groups
[ https://issues.jenkins-ci.org/browse/JENKINS-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163326#comment-163326 ] SCM/JIRA link daemon commented on JENKINS-9094: --- Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/security/PAMSecurityRealm.java test/src/test/java/hudson/security/PAMSecurityRealmTest.java http://jenkins-ci.org/commit/pam-auth-plugin/9057f6bd21cabac0f1d7b16d720fa4cb5c9f51ca Log: [FIXED JENKINS-9094] "Remember me" doesn't work with PAM Originally-Committed-As: ca4de00c2c93b156a3e4ffc1d5c39d13e351792e > Remember me box doesn't work with unix groups > - > > Key: JENKINS-9094 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9094 > Project: Jenkins > Issue Type: Bug > Components: security >Affects Versions: current >Reporter: jpschewe > > When I login and check the box > "Remember me" and then come back later the list of projects displayed > only include those that I explicitly have permission to see, but doesn't > include those that I have permission to see because of the groups that > I'm in. I'm using pam authentication and have set a group to have admin > privileges and groups to have privileges to most of my projects. In > addition I have listed myself explicitly on some projects to have extra > privileges. When I come back to visit I don't have the "Manage Jenkins" > link nor do I see the projects that I should have access to because of > my groups. If I log out and log back in, then I see everything as I should. -- 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-13526) PAM security realm should have a way to differentiate users from groups
[ https://issues.jenkins-ci.org/browse/JENKINS-13526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163330#comment-163330 ] SCM/JIRA link daemon commented on JENKINS-13526: Code changed in jenkins User: Rob Petti Path: core/src/main/java/hudson/security/PAMSecurityRealm.java core/src/main/resources/hudson/security/PAMSecurityRealm/help.html http://jenkins-ci.org/commit/pam-auth-plugin/17721734698d56dbe0f654f52f27353df08235c9 Log: [FIXED JENKINS-13526] use '@' prefix to force PAM to interpret the user/group as a group Originally-Committed-As: db1b7eef1a9a67b5f08e73d349230e0cec5a485d > PAM security realm should have a way to differentiate users from groups > --- > > Key: JENKINS-13526 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13526 > Project: Jenkins > Issue Type: Improvement > Components: core, security >Reporter: Rob Petti > > This is an issue that came up in the #jenkins irc channel. > There is currently a limitation when using PAM with matrix based security. If > a group's name matches that of a user, it cannot be used in the > configuration, as it will always select the user instead of the group. > I propose supporting a prefix, such as '@' that will explicitly identify the > group/user as a group. -- 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-9094) Remember me box doesn't work with unix groups
[ https://issues.jenkins-ci.org/browse/JENKINS-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163327#comment-163327 ] SCM/JIRA link daemon commented on JENKINS-9094: --- Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/security/PAMSecurityRealm.java test/src/test/java/hudson/security/PAMSecurityRealmTest.java http://jenkins-ci.org/commit/pam-auth-plugin/f2476afc8f9c64beb07f29d8f2c74638896e71b5 Log: [FIXED JENKINS-9094] "Remember me" doesn't work with PAM Originally-Committed-As: c21918df7e9b783c12d1bdc775b45b9531da7032 > Remember me box doesn't work with unix groups > - > > Key: JENKINS-9094 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9094 > Project: Jenkins > Issue Type: Bug > Components: security >Affects Versions: current >Reporter: jpschewe > > When I login and check the box > "Remember me" and then come back later the list of projects displayed > only include those that I explicitly have permission to see, but doesn't > include those that I have permission to see because of the groups that > I'm in. I'm using pam authentication and have set a group to have admin > privileges and groups to have privileges to most of my projects. In > addition I have listed myself explicitly on some projects to have extra > privileges. When I come back to visit I don't have the "Manage Jenkins" > link nor do I see the projects that I should have access to because of > my groups. If I log out and log back in, then I see everything as I should. -- 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-9681) NIS / PAM authentication should use AbstractPasswordBasedSecurityRealm (PAMSecurityRealm should extend it)
[ https://issues.jenkins-ci.org/browse/JENKINS-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163328#comment-163328 ] SCM/JIRA link daemon commented on JENKINS-9681: --- Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/security/PAMSecurityRealm.java war/src/main/webapp/WEB-INF/security/PAMSecurityRealm.groovy http://jenkins-ci.org/commit/pam-auth-plugin/e6c2debacd061b4480868ee925b34f7189e4dd7f Log: [FIXED JENKINS-9681] PAM now supports CLI auth ... by extending from AbstractPasswordBasedSecurityRealm. Originally-Committed-As: 6a75fe64e69c9f53757603fc849c16099dfc483a > NIS / PAM authentication should use AbstractPasswordBasedSecurityRealm > (PAMSecurityRealm should extend it) > -- > > Key: JENKINS-9681 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9681 > Project: Jenkins > Issue Type: Bug > Components: cli >Reporter: Damien Nozay > > PAMSecurityRealm extends SecurityRealm. > PAMSecurityRealm should extend AbstractPasswordBasedSecurityRealm instead. > This is necessary for CLI to work with PAM authentication scheme. > see also JENKINS-7995. -- 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-13953) can't Deploy artifacts to Artifactory
[ https://issues.jenkins-ci.org/browse/JENKINS-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maritzabell suarez reassigned JENKINS-13953: Assignee: (was: maritzabell suarez) > can't Deploy artifacts to Artifactory > - > > Key: JENKINS-13953 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13953 > Project: Jenkins > Issue Type: Bug > Components: artifactdeployer >Affects Versions: current >Reporter: maritzabell suarez > Labels: plugin > Attachments: ArtifactoryConfigurationOnJenkins.jpg, > ArtifactoryConfigurationOnJenkinsTask.jpg > > > hi! > i'm trying to deploy artifacts to artifactory and i followed the tutorial, > however, i got the same problem no matter what: > Waiting for Jenkins to finish collecting data > channel stopped > Deploying artifacts to http://192.168.1.22/artifactory > Deploying artifacts of module: > etask.components.security:COM-SecurityGuardEntities > ERROR: null > java.lang.NullPointerException > at > org.jfrog.hudson.util.BuildUniqueIdentifierHelper.getUpstreamIdentifier(BuildUniqueIdentifierHelper.java:106) > at > org.jfrog.hudson.maven2.ArtifactsDeployer.deployArtifact(ArtifactsDeployer.java:170) > at > org.jfrog.hudson.maven2.ArtifactsDeployer.deploy(ArtifactsDeployer.java:127) > at > org.jfrog.hudson.ArtifactoryRedeployPublisher.perform(ArtifactoryRedeployPublisher.java:300) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:994) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) > at hudson.model.Run.run(Run.java:1463) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:239) > Build step 'Deploy artifacts to Artifactory' changed build result to FAILURE > Finished: FAILURE > it doesn't say anything i can use to resolve the problem. > i attached the configuration of jenkins > thank you so much for the help, > Maritzabell Suarez -- 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-8152) LDAP config error
[ https://issues.jenkins-ci.org/browse/JENKINS-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163325#comment-163325 ] SCM/JIRA link daemon commented on JENKINS-8152: --- Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/security/LDAPSecurityRealm.java http://jenkins-ci.org/commit/ldap-plugin/c32808c8d74c4b5508689040863529c3676defc4 Log: [FIXED JENKINS-8152] Formatting error in the rootDN inference code. It shouldn't include attribute name. Originally-Committed-As: c99fc315dddf707dba3a2dea6a048bd76dce4c2e > LDAP config error > - > > Key: JENKINS-8152 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8152 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Hudson 1.386; Windows XP; Hudson's built-in container > (no Tomcat) >Reporter: cjyar > > Configuring LDAP authentication in Hudson: > Server: ldaps://directory.sri.com > root DN: o=SRI International,c=US > User search base: > User search filter: uid={0} > Group search base: > Manager DN: > Manager Password: > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'initialDirContextFactory': Instantiation of bean failed; nested > exception is org.springframework.beans.BeanInstantiationException: Could not > instantiate bean class > [org.acegisecurity.ldap.DefaultInitialDirContextFactory]: Constructor threw > exception; nested exception is java.lang.IllegalArgumentException: Root DNs > must be the same when using multiple URLs > at > org.springframework.beans.factory.support.ConstructorResolver.autowireConstructor(ConstructorResolver.java:231) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.autowireConstructor(AbstractAutowireCapableBeanFactory.java:957) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBeanInstance(AbstractAutowireCapableBeanFactory.java:869) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:514) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory$1.run(AbstractAutowireCapableBeanFactory.java:485) > at java.security.AccessController.doPrivileged(Native Method) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:455) > at > org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:251) > at > org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:169) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:248) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:170) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:413) > at > org.springframework.context.support.AbstractApplicationContext.finishBeanFactoryInitialization(AbstractApplicationContext.java:735) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:369) > at > hudson.util.spring.DefaultRuntimeSpringConfiguration.getApplicationContext(DefaultRuntimeSpringConfiguration.java:94) > at > hudson.util.spring.BeanBuilder.createApplicationContext(BeanBuilder.java:388) > at > hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:344) > at > hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:359) > at hudson.security.HudsonFilter.reset(HudsonFilter.java:134) > at hudson.model.Hudson.setSecurityRealm(Hudson.java:1833) > at hudson.model.Hudson.doConfigSubmit(Hudson.java:2345) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) > at java.lang.reflect.Method.invoke(Unknown Source) > 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:102) > at > org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) > at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:562) > at org.kohsuke.stapler.Stapler.inv
[JIRA] (JENKINS-13953) can't Deploy artifacts to Artifactory
maritzabell suarez created JENKINS-13953: Summary: can't Deploy artifacts to Artifactory Key: JENKINS-13953 URL: https://issues.jenkins-ci.org/browse/JENKINS-13953 Project: Jenkins Issue Type: Bug Components: artifactdeployer Affects Versions: current Reporter: maritzabell suarez Assignee: Gregory Boissinot Attachments: ArtifactoryConfigurationOnJenkins.jpg, ArtifactoryConfigurationOnJenkinsTask.jpg hi! i'm trying to deploy artifacts to artifactory and i followed the tutorial, however, i got the same problem no matter what: Waiting for Jenkins to finish collecting data channel stopped Deploying artifacts to http://192.168.1.22/artifactory Deploying artifacts of module: etask.components.security:COM-SecurityGuardEntities ERROR: null java.lang.NullPointerException at org.jfrog.hudson.util.BuildUniqueIdentifierHelper.getUpstreamIdentifier(BuildUniqueIdentifierHelper.java:106) at org.jfrog.hudson.maven2.ArtifactsDeployer.deployArtifact(ArtifactsDeployer.java:170) at org.jfrog.hudson.maven2.ArtifactsDeployer.deploy(ArtifactsDeployer.java:127) at org.jfrog.hudson.ArtifactoryRedeployPublisher.perform(ArtifactoryRedeployPublisher.java:300) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:994) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1463) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Build step 'Deploy artifacts to Artifactory' changed build result to FAILURE Finished: FAILURE it doesn't say anything i can use to resolve the problem. i attached the configuration of jenkins thank you so much for the help, Maritzabell Suarez -- 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-13953) can't Deploy artifacts to Artifactory
[ https://issues.jenkins-ci.org/browse/JENKINS-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maritzabell suarez reassigned JENKINS-13953: Assignee: maritzabell suarez (was: Gregory Boissinot) > can't Deploy artifacts to Artifactory > - > > Key: JENKINS-13953 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13953 > Project: Jenkins > Issue Type: Bug > Components: artifactdeployer >Affects Versions: current >Reporter: maritzabell suarez >Assignee: maritzabell suarez > Labels: plugin > Attachments: ArtifactoryConfigurationOnJenkins.jpg, > ArtifactoryConfigurationOnJenkinsTask.jpg > > > hi! > i'm trying to deploy artifacts to artifactory and i followed the tutorial, > however, i got the same problem no matter what: > Waiting for Jenkins to finish collecting data > channel stopped > Deploying artifacts to http://192.168.1.22/artifactory > Deploying artifacts of module: > etask.components.security:COM-SecurityGuardEntities > ERROR: null > java.lang.NullPointerException > at > org.jfrog.hudson.util.BuildUniqueIdentifierHelper.getUpstreamIdentifier(BuildUniqueIdentifierHelper.java:106) > at > org.jfrog.hudson.maven2.ArtifactsDeployer.deployArtifact(ArtifactsDeployer.java:170) > at > org.jfrog.hudson.maven2.ArtifactsDeployer.deploy(ArtifactsDeployer.java:127) > at > org.jfrog.hudson.ArtifactoryRedeployPublisher.perform(ArtifactoryRedeployPublisher.java:300) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) > at > hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) > at > hudson.maven.MavenModuleSetBuild$RunnerImpl.post2(MavenModuleSetBuild.java:994) > at > hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) > at hudson.model.Run.run(Run.java:1463) > at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:239) > Build step 'Deploy artifacts to Artifactory' changed build result to FAILURE > Finished: FAILURE > it doesn't say anything i can use to resolve the problem. > i attached the configuration of jenkins > thank you so much for the help, > Maritzabell Suarez -- 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-13863) MSBuild is unable to build projects in a different directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163324#comment-163324 ] Aaron Laws edited comment on JENKINS-13863 at 5/30/12 4:04 PM: --- I should have attached this earlier. There's no command line argument, just specify the path to the project as the project file argument. Please see "{{betterbuild.txt}}" which I just ran by hand from the command line. was (Author: limited_atonement): I should have attached this earlier. There's no command line argument, just specify the path to the project as the project file argument. (please see "{{betterbuild.txt}}") > MSBuild is unable to build projects in a different directory > > > Key: JENKINS-13863 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13863 > Project: Jenkins > Issue Type: Bug > Components: msbuild >Affects Versions: current > Environment: MS Windows Server 2008 >Reporter: Aaron Laws >Assignee: kdsweeney >Priority: Minor > Labels: path, plugin > Attachments: badbuild.txt, badconfig.PNG, betterbuild.txt, > goodbuild.txt, goodconfig.PNG > > > I use SVN to checkout a project to {{.\proj\}} and a dependency to > {{.\dep\}}. The {{.sln}} file is at {{.\proj\proj.sln}}. I us the MsBuild > plugin with the setting "MsBuild Build File" = "{{proj\proj.sln}}" (or a > number of variants such as {{.\proj\proj.sln}}). Msbuild fails with > {{MSB1009: Project file does not exist.}} However, running a similar command > manually succeeds. -- 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-13863) MSBuild is unable to build projects in a different directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163324#comment-163324 ] Aaron Laws edited comment on JENKINS-13863 at 5/30/12 4:03 PM: --- I should have attached this earlier. There's no command line argument, just specify the path to the project as the project file argument. (please see "better build.txt") was (Author: limited_atonement): I should have attached this earlier. There's no command line argument, just specify the path to the project as the project file argument. > MSBuild is unable to build projects in a different directory > > > Key: JENKINS-13863 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13863 > Project: Jenkins > Issue Type: Bug > Components: msbuild >Affects Versions: current > Environment: MS Windows Server 2008 >Reporter: Aaron Laws >Assignee: kdsweeney >Priority: Minor > Labels: path, plugin > Attachments: badbuild.txt, badconfig.PNG, betterbuild.txt, > goodbuild.txt, goodconfig.PNG > > > I use SVN to checkout a project to {{.\proj\}} and a dependency to > {{.\dep\}}. The {{.sln}} file is at {{.\proj\proj.sln}}. I us the MsBuild > plugin with the setting "MsBuild Build File" = "{{proj\proj.sln}}" (or a > number of variants such as {{.\proj\proj.sln}}). Msbuild fails with > {{MSB1009: Project file does not exist.}} However, running a similar command > manually succeeds. -- 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-13863) MSBuild is unable to build projects in a different directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163324#comment-163324 ] Aaron Laws edited comment on JENKINS-13863 at 5/30/12 4:03 PM: --- I should have attached this earlier. There's no command line argument, just specify the path to the project as the project file argument. (please see "{{betterbuild.txt}}") was (Author: limited_atonement): I should have attached this earlier. There's no command line argument, just specify the path to the project as the project file argument. (please see "better build.txt") > MSBuild is unable to build projects in a different directory > > > Key: JENKINS-13863 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13863 > Project: Jenkins > Issue Type: Bug > Components: msbuild >Affects Versions: current > Environment: MS Windows Server 2008 >Reporter: Aaron Laws >Assignee: kdsweeney >Priority: Minor > Labels: path, plugin > Attachments: badbuild.txt, badconfig.PNG, betterbuild.txt, > goodbuild.txt, goodconfig.PNG > > > I use SVN to checkout a project to {{.\proj\}} and a dependency to > {{.\dep\}}. The {{.sln}} file is at {{.\proj\proj.sln}}. I us the MsBuild > plugin with the setting "MsBuild Build File" = "{{proj\proj.sln}}" (or a > number of variants such as {{.\proj\proj.sln}}). Msbuild fails with > {{MSB1009: Project file does not exist.}} However, running a similar command > manually succeeds. -- 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-13863) MSBuild is unable to build projects in a different directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Laws updated JENKINS-13863: - Attachment: betterbuild.txt I should have attached this earlier. There's no command line argument, just specify the path to the project as the project file argument. > MSBuild is unable to build projects in a different directory > > > Key: JENKINS-13863 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13863 > Project: Jenkins > Issue Type: Bug > Components: msbuild >Affects Versions: current > Environment: MS Windows Server 2008 >Reporter: Aaron Laws >Assignee: kdsweeney >Priority: Minor > Labels: path, plugin > Attachments: badbuild.txt, badconfig.PNG, betterbuild.txt, > goodbuild.txt, goodconfig.PNG > > > I use SVN to checkout a project to {{.\proj\}} and a dependency to > {{.\dep\}}. The {{.sln}} file is at {{.\proj\proj.sln}}. I us the MsBuild > plugin with the setting "MsBuild Build File" = "{{proj\proj.sln}}" (or a > number of variants such as {{.\proj\proj.sln}}). Msbuild fails with > {{MSB1009: Project file does not exist.}} However, running a similar command > manually succeeds. -- 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-13952) Coverity plugin cannot connect to CIM instance
[ https://issues.jenkins-ci.org/browse/JENKINS-13952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163323#comment-163323 ] Tim Mason commented on JENKINS-13952: - Jenkins version is 1.466. I got same error with coverity plugins 1.1.3 and 1.1.4 > Coverity plugin cannot connect to CIM instance > -- > > Key: JENKINS-13952 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13952 > Project: Jenkins > Issue Type: Bug > Components: coverity >Reporter: Tim Mason > > Hi, > I installed the coverity plugin. > On the Jenkins Configure System, after I enter the details for the Coverity > CIM instance and click the Check button, I get "unexpected error occurred". > Clicking Show Details gives the following: > java.lang.NoClassDefFoundError: Could not initialize class > com.sun.xml.wss.impl.SecurableSoapMessage > at > com.sun.xml.wss.ProcessingContext.setSOAPMessage(ProcessingContext.java:223) > at > com.sun.xml.wss.impl.misc.XWSSProcessor2_0Impl.createProcessingContext(XWSSProcessor2_0Impl.java:153) > at > jenkins.plugins.coverity.ClientAuthenticationHandlerWSS.handleMessage(ClientAuthenticationHandlerWSS.java:97) > at > jenkins.plugins.coverity.ClientAuthenticationHandlerWSS.handleMessage(ClientAuthenticationHandlerWSS.java:40) > at > com.sun.xml.internal.ws.handler.HandlerProcessor.callHandleMessage(Unknown > Source) > at > com.sun.xml.internal.ws.handler.HandlerProcessor.callHandlersRequest(Unknown > Source) > etc > Any idea how I can fix this? > Thanks -- 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-13952) Coverity plugin cannot connect to CIM instance
Tim Mason created JENKINS-13952: --- Summary: Coverity plugin cannot connect to CIM instance Key: JENKINS-13952 URL: https://issues.jenkins-ci.org/browse/JENKINS-13952 Project: Jenkins Issue Type: Bug Components: coverity Reporter: Tim Mason Hi, I installed the coverity plugin. On the Jenkins Configure System, after I enter the details for the Coverity CIM instance and click the Check button, I get "unexpected error occurred". Clicking Show Details gives the following: java.lang.NoClassDefFoundError: Could not initialize class com.sun.xml.wss.impl.SecurableSoapMessage at com.sun.xml.wss.ProcessingContext.setSOAPMessage(ProcessingContext.java:223) at com.sun.xml.wss.impl.misc.XWSSProcessor2_0Impl.createProcessingContext(XWSSProcessor2_0Impl.java:153) at jenkins.plugins.coverity.ClientAuthenticationHandlerWSS.handleMessage(ClientAuthenticationHandlerWSS.java:97) at jenkins.plugins.coverity.ClientAuthenticationHandlerWSS.handleMessage(ClientAuthenticationHandlerWSS.java:40) at com.sun.xml.internal.ws.handler.HandlerProcessor.callHandleMessage(Unknown Source) at com.sun.xml.internal.ws.handler.HandlerProcessor.callHandlersRequest(Unknown Source) etc Any idea how I can fix this? Thanks -- 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-13951) Custom workspace not resolved correctly after installing EnvInject
Corey O'Brien created JENKINS-13951: --- Summary: Custom workspace not resolved correctly after installing EnvInject Key: JENKINS-13951 URL: https://issues.jenkins-ci.org/browse/JENKINS-13951 Project: Jenkins Issue Type: Bug Components: envinject Affects Versions: current Environment: windows Reporter: Corey O'Brien Assignee: Gregory Boissinot Attachments: config.xml, slaveconfig.xml After installing EnvInject, existing jobs that have no EnvInject settings enabled are broken if they use a custom workspace. When running a job with a custom workspace on a slave, the custom workspace is ignored and %WORKSPACE% is set to the slave's root instead. Job configuration and the snippet from the jenkins config for the slave are attached. This is running with Jenkins 1.461 and EnvInject 1.54 Here's the console output from the attached job: {noformat} [EnvInject] - Loading node environment variables. Building remotely on Master-Admin in workspace C:\envinjcustomws [envinjcustomws] $ cmd /c call C:\Users\jenkins\AppData\Local\Temp\hudson867880511665494930.bat C:\envinjcustomws>echo C:\Jenkins_AdminNode C:\Jenkins_AdminNode C:\envinjcustomws>exit 0 Finished: SUCCESS {noformat} This may or may not be related to JENKINS-12027 which was resolved as fixed in 1.2 without confirmation. -- 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-13950) Control what components are included in game scoring
[ https://issues.jenkins-ci.org/browse/JENKINS-13950?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] kutzi reassigned JENKINS-13950: --- Assignee: (was: kutzi) > Control what components are included in game scoring > > > Key: JENKINS-13950 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13950 > Project: Jenkins > Issue Type: New Feature > Components: ci-game >Reporter: Jamie Kahgee > Labels: plugin > > Would like to be able to control which components are included in the scoring > on a "per project" basis. i.e. (if I don't want to include checkstyle > scoring, PMD, Tasks, etc...) > Right now we're stuck including everything irregardless if thats how we'd > like to play. -- 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-13950) Control what components are included in game scoring
Jamie Kahgee created JENKINS-13950: -- Summary: Control what components are included in game scoring Key: JENKINS-13950 URL: https://issues.jenkins-ci.org/browse/JENKINS-13950 Project: Jenkins Issue Type: New Feature Components: ci-game Reporter: Jamie Kahgee Assignee: kutzi Would like to be able to control which components are included in the scoring on a "per project" basis. i.e. (if I don't want to include checkstyle scoring, PMD, Tasks, etc...) Right now we're stuck including everything irregardless if thats how we'd like to play. -- 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-13842) Mercurial poll triggers build due to unrelated changes
[ https://issues.jenkins-ci.org/browse/JENKINS-13842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163322#comment-163322 ] Thomas Lotze commented on JENKINS-13842: What would a test case for this look like? A repository with a description of which revisions to push to another repository visible to a Jenkins instance at what point? Some Jenkins configuration? I'm not sure that would end up more concise than the short description I gave already, but I can try when I know what you'd like to see. OTOH, I don't understand that comment about the mercurial version. Which versions of mercurial are you committed to support? Revsets have been part of mercurial since version 1.5 or 1.6 - do you need to support versions as old as that by new Jenkins releases? > Mercurial poll triggers build due to unrelated changes > -- > > Key: JENKINS-13842 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13842 > Project: Jenkins > Issue Type: Bug > Components: mercurial >Affects Versions: current >Reporter: Thomas Lotze >Assignee: Kohsuke Kawaguchi > > The current Mercurial poll command is formulated such that it may falsely > detect new changes if there have ever been any branches with the same name as > that relevant to the build, but which are not ancestors of the current > working-directory revision in terms of the revision DAG. > If the repository happens to contain another branch with the same name, > Jenkins will continuously build the project and the only way to stop it is to > push a dummy merge of that other branch into the line of development Jenkins > is supposed to build. > A better way to ask for new descendants of the current working-directory > revision would be this: > hg log --branch $branch --rev "descendants(children($revision))" > The children predicate is needed because descendants always include the named > revision itself. -- 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-12307) Stack Trace when going to main configuration page
[ https://issues.jenkins-ci.org/browse/JENKINS-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner resolved JENKINS-12307. --- Resolution: Fixed > Stack Trace when going to main configuration page > - > > Key: JENKINS-12307 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12307 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: mwebber >Assignee: Ulli Hafner >Priority: Minor > > When I go (in the web interface) to the main Jenkins configuration page, a > stack trace is generated on the Jenkins console. No adverse results appear on > the web page itself. From the stack track, it looks like it is connected to > the warnings plugin. > This is Jenkins 1.446 and Warnings plugin 3.26 (the latest available at the > time of reporting). I have been noticing this stack track for some time now, > including under earlier releases (I'm not sure how recently it started). > The stack trace: > {noformat} > 05-Jan-2012 11:35:26 hudson.ExpressionFactory2$JexlExpression evaluate > WARNING: Caught exception evaluating: > descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie. Reason: > java.lang.reflect.InvocationTargetException > java.lang.reflect.InvocationTargetException > 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.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) > at > org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) > at > org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) > at > org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) > at > org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) > at > org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) > at > org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) > at > org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) > at > hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) > at > org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) > at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) > at > org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at > org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) > at > org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) > at > org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) > at > org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > at > org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at > org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at > org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) > at > org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) > at > org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) > at > org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > (snip) > at > winstone.RequestHandlerThread.processRequest(RequestHandlerThread.java:244) > at winstone.RequestHandlerThread.run(RequestHandlerThread.java:150) > at java.lang.Thread.run(Thread.java:662) > Caused by: java.lang.
[JIRA] (JENKINS-12307) Stack Trace when going to main configuration page
[ https://issues.jenkins-ci.org/browse/JENKINS-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163321#comment-163321 ] SCM/JIRA link daemon commented on JENKINS-12307: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/warnings/ConsoleParser.java src/main/java/hudson/plugins/warnings/ParserConfiguration.java src/main/java/hudson/plugins/warnings/parser/ParserRegistry.java http://jenkins-ci.org/commit/warnings-plugin/f9ca3bb34e792769544a4599c8e52cd3b9f0b375 Log: [Fixed JENKINS-12307] Refactoring. Compare: https://github.com/jenkinsci/warnings-plugin/compare/2b8c857...f9ca3bb > Stack Trace when going to main configuration page > - > > Key: JENKINS-12307 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12307 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: mwebber >Assignee: Ulli Hafner >Priority: Minor > > When I go (in the web interface) to the main Jenkins configuration page, a > stack trace is generated on the Jenkins console. No adverse results appear on > the web page itself. From the stack track, it looks like it is connected to > the warnings plugin. > This is Jenkins 1.446 and Warnings plugin 3.26 (the latest available at the > time of reporting). I have been noticing this stack track for some time now, > including under earlier releases (I'm not sure how recently it started). > The stack trace: > {noformat} > 05-Jan-2012 11:35:26 hudson.ExpressionFactory2$JexlExpression evaluate > WARNING: Caught exception evaluating: > descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie. Reason: > java.lang.reflect.InvocationTargetException > java.lang.reflect.InvocationTargetException > 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.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) > at > org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) > at > org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) > at > org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) > at > org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) > at > org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) > at > org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) > at > org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) > at > hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) > at > org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) > at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) > at > org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at > org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) > at > org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) > at > org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) > at > org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > at > org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at > org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at > org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) > at > org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) > at > or
[JIRA] (JENKINS-12307) Stack Trace when going to main configuration page
[ https://issues.jenkins-ci.org/browse/JENKINS-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163320#comment-163320 ] SCM/JIRA link daemon commented on JENKINS-12307: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/warnings/ConsoleParser.java src/main/java/hudson/plugins/warnings/ParserConfiguration.java src/main/java/hudson/plugins/warnings/WarningsDescriptor.java src/main/java/hudson/plugins/warnings/WarningsPublisher.java src/main/java/hudson/plugins/warnings/parser/ParserRegistry.java src/main/resources/hudson/plugins/warnings/ConsoleParser/config.jelly src/main/resources/hudson/plugins/warnings/ConsoleParser/config.properties src/main/resources/hudson/plugins/warnings/ConsoleParser/config_de.properties src/main/resources/hudson/plugins/warnings/ConsoleParser/config_ja.properties src/main/resources/hudson/plugins/warnings/ParserConfiguration/config.jelly src/main/resources/hudson/plugins/warnings/ParserConfiguration/config.properties src/main/resources/hudson/plugins/warnings/ParserConfiguration/config_de.properties src/main/resources/hudson/plugins/warnings/ParserConfiguration/config_ja.properties src/main/resources/hudson/plugins/warnings/WarningsPublisher/config.jelly src/main/resources/hudson/plugins/warnings/WarningsPublisher/config.properties src/main/resources/hudson/plugins/warnings/WarningsPublisher/config_de.properties src/main/resources/hudson/plugins/warnings/WarningsPublisher/config_ja.properties src/test/java/hudson/plugins/warnings/ConsoleParserTest.java src/test/java/hudson/plugins/warnings/ParserConfigurationTest.java src/test/java/hudson/plugins/warnings/parser/ParserRegistryIntegrationTest.java http://jenkins-ci.org/commit/warnings-plugin/ef880b867f7378b6c6242eb2d7cbe6bd551c0b23 Log: [JENKINS-12307] Added describables for all parser and pattern selection. > Stack Trace when going to main configuration page > - > > Key: JENKINS-12307 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12307 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: mwebber >Assignee: Ulli Hafner >Priority: Minor > > When I go (in the web interface) to the main Jenkins configuration page, a > stack trace is generated on the Jenkins console. No adverse results appear on > the web page itself. From the stack track, it looks like it is connected to > the warnings plugin. > This is Jenkins 1.446 and Warnings plugin 3.26 (the latest available at the > time of reporting). I have been noticing this stack track for some time now, > including under earlier releases (I'm not sure how recently it started). > The stack trace: > {noformat} > 05-Jan-2012 11:35:26 hudson.ExpressionFactory2$JexlExpression evaluate > WARNING: Caught exception evaluating: > descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie. Reason: > java.lang.reflect.InvocationTargetException > java.lang.reflect.InvocationTargetException > 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.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) > at > org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) > at > org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) > at > org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) > at > org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) > at > org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) > at > org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) > at > org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) > at > hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) > at > org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) > at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) > at
[JIRA] (JENKINS-12307) Stack Trace when going to main configuration page
[ https://issues.jenkins-ci.org/browse/JENKINS-12307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163319#comment-163319 ] SCM/JIRA link daemon commented on JENKINS-12307: Code changed in jenkins User: Ulli Hafner Path: clean.sh src/clean.sh src/main/java/hudson/plugins/warnings/GroovyParser.java src/main/java/hudson/plugins/warnings/ParserConfiguration.java src/main/java/hudson/plugins/warnings/WarningsDescriptor.java src/main/java/hudson/plugins/warnings/parser/ParserRegistry.java src/main/resources/hudson/plugins/warnings/GroovyParser/config.jelly src/main/resources/hudson/plugins/warnings/GroovyParser/config.properties src/main/resources/hudson/plugins/warnings/GroovyParser/config_de.properties src/main/resources/hudson/plugins/warnings/GroovyParser/config_ja.properties src/main/resources/hudson/plugins/warnings/GroovyParser/help-regexp.html src/main/resources/hudson/plugins/warnings/GroovyParser/help-regexp_de.html src/main/resources/hudson/plugins/warnings/GroovyParser/help-script.html src/main/resources/hudson/plugins/warnings/GroovyParser/help-script_de.html src/main/resources/hudson/plugins/warnings/GroovyParser/help-script_ja.html src/main/resources/hudson/plugins/warnings/WarningsPublisher/global.jelly src/main/resources/hudson/plugins/warnings/WarningsPublisher/global.properties src/main/resources/hudson/plugins/warnings/WarningsPublisher/global_de.properties src/main/resources/hudson/plugins/warnings/WarningsPublisher/global_ja.properties src/main/webapp/help-regexp.html src/main/webapp/help-regexp_de.html src/main/webapp/help-script.html src/main/webapp/help-script_de.html src/main/webapp/help-script_ja.html src/test/java/hudson/plugins/warnings/GroovyParserTest.java src/test/java/hudson/plugins/warnings/WarningsDescriptorTest.java src/test/java/hudson/plugins/warnings/parser/ParserRegistryTest.java http://jenkins-ci.org/commit/warnings-plugin/0c94865c65c606786678c3fb77b0a7aae1ae9265 Log: [JENKINS-12307] Make GroovyParser a describable object. > Stack Trace when going to main configuration page > - > > Key: JENKINS-12307 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12307 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: mwebber >Assignee: Ulli Hafner >Priority: Minor > > When I go (in the web interface) to the main Jenkins configuration page, a > stack trace is generated on the Jenkins console. No adverse results appear on > the web page itself. From the stack track, it looks like it is connected to > the warnings plugin. > This is Jenkins 1.446 and Warnings plugin 3.26 (the latest available at the > time of reporting). I have been noticing this stack track for some time now, > including under earlier releases (I'm not sure how recently it started). > The stack trace: > {noformat} > 05-Jan-2012 11:35:26 hudson.ExpressionFactory2$JexlExpression evaluate > WARNING: Caught exception evaluating: > descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie. Reason: > java.lang.reflect.InvocationTargetException > java.lang.reflect.InvocationTargetException > 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.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) > at > org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) > at > org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) > at > org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) > at > org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) > at > org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) > at > org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) > at > org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) > at > hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) > at > org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) > at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) > at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) > at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) > at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) > at org.apa
[JIRA] (JENKINS-13934) Make it possible to delete all except latest 'n' archived artifacts
[ https://issues.jenkins-ci.org/browse/JENKINS-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Croome reassigned JENKINS-13934: - Assignee: OHTAKE Tomohiro > Make it possible to delete all except latest 'n' archived artifacts > --- > > Key: JENKINS-13934 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13934 > Project: Jenkins > Issue Type: Improvement > Components: postbuild-task >Affects Versions: current > Environment: Sun/Solaris 9 ; Java 1.6.0_10; Jenkins ver. 1.466 >Reporter: Paul Croome >Assignee: OHTAKE Tomohiro >Priority: Minor > > In the job configuration page, under Post-build Actions > Archive the > Artifacts > Advanced > it's possible to select the checkbox "Discard all but the last > successful/stable artifact to save disk space". > It would be useful if I could choose "Discard all but the last 'n' > successful/stable artifacts to save disk space". > (By comparison: The option "Discard Old Builds" allows me to specify "Max # > of builds to keep". A similar feature for archived artifacts would be nice.) -- 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-13934) Make it possible to delete all except latest 'n' archived artifacts
[ https://issues.jenkins-ci.org/browse/JENKINS-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163318#comment-163318 ] Paul Croome commented on JENKINS-13934: --- Thanks for the tip. I think it would be nice if I could specify independently (1) the number of builds to keep and (2) the number of artifacts to keep. > Make it possible to delete all except latest 'n' archived artifacts > --- > > Key: JENKINS-13934 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13934 > Project: Jenkins > Issue Type: Improvement > Components: postbuild-task >Affects Versions: current > Environment: Sun/Solaris 9 ; Java 1.6.0_10; Jenkins ver. 1.466 >Reporter: Paul Croome >Priority: Minor > > In the job configuration page, under Post-build Actions > Archive the > Artifacts > Advanced > it's possible to select the checkbox "Discard all but the last > successful/stable artifact to save disk space". > It would be useful if I could choose "Discard all but the last 'n' > successful/stable artifacts to save disk space". > (By comparison: The option "Discard Old Builds" allows me to specify "Max # > of builds to keep". A similar feature for archived artifacts would be nice.) -- 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-12645) Violations plugin reports its own failures as build failures
[ https://issues.jenkins-ci.org/browse/JENKINS-12645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163317#comment-163317 ] acdha commented on JENKINS-12645: - A common trigger for this is that the acceptable values for the directory name are completely undocumented and not relative to the workspace. Using something like {{{**/coverage}}} will work but simply {{{coverage}}} will not. > Violations plugin reports its own failures as build failures > > > Key: JENKINS-12645 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12645 > Project: Jenkins > Issue Type: Bug > Components: violations >Reporter: acdha >Assignee: peterkittreilly > > Violations will cause a build to be marked as failed due to build > configuration problems - for example if the coverage.py HTML path is empty or > incorrect, the build will inaccurately be reported as failing and spam > innocent committers. It should be marked as aborted or some other state > indicating that the tests actually passed but there was something wrong > within the Jenkins environment. > {code} > ERROR: failed to find coverage HTML reports > Build step 'Publish coverage.py HTML reports' changed build result to FAILURE > {code} -- 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-13110) Automatic tool installer: Install from mongodb.org option doesn't include a label field
[ https://issues.jenkins-ci.org/browse/JENKINS-13110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Reilly updated JENKINS-13110: -- Component/s: mongodb > Automatic tool installer: Install from mongodb.org option doesn't include a > label field > --- > > Key: JENKINS-13110 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13110 > Project: Jenkins > Issue Type: Bug > Components: mongodb, plugin > Environment: Jenkins version 1.455 >Reporter: Sean Reilly >Priority: Minor > > I first noticed this with the MongoDB plugin (v 1.1), but then realised that > this occurs with all automatic tool installers that I can find. > When choosing an automatic tool installer of type "Extract \*.zip/\*.tar.gz", > or "Run Command", the UI provides a "label" field, which can be used to > configure which kinds of nodes use a specific installer. When I have slaves > on many platforms, this allows me to install (for example) the > mongodb-linux-x86_64 build on a linux slave, and a mongo osx build on an osx > slave. > The "Install from mongodb.org" option doesn't include a label field, even > though I can configure multiple installers for different platforms. The first > installer is always used no matter what. > Update: while writing this bug report, I realised that this behaviour seems > to be present for all "Install from " options, across many plugins. > This behaviour is fine for a platform independent tool like ant, but doesn't > work well for native code (such as mongodb). > *Workaround* > Create "Extract \*.zip/\*.tar.gz" installers with appropriate labels and > download locations such as > "http://downloads.mongodb.org/linux/mongodb-linux-x86_64-2.0.3.tgz"; to > accomplish the same thing. Note that this won't work for more complicated > automated tool installers like the one that installs java from java.sun.com. -- 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-13949) Broken image in job summary with github and git plugins
[ https://issues.jenkins-ci.org/browse/JENKINS-13949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Reilly updated JENKINS-13949: -- Summary: Broken image in job summary with github and git plugins (was: Broken image in job summary with github plugin) Given that the broken icon is the git icon, I suspect that the issue is related to either the git plugin or the github plugin, although I don't know for sure. Plugin versions: Git: 1.1.18 Github: 1.2 > Broken image in job summary with github and git plugins > --- > > Key: JENKINS-13949 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13949 > Project: Jenkins > Issue Type: Bug > Components: git, github >Reporter: Sean Reilly >Assignee: Nicolas De Loof > > When looking at a specific job for a jenkins build (such as > http://host:8080/job/TheJob/42/) that was caused by a github commit, the git > icon next to the revision is broken. The url for the icon is listed as > /static/a7eba5fd/static/a7eba5fd/plugin/git/icons/git-48x48.png — I suspect > it should be /static/a7eba5fd/plugin/git/icons/git-48x48.png. -- 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-13949) Broken image in job summary with github plugin
Sean Reilly created JENKINS-13949: - Summary: Broken image in job summary with github plugin Key: JENKINS-13949 URL: https://issues.jenkins-ci.org/browse/JENKINS-13949 Project: Jenkins Issue Type: Bug Components: git, github Reporter: Sean Reilly Assignee: Nicolas De Loof When looking at a specific job for a jenkins build (such as http://host:8080/job/TheJob/42/) that was caused by a github commit, the git icon next to the revision is broken. The url for the icon is listed as /static/a7eba5fd/static/a7eba5fd/plugin/git/icons/git-48x48.png — I suspect it should be /static/a7eba5fd/plugin/git/icons/git-48x48.png. -- 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-13917) Artifactory plugin libraries affecting the path used during an Ant build
[ https://issues.jenkins-ci.org/browse/JENKINS-13917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Camden Holt resolved JENKINS-13917. --- Resolution: Not A Defect > Artifactory plugin libraries affecting the path used during an Ant build > > > Key: JENKINS-13917 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13917 > Project: Jenkins > Issue Type: Bug > Components: artifactory >Affects Versions: current > Environment: Linux (CentOS 6) >Reporter: Camden Holt >Assignee: yossis > > We have a job using an Ant script to perform the build. One of the targets > in this script generates instrumented classes to enable us to generate a > Cobertura coverage report. > As part of our set of standard libraries, we include various jars from the > slf4j suite. When we enable the Artifactory plugin for this job, the > Cobertura Ant target fails, because of an incompatible set of jars being > used. The snippet of output below is generated with verbose logging from the > VM: > 12:19:40 cobertura-instrumented-src-classes: > 12:19:40 [Loaded net.sourceforge.cobertura.ant.CommonMatchingTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.InstrumentTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.MergeTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.CheckTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.ReportTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.Ignore from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.IgnoreBranches from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.IncludeClasses from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.ExcludeClasses from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded org.apache.tools.ant.taskdefs.ImportTask from > file:/opt/apache-ant-1.8.1/lib/ant.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.util.CommandLineBuilder from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded org.apache.log4j.Category from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/log4j-over-slf4j-1.6.4.jar] > 12:19:40 [Loaded org.apache.log4j.Logger from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/log4j-over-slf4j-1.6.4.jar] > * 12:19:40 [Loaded org.slf4j.MarkerFactory from > file:/opt/jenkins/plugins/artifactory/WEB-INF/lib/slf4j-api-1.5.8.jar] > 12:19:40 [Loaded org.apache.tools.ant.util.DateUtils from > file:/opt/apache-ant-1.8.1/lib/ant.jar] > The line prefixed with * shows the problem; the slf4j-api-1.5.8.jar is being > loaded from the artifactory plugin directory. This is an older version than > that supplied with our project which is 1.6.4 - and this is causing a problem > when the compilation step occurs. > When we run this from the command line using ant directly we can see that > the correct jar from within our project is loaded. > I'm afraid I don't understand fully how the addition of plugins affects the > build environment technically, but I assume that the Artifactory plugin has > been able to modify the environment/build path somehow to ensure that it's > available at the appropriate time. Unfortunately this seems to cause problems > if newer libraries are needed elsewhere. > We can work around this by using the Ant/Ivy/Artifactory integration from the > build script directly, but it would be good to be able to do this from > Jenkins and simplify our scripts. -- 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-13917) Artifactory plugin libraries affecting the path used during an Ant build
[ https://issues.jenkins-ci.org/browse/JENKINS-13917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163315#comment-163315 ] Camden Holt commented on JENKINS-13917: --- That's strange. We are using 2.0.9 on Jenkins 1.462. I checked the path I mentioned and you are of course quite right, the jar isn't there. I should have checked that before raising the ticket. I don't actually see that jar anywhere under /opt/jenkins which is somewhat confusing. I just tried to reproduce it and it doesn't happen any more (possibly we've upgraded since we had the original problem - I am not sure). I'll close this, I don't really understand what caused it. Apologies for wasting your time! > Artifactory plugin libraries affecting the path used during an Ant build > > > Key: JENKINS-13917 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13917 > Project: Jenkins > Issue Type: Bug > Components: artifactory >Affects Versions: current > Environment: Linux (CentOS 6) >Reporter: Camden Holt >Assignee: yossis > > We have a job using an Ant script to perform the build. One of the targets > in this script generates instrumented classes to enable us to generate a > Cobertura coverage report. > As part of our set of standard libraries, we include various jars from the > slf4j suite. When we enable the Artifactory plugin for this job, the > Cobertura Ant target fails, because of an incompatible set of jars being > used. The snippet of output below is generated with verbose logging from the > VM: > 12:19:40 cobertura-instrumented-src-classes: > 12:19:40 [Loaded net.sourceforge.cobertura.ant.CommonMatchingTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.InstrumentTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.MergeTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.CheckTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.ReportTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.Ignore from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.IgnoreBranches from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.IncludeClasses from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.ExcludeClasses from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded org.apache.tools.ant.taskdefs.ImportTask from > file:/opt/apache-ant-1.8.1/lib/ant.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.util.CommandLineBuilder from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded org.apache.log4j.Category from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/log4j-over-slf4j-1.6.4.jar] > 12:19:40 [Loaded org.apache.log4j.Logger from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/log4j-over-slf4j-1.6.4.jar] > * 12:19:40 [Loaded org.slf4j.MarkerFactory from > file:/opt/jenkins/plugins/artifactory/WEB-INF/lib/slf4j-api-1.5.8.jar] > 12:19:40 [Loaded org.apache.tools.ant.util.DateUtils from > file:/opt/apache-ant-1.8.1/lib/ant.jar] > The line prefixed with * shows the problem; the slf4j-api-1.5.8.jar is being > loaded from the artifactory plugin directory. This is an older version than > that supplied with our project which is 1.6.4 - and this is causing a problem > when the compilation step occurs. > When we run this from the command line using ant directly we can see that > the correct jar from within our project is loaded. > I'm afraid I don't understand fully how the addition of plugins affects the > build environment technically, but I assume that the Artifactory plugin has > been able to modify the environment/build path somehow to ensure that it's > available at the appropriate time. Unfortunately this seems to cause problems > if newer libraries are needed elsewhere. > We can work around this by using the Ant/Ivy/Artifactory integration from the > build script directly, but it would be good to be able to do this from > Jenkins and simplify our scripts. -- This message is automatically generated by JIRA. If you think
[JIRA] (JENKINS-13948) VirtualBox Integration Problem
Nicolas JAN created JENKINS-13948: - Summary: VirtualBox Integration Problem Key: JENKINS-13948 URL: https://issues.jenkins-ci.org/browse/JENKINS-13948 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Ubuntu Desktop 12.04 64 bits with Jenkins 1.466 hosted on tomcat7 (ubuntu package) Reporter: Nicolas JAN Attachments: test Config [Jenkins].png Hi, I have a job which permits me to restore and start a vm (VirtualBox). This job calls this shell command : vboxmanage startvm "UbuntuDev" --type headless This command functions correctly in a shell console. When I launch a build, this build is on Success and all output messages are good : [workspace] $ /bin/sh -xe /tmp/tomcat7-tomcat7-tmp/hudson286650196961541593.sh + vboxmanage startvm UbuntuDev --type headless Waiting for VM "UbuntuDev" to power on... VM "UbuntuDev" has been successfully started. But when I ping the VM, the VM doesn't respond. So, I add 2 shell commands (one before and another one after) to get VM state : vboxmanage showvminfo "UbuntuDev" When I launch the build, The last shell command indicate the VM is running : [workspace] $ /bin/sh -xe /tmp/tomcat7-tomcat7-tmp/hudson3800152253048004421.sh + vboxmanage showvminfo UbuntuDev Name:UbuntuDev Guest OS:Ubuntu UUID:ebb824d8-d6aa-42d3-8cf1-eafb9d50d46a Config file: /home/all/VirtualBox/VMs/UbuntuDev/UbuntuDev.vbox Snapshot folder: /home/all/VirtualBox/VMs/UbuntuDev/Snapshots Log folder: /home/all/VirtualBox/VMs/UbuntuDev/Logs Hardware UUID: ebb824d8-d6aa-42d3-8cf1-eafb9d50d46a Memory size: 512MB Page Fusion: off VRAM size: 12MB CPU exec cap:100% HPET:off Chipset: piix3 Firmware:BIOS Number of CPUs: 1 Synthetic Cpu: off CPUID overrides: None Boot menu mode: message and menu Boot Device (1): Floppy Boot Device (2): DVD Boot Device (3): HardDisk Boot Device (4): Not Assigned ACPI:on IOAPIC: off PAE: on Time offset: 0 ms RTC: UTC Hardw. virt.ext: on Hardw. virt.ext exclusive: on Nested Paging: on Large Pages: off VT-x VPID: on State: aborted (since 2012-05-30T07:45:43.0) Monitor count: 1 3D Acceleration: off 2D Video Acceleration: off Teleporter Enabled: off Teleporter Port: 0 Teleporter Address: Teleporter Password: Storage Controller Name (0):Contrôleur IDE Storage Controller Type (0):PIIX4 Storage Controller Instance Number (0): 0 Storage Controller Max Port Count (0): 2 Storage Controller Port Count (0): 2 Storage Controller Bootable (0):on Storage Controller Name (1):Contrôleur SATA Storage Controller Type (1):IntelAhci Storage Controller Instance Number (1): 0 Storage Controller Max Port Count (1): 30 Storage Controller Port Count (1): 1 Storage Controller Bootable (1):on Contrôleur IDE (1, 0): Empty Contrôleur SATA (0, 0): /home/all/VirtualBox/VMs/UbuntuDev/UbuntuDev.vdi (UUID: 232df65c-d64e-45cd-b0ba-aa4f79bc3e85) NIC 1: MAC: 0800274EA33B, Attachment: Bridged Interface 'eth0', Cable connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0, Promisc Policy: deny NIC 2: disabled NIC 3: disabled NIC 4: disabled NIC 5: disabled NIC 6: disabled NIC 7: disabled NIC 8: disabled Pointing Device: USB Tablet Keyboard Device: PS/2 Keyboard UART 1: disabled UART 2: disabled Audio: enabled (Driver: Null, Controller: AC97) Clipboard Mode: Bidirectional VRDE:disabled USB: enabled USB Device Filters: Available remote USB devices: Currently Attached USB Devices: Shared folders: VRDE Connection:not active Clients so far: 0 Guest: Configured memory balloon size: 0 MB OS type: Ubuntu Additions run level: 0 Guest Facilities: No active facilities. [workspace] $ /bin/sh -xe /tmp/tomcat7-tomcat7-tmp/hudson286650196961541593.sh + vboxmanage startvm UbuntuDev --type headless Waiting for VM "UbuntuDev" to power on... VM "UbuntuDev" has been successfully started. [workspace] $ /bin/sh -xe /tmp/tomcat7-tomcat7-tmp/hudson2015171658235852148.sh + vboxmanage showvminfo UbuntuDev Name:UbuntuDev Guest OS:Ubuntu UUID:ebb824d8-d6aa-42d3-8cf1-eafb9d50d46a Config file: /home/all/VirtualBox/VMs/UbuntuDev/UbuntuDev.vbox Snapshot folder: /home/all/VirtualBox/VMs/UbuntuDev/Snapshots Log folder: /home/all/VirtualBox/VMs/UbuntuDev/Logs Hardware UUID: ebb824d8-d6aa-42d3-8cf1-eafb9d50d46a Memory size: 512MB Page Fusion: off VRAM size: 12MB CPU exec cap:100% HPET:off Chipset:
[JIRA] (JENKINS-13947) NPE on Jenkins start
[ https://issues.jenkins-ci.org/browse/JENKINS-13947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] cforce updated JENKINS-13947: - Description: I'm getting a NPE when i try to use the view-job-filters plugin with a recent Jenkins install (did try with 1463,1464): /.jenkins/war/WEB-INF/lib/jenkins-core-1.464.jar!/lib/hudson/projectView.jelly:60:22: java.lang.NullPointerException at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:716) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.kohsuke.stapler.jelly.CompressTag.doTag(CompressTag.java:44) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53) at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107) ... 53 more Caused by: java.lang.RuntimeException: org.apache.commons.jelly.JellyTagException: jar:file://.jenkins/war/WEB-INF/lib/jenkins-core-1.464.jar!/lib/hudson/projectView.jelly:60:22: java.lang.NullPointerException at org.kohsuke.stapler.jelly.groovy.JellyBuilder.doInvokeMethod(JellyBuilder.java:287) at org.kohsuke.stapler.jelly.groovy.Namespace$ProxyImpl.invoke(Namespace.java:92) at $Proxy25.projectView(Unknown Source) at lib.JenkinsTagLib$projectView.call(Unknown Source) at hudson.model.View.main.run(main.groovy:14) at org.kohsuke.stapler.jelly.groovy.GroovierJellyScript.run(GroovierJellyScript.java:66) at org.kohsuke.stapler.jelly.groovy.GroovierJellyScript.run(GroovierJellyScript.java:59) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:146) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) ... 84 more Caused by: org.apache.commons.jelly.JellyTagException: jar:file://.jenkins/war/WEB-INF/lib/jenkins-core-1.464.jar!/lib/hudson/projectView.jelly:60:22: java.lang.NullPointerException at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:716) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.Script
[JIRA] (JENKINS-13947) NPE on Jenkins start
cforce created JENKINS-13947: Summary: NPE on Jenkins start Key: JENKINS-13947 URL: https://issues.jenkins-ci.org/browse/JENKINS-13947 Project: Jenkins Issue Type: Bug Components: view-job-filters Reporter: cforce Assignee: Jacob Robertson Priority: Blocker I'm getting a NPE when i try to use the view-job-filters plugin with a recent Jenkins install (did try with 1463,1464): /.jenkins/war/WEB-INF/lib/jenkins-core-1.464.jar!/lib/hudson/projectView.jelly:60:22: java.lang.NullPointerException at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:716) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.kohsuke.stapler.jelly.CompressTag.doTag(CompressTag.java:44) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53) at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:107) ... 53 more Caused by: java.lang.RuntimeException: org.apache.commons.jelly.JellyTagException: jar:file://.jenkins/war/WEB-INF/lib/jenkins-core-1.464.jar!/lib/hudson/projectView.jelly:60:22: java.lang.NullPointerException at org.kohsuke.stapler.jelly.groovy.JellyBuilder.doInvokeMethod(JellyBuilder.java:287) at org.kohsuke.stapler.jelly.groovy.Namespace$ProxyImpl.invoke(Namespace.java:92) at $Proxy25.projectView(Unknown Source) at lib.JenkinsTagLib$projectView.call(Unknown Source) at hudson.model.View.main.run(main.groovy:14) at org.kohsuke.stapler.jelly.groovy.GroovierJellyScript.run(GroovierJellyScript.java:66) at org.kohsuke.stapler.jelly.groovy.GroovierJellyScript.run(GroovierJellyScript.java:59) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:146) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) ... 84 more Caused by: org.apache.commons.jelly.JellyTagException: jar:file://.jenkins/war/WEB-INF/lib/jenkins-core-1.464.jar!/lib/hudson/projectView.jelly:60:22: java.lang.NullPointerException at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:716) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.c
[JIRA] (JENKINS-13946) git submodule fetch fails due to unpruned branch
Steffen Prohaska created JENKINS-13946: -- Summary: git submodule fetch fails due to unpruned branch Key: JENKINS-13946 URL: https://issues.jenkins-ci.org/browse/JENKINS-13946 Project: Jenkins Issue Type: Bug Components: git Affects Versions: current Reporter: Steffen Prohaska If a branch (e.g. a/b) has replaced by a branch that includes a directory (e.g. a/b/c), fetch fails with the following message: ''' FATAL: Command "/usr/bin/git submodule update --init --recursive" returned status code 1: [...] error: some local refs could not be updated; try running 'git remote prune origin' to remove any old, conflicting branches Unable to fetch in submodule [...] ''' To fix the issue, 'git prune' should include submodules and be run before fetching. -- 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-13937) ArtifactDeployer 0.16 messes the filenames for Windows filesystems
[ https://issues.jenkins-ci.org/browse/JENKINS-13937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163314#comment-163314 ] Roger Myung commented on JENKINS-13937: --- We usually access the deployed artifacts from the job page. from "Last Successful Deployed Artifacts" or from the page of the run "Deployed Artifacts" > ArtifactDeployer 0.16 messes the filenames for Windows filesystems > -- > > Key: JENKINS-13937 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13937 > Project: Jenkins > Issue Type: Bug > Components: artifactdeployer > Environment: artifactdeployer 0.16 > Windows >Reporter: Roger Myung >Assignee: Gregory Boissinot > > We deploy our artifacts to a UNC path > \\\Artifacts\artifact.file > With version 0.16, when a user tries to download this file, the file becomes > _Artifactsartifact.file -- 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-13945) Copy artifacts from master -> slaves takes about 10x longer with openjdk
[ https://issues.jenkins-ci.org/browse/JENKINS-13945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] sanga updated JENKINS-13945: Description: Version: 1.451 We switched from sun java to openjdk and noticed that copying artifacts from master to slave took way longer than it had previously (x10 or more). Switching back to sun java fixed the problem. Related to this, the node ping times, as seen at: https://.../jenkins/computer/ were all up around 0.5s with openjdk and then when switching to sun java dropped back down to where they should be (around 20ms). If this is a bug in openjdk that's not really Jenkins problem, but perhaps there's something in Jenkins to be done. Or at least it'd be beneficial for Jenkins to know about this I guess. was: Version: 1.451 We switched from sun java to openjdk and noticed that copying artifacts from master to slave took way longer than it had previously (x10 or more). Switching back to sun java fixed the problem. > Copy artifacts from master -> slaves takes about 10x longer with openjdk > > > Key: JENKINS-13945 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13945 > Project: Jenkins > Issue Type: Bug > Components: core > Environment: Debian 6 >Reporter: sanga > > Version: 1.451 > We switched from sun java to openjdk and noticed that copying artifacts from > master to slave took way longer than it had previously (x10 or more). > Switching back to sun java fixed the problem. > Related to this, the node ping times, as seen at: > https://.../jenkins/computer/ were all up around 0.5s with openjdk and then > when switching to sun java dropped back down to where they should be (around > 20ms). > If this is a bug in openjdk that's not really Jenkins problem, but perhaps > there's something in Jenkins to be done. Or at least it'd be beneficial for > Jenkins to know about this I guess. -- 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-13945) Copy artifacts from master -> slaves takes about 10x longer with openjdk
sanga created JENKINS-13945: --- Summary: Copy artifacts from master -> slaves takes about 10x longer with openjdk Key: JENKINS-13945 URL: https://issues.jenkins-ci.org/browse/JENKINS-13945 Project: Jenkins Issue Type: Bug Components: core Environment: Debian 6 Reporter: sanga Version: 1.451 We switched from sun java to openjdk and noticed that copying artifacts from master to slave took way longer than it had previously (x10 or more). Switching back to sun java fixed the problem. -- 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-13944) Missing hyperlink type "tag" in Clearcase does not fail the build
Jens Brejner created JENKINS-13944: --- Summary: Missing hyperlink type "tag" in Clearcase does not fail the build Key: JENKINS-13944 URL: https://issues.jenkins-ci.org/browse/JENKINS-13944 Project: Jenkins Issue Type: Bug Components: clearcase-ucm Affects Versions: current Reporter: Jens Brejner Priority: Trivial If the "make tag" option is checked in the clearcase-ucm plugin settings of a job, and the clearcase hyperlink type tag is missing from the PVOB, an explanotory message is shown in the build log: [CCUCM] Could not change tag in ClearCase. Contact ClearCase administrator to do this manually. net.praqma.util.execute.AbnormalProcessTerminationException: cleartool: Error: hyperlink type "tag" not found in VOB "\Cool_PVOB" and no global type definition can be found. cleartool: Error: Unable to create hyperlink "tag". The Hyperlink type "tag" was not found. Installation: "cleartool mkhltype -global -c "Hyperlink type for tagging entities" tag@\Cool_PVOB Command was: cleartool mkhlink -ttext "tagtype=TestPosted&tagid=734&buildstatus=SUCCESS" tag baseline:Automade.8125@\Cool_PVOB cleartool: Error: hyperlink type "tag" not found in VOB "\Cool_PVOB" and no global type definition can be found. cleartool: Error: Unable to create hyperlink "tag". [CCUCM] Post build steps done Finished: SUCCESS I think that the build should be failed instead, because I do not get the results I "ordered" in the job configuration. Or as a minimum, the build should become Unstable -- 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-13943) java 7 support to build plugin
Audrius K created JENKINS-13943: --- Summary: java 7 support to build plugin Key: JENKINS-13943 URL: https://issues.jenkins-ci.org/browse/JENKINS-13943 Project: Jenkins Issue Type: Task Components: android-emulator Environment: Arch linux, JDK7 Reporter: Audrius K Priority: Minor Current project can't be build with JDK7. Min jenkins plugin version to support JDK7 is 1.420. More details https://issues.jenkins-ci.org/browse/JENKINS-10490 -- 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-13790) Subversion externals fail
[ https://issues.jenkins-ci.org/browse/JENKINS-13790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163313#comment-163313 ] Alexander Ost commented on JENKINS-13790: - Same here on Linux platform. As a nasty side-effect, also the externals' revision information in /revision.txt is missing. The file only contains the revision of the main repository. > Subversion externals fail > - > > Key: JENKINS-13790 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13790 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current > Environment: Windows XP SP3 >Reporter: chikigai > > Updates on a repository with svn:externals property set fail with the > following: > AssertionError: appears to be using unpatched svnkit at jar:xxx/SVNEvent.class > The issue is present with the latest 1.40 release. > The issue is not preset with the 1.39 release. -- 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-13917) Artifactory plugin libraries affecting the path used during an Ant build
[ https://issues.jenkins-ci.org/browse/JENKINS-13917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163312#comment-163312 ] yossis commented on JENKINS-13917: -- This library is not distributed with Artifactory plugin. Are you using an old version? > Artifactory plugin libraries affecting the path used during an Ant build > > > Key: JENKINS-13917 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13917 > Project: Jenkins > Issue Type: Bug > Components: artifactory >Affects Versions: current > Environment: Linux (CentOS 6) >Reporter: Camden Holt >Assignee: yossis > > We have a job using an Ant script to perform the build. One of the targets > in this script generates instrumented classes to enable us to generate a > Cobertura coverage report. > As part of our set of standard libraries, we include various jars from the > slf4j suite. When we enable the Artifactory plugin for this job, the > Cobertura Ant target fails, because of an incompatible set of jars being > used. The snippet of output below is generated with verbose logging from the > VM: > 12:19:40 cobertura-instrumented-src-classes: > 12:19:40 [Loaded net.sourceforge.cobertura.ant.CommonMatchingTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.InstrumentTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.MergeTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.CheckTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.ReportTask from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.Ignore from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.IgnoreBranches from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.IncludeClasses from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.ant.ExcludeClasses from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded org.apache.tools.ant.taskdefs.ImportTask from > file:/opt/apache-ant-1.8.1/lib/ant.jar] > 12:19:40 [Loaded net.sourceforge.cobertura.util.CommandLineBuilder from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/cobertura-1.9.4.1.jar] > 12:19:40 [Loaded org.apache.log4j.Category from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/log4j-over-slf4j-1.6.4.jar] > 12:19:40 [Loaded org.apache.log4j.Logger from > file:/opt/jenkins/jobs/data-processing/workspace/test-lib/log4j-over-slf4j-1.6.4.jar] > * 12:19:40 [Loaded org.slf4j.MarkerFactory from > file:/opt/jenkins/plugins/artifactory/WEB-INF/lib/slf4j-api-1.5.8.jar] > 12:19:40 [Loaded org.apache.tools.ant.util.DateUtils from > file:/opt/apache-ant-1.8.1/lib/ant.jar] > The line prefixed with * shows the problem; the slf4j-api-1.5.8.jar is being > loaded from the artifactory plugin directory. This is an older version than > that supplied with our project which is 1.6.4 - and this is causing a problem > when the compilation step occurs. > When we run this from the command line using ant directly we can see that > the correct jar from within our project is loaded. > I'm afraid I don't understand fully how the addition of plugins affects the > build environment technically, but I assume that the Artifactory plugin has > been able to modify the environment/build path somehow to ensure that it's > available at the appropriate time. Unfortunately this seems to cause problems > if newer libraries are needed elsewhere. > We can work around this by using the Ant/Ivy/Artifactory integration from the > build script directly, but it would be good to be able to do this from > Jenkins and simplify our scripts. -- 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
REMOVE ME
Martin Schoepf - Software Testing TTTech Computertechnik AG - Ensuring Reliable Networks Commercial Reg. No.: 165 664z, Commercial Court Vienna Schoenbrunner Strasse 7, A-1040 Vienna, Austria Phone: +43 1 585 34 34-46, Fax: +43 1 585 34 34-90 martin.scho...@tttech.com, http://www.tttech.com ___ From: "hits...@gmail.com (JIRA)" To: jenkinsci-issues@googlegroups.com Date: 05.30.2012 09:22 Subject: [JIRA] (JENKINS-13836) Stable release issues|Loading All Build History Fails in stable release 1.447.1 Sent by: jenkinsci-issues@googlegroups.com [ https://issues.jenkins-ci.org/browse/JENKINS-13836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163311#comment-163311 ] hiteswar kumar commented on JENKINS-13836: -- this issue fixed in Jenkins 1.459 (2012/04/09) and will be fixed at Jenkins coming LTS 1.447.2 Reference: http://jenkins-ci.org/changelog Loading All Build History Fails. (issue 13238) https://issues.jenkins-ci.org/browse/JENKINS-13238 > Stable release issues|Loading All Build History Fails in stable release 1.447.1 > --- > > Key: JENKINS-13836 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13836 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Prodution >Reporter: Arvind Ramalingam >Priority: Blocker > > Hi I have upgraded my Production Jenkins to 1.447.1 and I am not able to see my build history.When I try to view more of my build history I get the below error.Please let me know which stable release should i revert back to and I was at 1.409 and everything was fine. > HTTP Status 404 - > type Status report > message > description The requested resource () is not available. > Apache Tomcat/6.0.26 -- 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 CONFIDENTIALITY: The contents of this e-mail are confidential and intended only for the above addressee(s). If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, copying or delivering it to anyone else or using it in any unauthorized manner is prohibited and may be unlawful. If you receive this e-mail by mistake, please notify the sender and the systems administrator at straym...@tttech.com immediately.
[JIRA] (JENKINS-13836) Stable release issues|Loading All Build History Fails in stable release 1.447.1
[ https://issues.jenkins-ci.org/browse/JENKINS-13836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163311#comment-163311 ] hiteswar kumar commented on JENKINS-13836: -- this issue fixed in Jenkins 1.459 (2012/04/09) and will be fixed at Jenkins coming LTS 1.447.2 Reference: http://jenkins-ci.org/changelog Loading All Build History Fails. (issue 13238) https://issues.jenkins-ci.org/browse/JENKINS-13238 > Stable release issues|Loading All Build History Fails in stable release > 1.447.1 > --- > > Key: JENKINS-13836 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13836 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Prodution >Reporter: Arvind Ramalingam >Priority: Blocker > > Hi I have upgraded my Production Jenkins to 1.447.1 and I am not able to see > my build history.When I try to view more of my build history I get the below > error.Please let me know which stable release should i revert back to and I > was at 1.409 and everything was fine. > HTTP Status 404 - > type Status report > message > description The requested resource () is not available. > Apache Tomcat/6.0.26 -- 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-13878) [Max # of builds to keep] can't be configured as global variable
[ https://issues.jenkins-ci.org/browse/JENKINS-13878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163310#comment-163310 ] OHTAKE Tomohiro commented on JENKINS-13878: --- I believe you would like [Configuration Slicing Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Configuration+Slicing+Plugin]. > [Max # of builds to keep] can't be configured as global variable > > > Key: JENKINS-13878 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13878 > Project: Jenkins > Issue Type: Improvement > Components: gui >Affects Versions: current > Environment: Java version: 1.6.0_27, vendor: Sun Microsystems Inc. > Java home: d:\fspldev\java\jdk1.6.0_27-i586 > Default locale: en_US, platform encoding: Cp1252 > OS name: "windows xp", version: "5.1", arch: "x86", family: "windows" > Jenkins ver. 1.465 >Reporter: Neven Radovanovic > > It would be very helpful to configure [Max # of builds to keep] as a [Global > property] that can be applied to several jobs at once for easy maintenance. > -- 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-13934) Make it possible to delete all except latest 'n' archived artifacts
[ https://issues.jenkins-ci.org/browse/JENKINS-13934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163309#comment-163309 ] OHTAKE Tomohiro commented on JENKINS-13934: --- You can find "Max # of builds to keep with artifacts" inside the advanced block of "Discard Old Builds". > Make it possible to delete all except latest 'n' archived artifacts > --- > > Key: JENKINS-13934 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13934 > Project: Jenkins > Issue Type: Improvement > Components: postbuild-task >Affects Versions: current > Environment: Sun/Solaris 9 ; Java 1.6.0_10; Jenkins ver. 1.466 >Reporter: Paul Croome >Priority: Minor > > In the job configuration page, under Post-build Actions > Archive the > Artifacts > Advanced > it's possible to select the checkbox "Discard all but the last > successful/stable artifact to save disk space". > It would be useful if I could choose "Discard all but the last 'n' > successful/stable artifacts to save disk space". > (By comparison: The option "Discard Old Builds" allows me to specify "Max # > of builds to keep". A similar feature for archived artifacts would be nice.) -- 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