[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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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
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) nore...@jenkins-ci.org 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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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
[JIRA] (JENKINS-13790) Subversion externals fail
[ https://issues.jenkins-ci.org/browse/JENKINS-13790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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 build directory/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-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-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=TestPostedtagid=734buildstatus=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-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-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-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-tabpanelfocusedCommentId=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 \\COMPUTERNAME\Artifacts\artifact.file With version 0.16, when a user tries to download this file, the file becomes _COMPUTERNAMEArtifactsartifact.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-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-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: d:invokeBody 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: d:invokeBody 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: d:invokeBody 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
[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: d:invokeBody 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: d:invokeBody 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: d:invokeBody 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
[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: none Available remote USB devices: none Currently Attached USB Devices: none Shared folders: none 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-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-tabpanelfocusedCommentId=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 it was sent incorrectly, please contact your JIRA administrators:
[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-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-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-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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-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-tabpanelfocusedCommentId=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
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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
org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98)
[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.AssertionError: null is missing its descriptor in public
hudson.util.CopyOnWriteList
[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-tabpanelfocusedCommentId=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-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-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-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:\envinjcustomwsecho C:\Jenkins_AdminNode
C:\Jenkins_AdminNode
C:\envinjcustomwsexit 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-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-13952) Coverity plugin cannot connect to CIM instance
[ https://issues.jenkins-ci.org/browse/JENKINS-13952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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:comment-tabpanelfocusedCommentId=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-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-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-8152) LDAP config error
[
https://issues.jenkins-ci.org/browse/JENKINS-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.invoke(Stapler.java:640)
at
[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-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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-6651) Hudson crashes for unknown reasons
[ https://issues.jenkins-ci.org/browse/JENKINS-6651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-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-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-tabpanelfocusedCommentId=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-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-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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-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-tabpanelfocusedCommentId=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-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
?suiteformat=xmlincludehtml
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
[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
?suiteformat=xmlincludehtml
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
[JIRA] (JENKINS-13956) FitNesse : Connection reset
[
https://issues.jenkins-ci.org/browse/JENKINS-13956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
?suiteformat=xmlincludehtml
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)
at
[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-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-13928) bad version number at offiset=6
[ https://issues.jenkins-ci.org/browse/JENKINS-13928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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.init(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-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-tabpanelfocusedCommentId=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.init(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.clinit(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.
[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-tabpanelfocusedCommentId=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-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-13953) can't Deploy artifacts to Artifactory
[ https://issues.jenkins-ci.org/browse/JENKINS-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-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-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-tabpanelfocusedCommentId=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-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-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 is something like this:
