[JIRA] (JENKINS-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159739#comment-159739 ] Jaroslavas D. commented on JENKINS-12810: - Hi, Bruno. Why plugin should seek for _platform_ option in XML? There's no _test plan_ option in generated JUnit/TestNG XMLs, but no problem for plugin to find TC only from defined Test Plan. Thank You, Bruno, for productive communication! And sorry for my silly questions. I'm not really programer guy - I'm tester. So, my point of view to problem may be different :) JUnit test results are getting wrongly attached to all the test cases - Key: JENKINS-12810 URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 Project: Jenkins Issue Type: Bug Components: testlink Affects Versions: current Reporter: Vignesh Senapathy Assignee: Bruno P. Kinoshita Fix For: current Attachments: 1.jpg, 2.jpg, 3.jpg, last_tc.png, schema.jpg, screenshot20120228152415.jpg, screenshot20120228152511.jpg, tc1.png, tc2.png, testlink-3.1-alpha2.hpi Hi, I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the Junit Test results are getting generated. This in turn calls the Testlink xml rpc and attaches the results to the test case, but the test results are attached wrongly. The 1st test case has 6 results, the next has 5 and so on and the last one has 1 test result attached to it. I dont know if it is bug which is causing this. Please let me know what seems to be the problems. Also the execution flags are correctly rendered in this. which ever test case fails is marked as failed and which passed is marked as passed. Also I have one custom field which maps to the test suite name and test classname. -- 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-12250) Critical block can not be added into conditional step
[ https://issues.jenkins-ci.org/browse/JENKINS-12250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159741#comment-159741 ] Oleksandr Popov commented on JENKINS-12250: --- Hello? Any update on this issue? Critical block can not be added into conditional step - Key: JENKINS-12250 URL: https://issues.jenkins-ci.org/browse/JENKINS-12250 Project: Jenkins Issue Type: Bug Components: conditional-buildstep, exclusion Environment: Jenkins 1.445 Jenkins Exclusion Plug-in 0.6 conditional-buildstep 0.2 Reporter: Oleksandr Popov Assignee: Anthony Roux Priority: Critical Attachments: critical-block.PNG I'm not able to add critical block into conditional step. See screen-shot for details -- 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-12667) No possibility to specify Workspace Root Directory for Slave node
[ https://issues.jenkins-ci.org/browse/JENKINS-12667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159740#comment-159740 ] Oleksandr Popov commented on JENKINS-12667: --- Any update? No possibility to specify Workspace Root Directory for Slave node --- Key: JENKINS-12667 URL: https://issues.jenkins-ci.org/browse/JENKINS-12667 Project: Jenkins Issue Type: Bug Components: slave-setup Affects Versions: current Environment: Jenkins 1.450 Reporter: Oleksandr Popov Assignee: Kohsuke Kawaguchi There is no possibility to specify Workspace Root Directory for Slave node as it is for Master node. -- 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-12113) Maven - java.io.IOException: error=2, No such file or directory if in SVN configuration parameters used in Local module directory section
[ https://issues.jenkins-ci.org/browse/JENKINS-12113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleksandr Popov closed JENKINS-12113. - Thanks for you help! Maven - java.io.IOException: error=2, No such file or directory if in SVN configuration parameters used in Local module directory section - Key: JENKINS-12113 URL: https://issues.jenkins-ci.org/browse/JENKINS-12113 Project: Jenkins Issue Type: Bug Components: core, maven, maven2, parameters, subversion Environment: Jenkins 1.448 Subversion Plugin 1.37 Maven Integration Plugin 1.448 Ant 1.1 Reporter: Oleksandr Popov Assignee: kutzi Attachments: subversion.hpi, svn_maven_issue_01.PNG, svn_maven_issue_02.PNG Maven is unable to work if in Subversion configuration parameters are used in Local module directory section. As you can see in svn_maven_issue_01.PNG Ive specified predefined variable in Local module directory section. And when I run it - Maven failed (svn_maven_issue_02.PNG) with java.io.IOException. -- 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-12186) warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does)
[ https://issues.jenkins-ci.org/browse/JENKINS-12186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12186. Resolution: Fixed warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does) - Key: JENKINS-12186 URL: https://issues.jenkins-ci.org/browse/JENKINS-12186 Project: Jenkins Issue Type: Improvement Components: analysis-collector Affects Versions: current Reporter: Greg Moncreaff Assignee: Ulli Hafner E.g. if you aren't looking at Java code, then Findbugs and Checkstyle and PMD don't have any value. When new things are tied into analysis core, it will be even more important to allow reasonable display filtering -- 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-12186) warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does)
[ https://issues.jenkins-ci.org/browse/JENKINS-12186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159745#comment-159745 ] SCM/JIRA link daemon commented on JENKINS-12186: Code changed in jenkins User: Ulli Hafner Path: src/main/resources/hudson/plugins/analysis/collector/dashboard/WarningsTablePortlet/portlet.jelly http://jenkins-ci.org/commit/analysis-collector-plugin/98de615d0f44caabd4c3a306403733a5eeb2bd9c Log: [FIXED JENKINS-12186] Fixed visibility of open tasks column. warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does) - Key: JENKINS-12186 URL: https://issues.jenkins-ci.org/browse/JENKINS-12186 Project: Jenkins Issue Type: Improvement Components: analysis-collector Affects Versions: current Reporter: Greg Moncreaff Assignee: Ulli Hafner E.g. if you aren't looking at Java code, then Findbugs and Checkstyle and PMD don't have any value. When new things are tied into analysis core, it will be even more important to allow reasonable display filtering -- 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-12186) warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does)
[ https://issues.jenkins-ci.org/browse/JENKINS-12186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner reopened JENKINS-12186: --- This is a new bug. warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does) - Key: JENKINS-12186 URL: https://issues.jenkins-ci.org/browse/JENKINS-12186 Project: Jenkins Issue Type: Improvement Components: analysis-collector Affects Versions: current Reporter: Greg Moncreaff Assignee: Ulli Hafner E.g. if you aren't looking at Java code, then Findbugs and Checkstyle and PMD don't have any value. When new things are tied into analysis core, it will be even more important to allow reasonable display filtering -- 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-12186) warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does)
[ https://issues.jenkins-ci.org/browse/JENKINS-12186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159746#comment-159746 ] dogfood commented on JENKINS-12186: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_analysis-collector #326|http://ci.jenkins-ci.org/job/plugins_analysis-collector/326/] [FIXED JENKINS-12186] Fixed visibility of open tasks column. (Revision 98de615d0f44caabd4c3a306403733a5eeb2bd9c) Result = SUCCESS Ulli Hafner : Files : * src/main/resources/hudson/plugins/analysis/collector/dashboard/WarningsTablePortlet/portlet.jelly warnings per project dashboard portlet should allow un-used columns to be turned off, same as warnings trend (type distribution does) - Key: JENKINS-12186 URL: https://issues.jenkins-ci.org/browse/JENKINS-12186 Project: Jenkins Issue Type: Improvement Components: analysis-collector Affects Versions: current Reporter: Greg Moncreaff Assignee: Ulli Hafner E.g. if you aren't looking at Java code, then Findbugs and Checkstyle and PMD don't have any value. When new things are tied into analysis core, it will be even more important to allow reasonable display filtering -- 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-12844) Information about locked builds don't show anywhere.
[ https://issues.jenkins-ci.org/browse/JENKINS-12844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-12844 stopped by Kamil Wiraszka. Information about locked builds don't show anywhere. Key: JENKINS-12844 URL: https://issues.jenkins-ci.org/browse/JENKINS-12844 Project: Jenkins Issue Type: Bug Components: locks-and-latches Reporter: Kamil Wiraszka Hi, I have the same problem like Mr. Jorg Heymans in his question http://jenkins.361315.n4.nabble.com/locks-and-latches-plugin-question-td381053.html, but I'm just wondering if this plugin could display information in console about lock in these suspended 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-11337) Git plugin only triggers a build for one branch
[ https://issues.jenkins-ci.org/browse/JENKINS-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159748#comment-159748 ] Harry McIntyre commented on JENKINS-11337: -- That is also the behaviour I want - and it used to work? Git plugin only triggers a build for one branch --- Key: JENKINS-11337 URL: https://issues.jenkins-ci.org/browse/JENKINS-11337 Project: Jenkins Issue Type: Bug Components: git Affects Versions: current Reporter: Andreas Pakulat Assignee: abayer Priority: Critical I've just downloaded Jenkins 1.434 to see wether the last comment in #JENKINS-7554 from Christian Weiske is true that the newest git plugin solves the problems with the GIT_BRANCH/GIT_COMMIT envvars and setting the build up to build multiple branches. Unfortunately it turns out that the plugin does not support building multiple branches anymore at all. No matter wether I leave the branch field empty or add multiple branches to the build configuration it always only builds master. Tried with a totally fresh job so all branches need to be considered 'updated' and polling as well as manual building. -- 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-11337) Git plugin only triggers a build for one branch
[ https://issues.jenkins-ci.org/browse/JENKINS-11337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159749#comment-159749 ] Andreas Pakulat commented on JENKINS-11337: --- Yes, admittingly on a rather old version of Hudson/Git plugin. Hudson is 1.359 and the git plugin is at 1.1.6 Git plugin only triggers a build for one branch --- Key: JENKINS-11337 URL: https://issues.jenkins-ci.org/browse/JENKINS-11337 Project: Jenkins Issue Type: Bug Components: git Affects Versions: current Reporter: Andreas Pakulat Assignee: abayer Priority: Critical I've just downloaded Jenkins 1.434 to see wether the last comment in #JENKINS-7554 from Christian Weiske is true that the newest git plugin solves the problems with the GIT_BRANCH/GIT_COMMIT envvars and setting the build up to build multiple branches. Unfortunately it turns out that the plugin does not support building multiple branches anymore at all. No matter wether I leave the branch field empty or add multiple branches to the build configuration it always only builds master. Tried with a totally fresh job so all branches need to be considered 'updated' and polling as well as manual building. -- 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-9241) maven2: java.lang.IllegalArgumentException: /usr/bin/mvn without lib directory
[
https://issues.jenkins-ci.org/browse/JENKINS-9241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159750#comment-159750
]
Quintin Siebers commented on JENKINS-9241:
--
When I had this problem, it was because the Apache zip was extracted into
{MavenName}/apache-maven-3.0.4, while Hudson checks the {MavenName}/lib folder.
The solution is to manually move your extracted maven up one directory.
maven2: java.lang.IllegalArgumentException: /usr/bin/mvn without lib directory
--
Key: JENKINS-9241
URL: https://issues.jenkins-ci.org/browse/JENKINS-9241
Project: Jenkins
Issue Type: Bug
Components: maven2
Affects Versions: current
Environment: Ubuntu 10.10 hudson running inside tomcat6
Reporter: ssbarnea
I get the following error when I try to execute a maven task from hudson.
Maven is installed on the OS and I'm able to use it from the command line.
Maven is configured inside Jenkins config but I still get this unclear error.
java.lang.IllegalArgumentException: /usr/bin/mvn without lib directory
at
hudson.maven.MavenEmbedderUtils.buildClassRealm(MavenEmbedderUtils.java:81)
at
hudson.maven.MavenEmbedderUtils.getMavenVersion(MavenEmbedderUtils.java:170)
at hudson.maven.MavenVersionCallable.call(MavenVersionCallable.java:56)
at hudson.maven.MavenVersionCallable.call(MavenVersionCallable.java:40)
at hudson.FilePath.act(FilePath.java:785)
at
hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:568)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:423)
at hudson.model.Run.run(Run.java:1362)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:454)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:145)
--
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-12960) create new chart in gloabl build stat does not work with auto-refresh on
robsimon created JENKINS-12960: -- Summary: create new chart in gloabl build stat does not work with auto-refresh on Key: JENKINS-12960 URL: https://issues.jenkins-ci.org/browse/JENKINS-12960 Project: Jenkins Issue Type: Bug Components: global-build-stats Affects Versions: current Environment: Windows 7 64 SP1, JDK 1.6_29_x64, Jenkins 1.452, Global-Build-Stat plugin 1.2, Firefox 10.0.2 Reporter: robsimon Assignee: fcamblor * have auto-refresh on * click on 'Create new chart' Then overlay to enter chart data will disappear with the next refresh. Expected behavior - overlay would stick until data is saved or canceled -- 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-8871) Allow to use other SVN protocol than http/https
[
https://issues.jenkins-ci.org/browse/JENKINS-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159751#comment-159751
]
Pedro Correia commented on JENKINS-8871:
Hi everyone,
Don't know if anybody is still busy with this, but I was trying to get this
working.
Initially I ran into the same problem as reported by [~jchatham]:
{code}
Mar 2, 2012 1:41:15 PM hudson.plugins.scm_sync_configuration.SCMManipulator
checkout
SEVERE: [checkout] Error during checkout : SVN checkout failed.
Mar 2, 2012 1:41:15 PM hudson.plugins.scm_sync_configuration.SCMManipulator
scmConfigurationSettledUp
INFO: Creating scmRepository connection data ..
{code}
To try to fix this I manually checked out the
{{JENKINS_HOME/scm-sync-configuration/checkoutConfiguration}} directory. That
solves that problem, but now I get problems committing changes to the
configuration files:
{code}
Mar 2, 2012 1:48:13 PM hudson.plugins.scm_sync_configuration.SCMManipulator
checkinFiles
SEVERE: [checkinFiles] Problem during commit of [[config.xml]] : svn: Commit
failed (details follow):
svn: Authentication required for 'svn+ssh://tk7'
{code}
This is strange because I'm pretty sure the credentials are set up correctly...
Any thoughts?
Allow to use other SVN protocol than http/https
---
Key: JENKINS-8871
URL: https://issues.jenkins-ci.org/browse/JENKINS-8871
Project: Jenkins
Issue Type: Improvement
Components: scm-sync-configuration
Reporter: fcamblor
Assignee: fcamblor
Attachments: scm-sync-configuration-0.0.5-bugfix8871-1.hpi
Prior to v0.0.3, scm-sync-configuration plugin is relying on svnjava maven
scm provider (see
http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/ ),
only http/https/file protocols are supported (for example svn+ssh is not
supported).
Eventually, a workaround would be to activate svnexe maven scm implementation
for these case (Problem is : I don't know if we can have both svnexe
svnjava plexus component activated in the same time)
Nevertheless, the best point would be to have svnjava be compliant with every
svn supported protocols.
--
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-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159752#comment-159752 ] Bruno P. Kinoshita commented on JENKINS-12810: -- Hi Jaroslavas Why plugin should seek for platform option in XML? That's because a plan has many platforms. Let's say you have a test plan with two platforms. Now the plug-in *must* always include the platform ID or the platform name when invoking TestLink XML-RPC API methods. Otherwise an error is raised by TestLink. There's no test plan option in generated JUnit/TestNG XMLs, but no problem for plugin to find TC only from defined Test Plan. That's a good argument :D But here's no way to include the platform in the job configuration screen (imagine a scenario with 20 platforms). The platform is linked to the test case, and not to the test project (like test plan). Below I tried to represent how is the relation of each entity more or less (omitted test case version for simplicity) test project - has many - test plan - has many - test case - has one - platform . - has many - platform Thank You, Bruno, for productive communication! And sorry for my silly questions. I really enjoy having this type of conversation Jaroslavas. And no need for sorry your questions are very good. I'm not really programer guy - I'm tester. So, my point of view to problem may be different That's why it's so important that you participate in the project. Each time a user like you propose a new feature, find a bug, or just has a cool conversation like this, the plug-in gets better and more useful for testers, developers, devops and so it goes. This weekend I think I will have the first release candidate for 3.1, with all the issues found during alpha test fixed, as well as the release check list done (https://wiki.jenkins-ci.org/display/JENKINS/Release+check+list). I also want to include all the alpha testers in the plug-in team as contributors (unless they prefer remain anonymous :) Cheers Bruno JUnit test results are getting wrongly attached to all the test cases - Key: JENKINS-12810 URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 Project: Jenkins Issue Type: Bug Components: testlink Affects Versions: current Reporter: Vignesh Senapathy Assignee: Bruno P. Kinoshita Fix For: current Attachments: 1.jpg, 2.jpg, 3.jpg, last_tc.png, schema.jpg, screenshot20120228152415.jpg, screenshot20120228152511.jpg, tc1.png, tc2.png, testlink-3.1-alpha2.hpi Hi, I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the Junit Test results are getting generated. This in turn calls the Testlink xml rpc and attaches the results to the test case, but the test results are attached wrongly. The 1st test case has 6 results, the next has 5 and so on and the last one has 1 test result attached to it. I dont know if it is bug which is causing this. Please let me know what seems to be the problems. Also the execution flags are correctly rendered in this. which ever test case fails is marked as failed and which passed is marked as passed. Also I have one custom field which maps to the test suite name and test classname. -- 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-11628) Jenkins is no longer updating JIRA tickets
[ https://issues.jenkins-ci.org/browse/JENKINS-11628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159753#comment-159753 ] sogabe commented on JENKINS-11628: -- @Andrew Is your JIRA 5.0? Jenkins is no longer updating JIRA tickets -- Key: JENKINS-11628 URL: https://issues.jenkins-ci.org/browse/JENKINS-11628 Project: Jenkins Issue Type: Bug Components: jira Affects Versions: current Reporter: Andrew Knapp Ever since we upgraded Jenkins to 1.435 (I think), the JIRA plugin has been broken. No other changes have been made, but the plugin is not updating the corresponding issues in JIRA. I see our JIRA user making soap calls in our JIRA logs (I turned on the soap dump logs), but it's not actually updating the tickets. Any ideas? Let me know if you need more information about our setup or whatnot. JIRA Plugin version: 1.29 Jenkins version: 1.437 -- 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-12602) Detection of first build seems to be broken
[ https://issues.jenkins-ci.org/browse/JENKINS-12602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-12602 started by Ulli Hafner. Detection of first build seems to be broken --- Key: JENKINS-12602 URL: https://issues.jenkins-ci.org/browse/JENKINS-12602 Project: Jenkins Issue Type: Bug Components: tasks-plugin Reporter: Ulli Hafner Assignee: Ulli Hafner Priority: Trivial 13:24:42 [TASKS] Found 0 files to scan for tasks 13:24:42 Found 0 open tasks. 13:24:42 [TASKS] File encoding has not been set in pom.xml, using platform encoding UTF-8, i.e. build is platform dependent (see a href=http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding;Maven FAQ/a). 13:24:43 [TASKS] Ignore new warnings since this is the first valid build 13:24:43 [TASKS] Not changing build status, since no threshold has been exceeded 13:24:43 [TASKS] Computing warning deltas based on reference build #23 -- 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-12393) Support Matrix Projects
[ https://issues.jenkins-ci.org/browse/JENKINS-12393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159754#comment-159754 ] Andy Bigos commented on JENKINS-12393: -- Closing as appears to work. Support Matrix Projects --- Key: JENKINS-12393 URL: https://issues.jenkins-ci.org/browse/JENKINS-12393 Project: Jenkins Issue Type: Improvement Components: log-parser Affects Versions: current Reporter: Andy Bigos Assignee: rgoren Hi, I'm using the plugin without problems on simple builds, but it doesn't appear to support/work for matrix builds. Can you confirm if it's expected to work currently? If not I'd like to request the addition of support for matrix type projects. Thanks Andy -- 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-12602) Detection of first build seems to be broken
[ https://issues.jenkins-ci.org/browse/JENKINS-12602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159755#comment-159755 ] SCM/JIRA link daemon commented on JENKINS-12602: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/analysis/core/MavenResultAction.java http://jenkins-ci.org/commit/analysis-core-plugin/7dc673e3064361b361efbc9b71e6c7643dc856e8 Log: [FIXED JENKINS-12602] Don't evaluate build health if no threshold is given. Detection of first build seems to be broken --- Key: JENKINS-12602 URL: https://issues.jenkins-ci.org/browse/JENKINS-12602 Project: Jenkins Issue Type: Bug Components: tasks-plugin Reporter: Ulli Hafner Assignee: Ulli Hafner Priority: Trivial 13:24:42 [TASKS] Found 0 files to scan for tasks 13:24:42 Found 0 open tasks. 13:24:42 [TASKS] File encoding has not been set in pom.xml, using platform encoding UTF-8, i.e. build is platform dependent (see a href=http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding;Maven FAQ/a). 13:24:43 [TASKS] Ignore new warnings since this is the first valid build 13:24:43 [TASKS] Not changing build status, since no threshold has been exceeded 13:24:43 [TASKS] Computing warning deltas based on reference build #23 -- 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-12602) Detection of first build seems to be broken
[ https://issues.jenkins-ci.org/browse/JENKINS-12602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12602. Resolution: Fixed Detection of first build seems to be broken --- Key: JENKINS-12602 URL: https://issues.jenkins-ci.org/browse/JENKINS-12602 Project: Jenkins Issue Type: Bug Components: tasks-plugin Reporter: Ulli Hafner Assignee: Ulli Hafner Priority: Trivial 13:24:42 [TASKS] Found 0 files to scan for tasks 13:24:42 Found 0 open tasks. 13:24:42 [TASKS] File encoding has not been set in pom.xml, using platform encoding UTF-8, i.e. build is platform dependent (see a href=http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding;Maven FAQ/a). 13:24:43 [TASKS] Ignore new warnings since this is the first valid build 13:24:43 [TASKS] Not changing build status, since no threshold has been exceeded 13:24:43 [TASKS] Computing warning deltas based on reference build #23 -- 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-12602) Detection of first build seems to be broken
[ https://issues.jenkins-ci.org/browse/JENKINS-12602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159756#comment-159756 ] dogfood commented on JENKINS-12602: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_analysis-core #10421|http://ci.jenkins-ci.org/job/plugins_analysis-core/10421/] [FIXED JENKINS-12602] Don't evaluate build health if no threshold is (Revision 7dc673e3064361b361efbc9b71e6c7643dc856e8) Result = SUCCESS Ulli Hafner : Files : * src/main/java/hudson/plugins/analysis/core/MavenResultAction.java Detection of first build seems to be broken --- Key: JENKINS-12602 URL: https://issues.jenkins-ci.org/browse/JENKINS-12602 Project: Jenkins Issue Type: Bug Components: tasks-plugin Reporter: Ulli Hafner Assignee: Ulli Hafner Priority: Trivial 13:24:42 [TASKS] Found 0 files to scan for tasks 13:24:42 Found 0 open tasks. 13:24:42 [TASKS] File encoding has not been set in pom.xml, using platform encoding UTF-8, i.e. build is platform dependent (see a href=http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding;Maven FAQ/a). 13:24:43 [TASKS] Ignore new warnings since this is the first valid build 13:24:43 [TASKS] Not changing build status, since no threshold has been exceeded 13:24:43 [TASKS] Computing warning deltas based on reference build #23 -- 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-12961) Plugin: Role Based Authorization Strategy configuration fails with openLDAP group
Bengt Fahlgren created JENKINS-12961:
Summary: Plugin: Role Based Authorization Strategy configuration
fails with openLDAP group
Key: JENKINS-12961
URL: https://issues.jenkins-ci.org/browse/JENKINS-12961
Project: Jenkins
Issue Type: Bug
Components: role-strategy
Affects Versions: current
Environment: Linux CentOS 5.5
Oracle Java JDK1.6.0_u31
Jenkins LTS 1.424.2
role-strategy 1.1.2
https with a JKS keystore
Winstone Servlet Container (No apache Frontend)
Reporter: Bengt Fahlgren
Assignee: Daniel Petisme
Hi!
Working configuration:
Matrix based authorization
I can add a unix/ldap group to a Global Role and the group is detected OK
The group icon is visible, and the configuration is working OK
Not working configuration:
When I switch to Role Base Authorization in Manage Jenkins
Save and restart of Jenkins
When I try to add the same group to a Global Role a row is added but the group
icon is missing.
ldapsearch works OK
BTW a Group filter function seams to be missing in Jenkins LDAP advanced
configuration.
LDAP setting
Server: x.y.z.se
RootDN: dc=y,dc=z,dc=se
User Search Base: ou=users
User Search Filter: uid={0}
Groups Search Base: ou=Groups
RGDS/ bangalore
--
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-12424) More correct and specific build state change reasons from Warnings
[ https://issues.jenkins-ci.org/browse/JENKINS-12424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner reopened JENKINS-12424: --- Yes, that would improve that usability even more. Since this feature needs the HTML links from the individual plug-ins, changes to all plug-ins are required (and not only to analysis-core). So this will take some time... More correct and specific build state change reasons from Warnings --- Key: JENKINS-12424 URL: https://issues.jenkins-ci.org/browse/JENKINS-12424 Project: Jenkins Issue Type: Improvement Components: analysis-core, warnings Reporter: Greg Moncreaff Assignee: Ulli Hafner Priority: Minor I got this in my jobs console. [WARNINGS] Setting build status to FAILURE since total number of annotations exceeds the threshold 200: [HIGH, NORMAL, LOW] Two issues. 1. text says total, but this was actually a compute status since reference build (new) gate. 2. text should say which specific criteria was exceeded 3. it doesn't tell you what the actual number/difference was E.g. [WARNINGS] Setting build status to FAILURE since number, 234, of new HIGH annotations exceeds the threshold of 200 by 34 or 17%. -- 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-11628) Jenkins is no longer updating JIRA tickets
[ https://issues.jenkins-ci.org/browse/JENKINS-11628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159758#comment-159758 ] Peter Callies commented on JENKINS-11628: - Sorry for the confusion. I ran into this error on our JIRA 4.4.4 instance. I'm testing JIRA 5.0, but that's not where I ran into this issue. Jenkins is no longer updating JIRA tickets -- Key: JENKINS-11628 URL: https://issues.jenkins-ci.org/browse/JENKINS-11628 Project: Jenkins Issue Type: Bug Components: jira Affects Versions: current Reporter: Andrew Knapp Ever since we upgraded Jenkins to 1.435 (I think), the JIRA plugin has been broken. No other changes have been made, but the plugin is not updating the corresponding issues in JIRA. I see our JIRA user making soap calls in our JIRA logs (I turned on the soap dump logs), but it's not actually updating the tickets. Any ideas? Let me know if you need more information about our setup or whatnot. JIRA Plugin version: 1.29 Jenkins version: 1.437 -- 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-12962) Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin
Thomas Fields created JENKINS-12962: --- Summary: Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin Key: JENKINS-12962 URL: https://issues.jenkins-ci.org/browse/JENKINS-12962 Project: Jenkins Issue Type: Bug Components: ws-cleanup Affects Versions: current Environment: Jenkins 1.452, Win7 Reporter: Thomas Fields Assignee: vjuranek Hi there, The Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin. Here's a snippet from my console output for my build: 14:33:23 Deleting project workspace... done 14:33:23 14:33:23 [copy-to-slave] Copying 'Engine/Lib/**/*.lib, Engine/Lib/**/*.pdb, Engine/Lib/**/*.a', excluding nothing, from 'file:/c:/JCI/workspace/Expat-Live/CONFIG/Debug/TARGET/GCC/VSVERSION/2008' on 'hudson.slaves.DumbSlave@720397f7' to 'file:/C:/JCI/current_build/Expat-Live/CL167206' on the master. Note how the workspace is deleted before the copy step begins. Can this be fixed please? I assume deleting a workspace is something you'd always want to do last. I'd be happy to test any fixes. Regards, Tom. -- 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-12963) EnvInject plugin causes job to use JAVA_HOME instead of configured JDK
jvoegele created JENKINS-12963: -- Summary: EnvInject plugin causes job to use JAVA_HOME instead of configured JDK Key: JENKINS-12963 URL: https://issues.jenkins-ci.org/browse/JENKINS-12963 Project: Jenkins Issue Type: Bug Components: envinject Reporter: jvoegele Assignee: gbois Priority: Critical After upgrading the EnvInject plugin from version 1.17 to 1.30, Jenkins jobs stopped using the JDK configured for the job and would instead use the JDK referred to by the JAVA_HOME environment variable. For example, a test job that was configured for JDK 1.5 would run with JDK 1.6.0_30, as shown by the following console output: JAVA_HOME=/X/hotspot1.6.0_30 ... Apache Maven 2.2.1 (r801777; 2009-08-06 12:16:01-0700) Java version: 1.6.0_30 Java home: /X/hotspot1.6.0_30/jre The jobs are free-style software projects which use Maven in some of the build steps. Downgrading the plugin to the previously installed 1.17 version fixed this problem, but I do not know exactly what version introduced the issue. -- 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-12962) Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159760#comment-159760 ] vjuranek commented on JENKINS-12962: just for sure, are you using ws cleanup 0.6 (which should solve this kind of problems) or higher? Thanks Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin --- Key: JENKINS-12962 URL: https://issues.jenkins-ci.org/browse/JENKINS-12962 Project: Jenkins Issue Type: Bug Components: ws-cleanup Affects Versions: current Environment: Jenkins 1.452, Win7 Reporter: Thomas Fields Assignee: vjuranek Hi there, The Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin. Here's a snippet from my console output for my build: 14:33:23 Deleting project workspace... done 14:33:23 14:33:23 [copy-to-slave] Copying 'Engine/Lib/**/*.lib, Engine/Lib/**/*.pdb, Engine/Lib/**/*.a', excluding nothing, from 'file:/c:/JCI/workspace/Expat-Live/CONFIG/Debug/TARGET/GCC/VSVERSION/2008' on 'hudson.slaves.DumbSlave@720397f7' to 'file:/C:/JCI/current_build/Expat-Live/CL167206' on the master. Note how the workspace is deleted before the copy step begins. Can this be fixed please? I assume deleting a workspace is something you'd always want to do last. I'd be happy to test any fixes. Regards, Tom. -- 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-12965) mercurial build crash
Ken Stevens created JENKINS-12965: - Summary: mercurial build crash Key: JENKINS-12965 URL: https://issues.jenkins-ci.org/browse/JENKINS-12965 Project: Jenkins Issue Type: Bug Components: mercurial Environment: Linux 2.6.30.5-xenU i686 GNU/Linux Reporter: Ken Stevens Assignee: Kohsuke Kawaguchi Fix For: current Project set up with mercurial scm. When trying to do a build, I get the following error. Started by user kstevens Building in workspace /usr/local/tomcat/.hudson/jobs/stratinit/workspace FATAL: null java.lang.NullPointerException at hudson.tools.ToolInstaller.preferredLocation(ToolInstaller.java:115) at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:61) at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:61) at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:107) at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:150) at hudson.tasks.Maven$MavenInstallation.forNode(Maven.java:515) at hudson.maven.MavenModuleSetBuild.getEnvironment(MavenModuleSetBuild.java:173) at hudson.plugins.mercurial.MercurialSCM.clone(MercurialSCM.java:562) at hudson.plugins.mercurial.MercurialSCM.checkout(MercurialSCM.java:421) at hudson.model.AbstractProject.checkout(AbstractProject.java:1195) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:579) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:468) at hudson.model.Run.run(Run.java:1408) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:481) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) -- 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-12836) Gerrit-Trigger spams log with class ....Branch is missing its descriptor in ... ....GerritProject.getBranches()
[
https://issues.jenkins-ci.org/browse/JENKINS-12836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159761#comment-159761
]
Thomas Broyer commented on JENKINS-12836:
-
https://github.com/jenkinsci/gerrit-trigger-plugin/pull/13
Gerrit-Trigger spams log with class Branch is missing its descriptor in
... GerritProject.getBranches()
-
Key: JENKINS-12836
URL: https://issues.jenkins-ci.org/browse/JENKINS-12836
Project: Jenkins
Issue Type: Bug
Components: gerrit-trigger
Environment: Jenkins 1.451 with Gerrit-Trigger 2.3.1, then upgraded
to Gerrit-Trigger 2.4.0.
Reporter: Thomas Broyer
Assignee: rsandell
Priority: Minor
Attachments: jenkins.log
Log is full of:
{noformat}
Caused by: java.lang.AssertionError: class
com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.data.Branch is
missing its descriptor in public java.util.List
com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.data.GerritProject.getBranches().
See
https://wiki.jenkins-ci.org/display/JENKINS/My+class+is+missing+descriptor
at
hudson.model.Descriptor$PropertyType.getItemTypeDescriptorOrDie(Descriptor.java:194)
... 198 more
{noformat}
See attachment for full log.
--
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=159763#comment-159763
]
Curtis Ruck commented on JENKINS-12307:
---
Are there any workarounds to get the config page to be usable again?
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)
[JIRA] (JENKINS-12386) Self Promotion is broken - missing index.jelly file
[ https://issues.jenkins-ci.org/browse/JENKINS-12386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159762#comment-159762 ] Alexandre Chambriat commented on JENKINS-12386: --- Same here : Jenkins version 1.452 Jenkins promoted builds plugin 2.4 Self Promotion is broken - missing index.jelly file --- Key: JENKINS-12386 URL: https://issues.jenkins-ci.org/browse/JENKINS-12386 Project: Jenkins Issue Type: Bug Components: promoted-builds Affects Versions: current Environment: Jenkins version 1.447 Build Promotion plugin versions 2.3 and 2.4 Reporter: Valerie Wagner My project is configured to Promote immediately once the build is complete. After the project builds, there is no star indicating that a promotion has taken place. I click on the latest build and then on Promotion Status link. A stack trace is generated: Status Code: 500 Exception: Stacktrace: org.apache.commons.jelly.JellyTagException: file:/jenkins/plugins/promoted-builds/WEB-INF/classes/hudson/plugins/promoted_builds/PromotedBuildAction/index.jelly:115:54: st:include No page found 'index.jelly' for class hudson.plugins.promoted_builds.conditions.SelfPromotionCondition at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:124) 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.ForEachTag.doTag(ForEachTag.java:150) 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.ForEachTag.doTag(ForEachTag.java:150) 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.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.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.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) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:125) at
[JIRA] (JENKINS-12954) Configure accurev server per Jenkins node
[ https://issues.jenkins-ci.org/browse/JENKINS-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159764#comment-159764 ] Mike M commented on JENKINS-12954: -- This has been a want for a long time. Here's a link to the request from 2 years ago in the Hudson ticket repository. http://issues.hudson-ci.org/browse/HUDSON-6027 Configure accurev server per Jenkins node - Key: JENKINS-12954 URL: https://issues.jenkins-ci.org/browse/JENKINS-12954 Project: Jenkins Issue Type: New Feature Components: accurev Environment: Ubuntu 10.04.04 - Jenkins LTS Reporter: pickgr1 Assignee: Scott Tatum There may be a way to configure this already that I'm overlooking somewhere, but if not, this would be a great feature. In the Jenkins global configuration, it's possible to add multiple servers (replicas) We have replicas that are geographically diverse across a corporate WAN. For example, we have Jenkins nodes/slaves at both site A and site B. Each site also has it's own AccuRev replica. So we want nodes at site A to use their local AccuRev replica and nodes at site B use their local replica. I see that it's possible to configure this on a per-job basis, but what we really need is a per node/slave basis. Otherwise, we have to maintain separate jobs for each site. -- 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-11938) Jenkins loses builds when restarted
[ https://issues.jenkins-ci.org/browse/JENKINS-11938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159765#comment-159765 ] Brian Altenhofel commented on JENKINS-11938: Experiencing the same problem here. Jenkins 1.452 on Debian Squeeze. Debugging information class : hudson.model.FreeStyleBuild required-type : org.eclipse.jgit.lib.ObjectId path: /build/actions/hudson.plugins.git.util.BuildData/buildsByBranchName/entry/hudson.plugins.git.util.Build/revision/sha1 line number : 18 --- at com.thoughtworks.xstream.converters.reflection.SerializableConverter.doUnmarshal(SerializableConverter.java:281) at com.thoughtworks.xstream.converters.reflection.AbstractReflectionConverter.unmarshal(AbstractReflectionConverter.java:162) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:292) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:234) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:181) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:292) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:234) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:181) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at com.thoughtworks.xstream.converters.collections.MapConverter.populateMap(MapConverter.java:79) at com.thoughtworks.xstream.converters.collections.MapConverter.unmarshal(MapConverter.java:66) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:292) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:234) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:181) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:60) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:61) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:82) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:63) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:76) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:292) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:234) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:181) at
[JIRA] (JENKINS-4338) Hudson hangs
[ https://issues.jenkins-ci.org/browse/JENKINS-4338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] evernat resolved JENKINS-4338. -- Resolution: Incomplete No response, so resolving as incomplete. Hudson hangs Key: JENKINS-4338 URL: https://issues.jenkins-ci.org/browse/JENKINS-4338 Project: Jenkins Issue Type: Bug Components: build-timeout Affects Versions: current Environment: Platform: Other, OS: other Reporter: mnordlund Assignee: Kohsuke Kawaguchi Priority: Trivial Running hudson in a vmWare virtualized environment we tend to get some hangs when hudson is performing builds. Here are the requested stack dumps: Skip to content title search help for search * * * * * * * * * * HudsonENABLE AUTO REFRESH New Job Manage Hudson People Build History Build Queue No builds in the queue. Build Executor Status # Status 1 Building skolvcm #241 terminate this build 2 Idle Thread Dump ant clean-all test: stdout copier ant clean-all test: stdout copier Id=72 RUNNABLE (in native) at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:199) at java.io.BufferedInputStream.read1(BufferedInputStream.java:256) at java.io.BufferedInputStream.read(BufferedInputStream.java:317) - locked java.io.BufferedInputStream@14c02d4 at java.io.FilterInputStream.read(FilterInputStream.java:90) at hudson.util.StreamCopyThread.run(StreamCopyThread.java:56) process reaper process reaper Id=71 RUNNABLE (in native) at java.lang.UNIXProcess.waitForProcessExit(Native Method) at java.lang.UNIXProcess.access$900(UNIXProcess.java:20) at java.lang.UNIXProcess$1$1.run(UNIXProcess.java:132) RequestHandlerThread[#3] RequestHandlerThread[#3] Id=11 WAITING on winstone.RequestHandlerThread@14db52b at java.lang.Object.wait(Native Method) - waiting on winstone.RequestHandlerThread@14db52b at java.lang.Object.wait(Object.java:485) at winstone.RequestHandlerThread.run(RequestHandlerThread.java:216) at java.lang.Thread.run(Thread.java:619) RequestHandlerThread[#4] RequestHandlerThread[#4] Id=12 RUNNABLE at sun.management.ThreadImpl.dumpThreads0(Native Method) at sun.management.ThreadImpl.getThreadInfo(ThreadImpl.java:359) at hudson.Functions.getThreadInfos(Functions.java:746) 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.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104) 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:71) at org.apache.commons.jelly.expression.ExpressionSupport.evaluateRecurse(ExpressionSupport.java:61) at org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsIterator(ExpressionSupport.java:94) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:89) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:186) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CustomTagLibrary$StaplerDynamicTag$1.run(CustomTagLibrary.java:147) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262) at
[JIRA] (JENKINS-12962) Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159768#comment-159768 ] Thomas Fields commented on JENKINS-12962: - Ah yes this seems to be a duplicate of https://issues.jenkins-ci.org/browse/JENKINS-11210. I may not be using version 0.6 - I'll confirm on Monday. Thanks Tom Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin --- Key: JENKINS-12962 URL: https://issues.jenkins-ci.org/browse/JENKINS-12962 Project: Jenkins Issue Type: Bug Components: ws-cleanup Affects Versions: current Environment: Jenkins 1.452, Win7 Reporter: Thomas Fields Assignee: vjuranek Hi there, The Workspace Cleanup Plugin does not play nicely with the Copy To Slave plugin. Here's a snippet from my console output for my build: 14:33:23 Deleting project workspace... done 14:33:23 14:33:23 [copy-to-slave] Copying 'Engine/Lib/**/*.lib, Engine/Lib/**/*.pdb, Engine/Lib/**/*.a', excluding nothing, from 'file:/c:/JCI/workspace/Expat-Live/CONFIG/Debug/TARGET/GCC/VSVERSION/2008' on 'hudson.slaves.DumbSlave@720397f7' to 'file:/C:/JCI/current_build/Expat-Live/CL167206' on the master. Note how the workspace is deleted before the copy step begins. Can this be fixed please? I assume deleting a workspace is something you'd always want to do last. I'd be happy to test any fixes. Regards, Tom. -- 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-12223) Warnings trend graph (type distribution) dashboard portlet is very slow to display when # jobs in view 12 or so
[ https://issues.jenkins-ci.org/browse/JENKINS-12223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159769#comment-159769 ] Greg Moncreaff commented on JENKINS-12223: -- Its incredibly faster now! I had a dashboard with a couple hundred jobs and the warning trend by type, it used to take many minutes to load and now its no more that a couple of seconds! Excellent work! Warnings trend graph (type distribution) dashboard portlet is very slow to display when # jobs in view 12 or so - Key: JENKINS-12223 URL: https://issues.jenkins-ci.org/browse/JENKINS-12223 Project: Jenkins Issue Type: Improvement Components: analysis-collector, analysis-core, dashboard-view, warnings Affects Versions: current Reporter: Greg Moncreaff Assignee: Ulli Hafner Is it possible that the data can be cached (in the dashboard view) to be reused (and refreshed in the background as needed) rather than starting from scratch each time. While waiting for portlet to finish, view controls in other portlets (e.g. sorts) are not available. -- 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-8871) Allow to use other SVN protocol than http/https
[ https://issues.jenkins-ci.org/browse/JENKINS-8871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159770#comment-159770 ] fcamblor commented on JENKINS-8871: --- Hi Pedro, I just created https://wiki.jenkins-ci.org/display/JENKINS/ScmSyncConfig+Troubleshootings Can you please see if it can help ? Allow to use other SVN protocol than http/https --- Key: JENKINS-8871 URL: https://issues.jenkins-ci.org/browse/JENKINS-8871 Project: Jenkins Issue Type: Improvement Components: scm-sync-configuration Reporter: fcamblor Assignee: fcamblor Attachments: scm-sync-configuration-0.0.5-bugfix8871-1.hpi Prior to v0.0.3, scm-sync-configuration plugin is relying on svnjava maven scm provider (see http://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/ ), only http/https/file protocols are supported (for example svn+ssh is not supported). Eventually, a workaround would be to activate svnexe maven scm implementation for these case (Problem is : I don't know if we can have both svnexe svnjava plexus component activated in the same time) Nevertheless, the best point would be to have svnjava be compliant with every svn supported protocols. -- 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-5942) setenv variables not available to email-ext
[
https://issues.jenkins-ci.org/browse/JENKINS-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159771#comment-159771
]
noahsussman edited comment on JENKINS-5942 at 3/2/12 10:51 PM:
---
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
In my build, I generate some information and write it to a logfile called
{{my_logfile}}. Then I cat out the log file and prefix each line with the
token *EMAIL:*
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of the
{{my_logfile}} file.
was (Author: noahsussman):
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
In my build, I generate some information and write it to a logfile called
{{my_logfile}}. Then I cat out the log file and prefix each line with the
token *EMAIL:*
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
setenv variables not available to email-ext
Key: JENKINS-5942
URL: https://issues.jenkins-ci.org/browse/JENKINS-5942
Project: Jenkins
Issue Type: Improvement
Components: email-ext
Environment: Hudson Setenv Plugin 1.1
Hudson Email Extension Plugin 2.5
hudson 1.346
Reporter: jminne
It seems like this should work after JENKINS-3605 was fixed so I followed the
documented reference format as clarified in JENKINS-2413 and JENKINS-5322
(i.e. ${ENV, var=VERSION}
I can get access to the default variables, but not ones set by setenv plugin
or by any build steps.
When this is fixed we should make sure that the recipients can be set as well
as the email content.
There are a couple of related patches out there.
http://n4.nabble.com/Email-notification-recipients-as-a-variable-td1578247.html#a1578247
Access to node env variables: JENKINS-5465
I'm not sure if this should be opened against email-ext or setenv plugin.
http://wiki.jenkins-ci.org/display/JENKINS/Setenv+Plugin
http://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
There is not currently a setenv component in jira so I'm opening this against
email-ext.
A recent discussion of this issue:
http://n4.nabble.com/How-to-use-environment-variables-td1012822.html#a1012822
--
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-5942) setenv variables not available to email-ext
[
https://issues.jenkins-ci.org/browse/JENKINS-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159771#comment-159771
]
noahsussman edited comment on JENKINS-5942 at 3/2/12 10:52 PM:
---
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
In my build, I generate some information and write it to a logfile called
{{my_logfile}}. Then I cat out the log file and prefix each line with the
token *EMAIL:*
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
was (Author: noahsussman):
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
In my build, I generate some information and write it to a logfile called
{{my_logfile}}. Then I cat out the log file and prefix each line with the
token *EMAIL:*
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of the
{{my_logfile}} file.
setenv variables not available to email-ext
Key: JENKINS-5942
URL: https://issues.jenkins-ci.org/browse/JENKINS-5942
Project: Jenkins
Issue Type: Improvement
Components: email-ext
Environment: Hudson Setenv Plugin 1.1
Hudson Email Extension Plugin 2.5
hudson 1.346
Reporter: jminne
It seems like this should work after JENKINS-3605 was fixed so I followed the
documented reference format as clarified in JENKINS-2413 and JENKINS-5322
(i.e. ${ENV, var=VERSION}
I can get access to the default variables, but not ones set by setenv plugin
or by any build steps.
When this is fixed we should make sure that the recipients can be set as well
as the email content.
There are a couple of related patches out there.
http://n4.nabble.com/Email-notification-recipients-as-a-variable-td1578247.html#a1578247
Access to node env variables: JENKINS-5465
I'm not sure if this should be opened against email-ext or setenv plugin.
http://wiki.jenkins-ci.org/display/JENKINS/Setenv+Plugin
http://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
There is not currently a setenv component in jira so I'm opening this against
email-ext.
A recent discussion of this issue:
http://n4.nabble.com/How-to-use-environment-variables-td1012822.html#a1012822
--
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-5942) setenv variables not available to email-ext
[
https://issues.jenkins-ci.org/browse/JENKINS-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159771#comment-159771
]
Noah Sussman edited comment on JENKINS-5942 at 3/2/12 11:02 PM:
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
In my build, I generate some information and write it to a logfile called
{{my_logfile}}. Then I cat out the log file and prefix each line with the
token {{EMAIL:}}
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
was (Author: noahsussman):
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
In my build, I generate some information and write it to a logfile called
{{my_logfile}}. Then I cat out the log file and prefix each line with the
token *EMAIL:*
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
setenv variables not available to email-ext
Key: JENKINS-5942
URL: https://issues.jenkins-ci.org/browse/JENKINS-5942
Project: Jenkins
Issue Type: Improvement
Components: email-ext
Environment: Hudson Setenv Plugin 1.1
Hudson Email Extension Plugin 2.5
hudson 1.346
Reporter: jminne
It seems like this should work after JENKINS-3605 was fixed so I followed the
documented reference format as clarified in JENKINS-2413 and JENKINS-5322
(i.e. ${ENV, var=VERSION}
I can get access to the default variables, but not ones set by setenv plugin
or by any build steps.
When this is fixed we should make sure that the recipients can be set as well
as the email content.
There are a couple of related patches out there.
http://n4.nabble.com/Email-notification-recipients-as-a-variable-td1578247.html#a1578247
Access to node env variables: JENKINS-5465
I'm not sure if this should be opened against email-ext or setenv plugin.
http://wiki.jenkins-ci.org/display/JENKINS/Setenv+Plugin
http://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
There is not currently a setenv component in jira so I'm opening this against
email-ext.
A recent discussion of this issue:
http://n4.nabble.com/How-to-use-environment-variables-td1012822.html#a1012822
--
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-5942) setenv variables not available to email-ext
[
https://issues.jenkins-ci.org/browse/JENKINS-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159771#comment-159771
]
Noah Sussman edited comment on JENKINS-5942 at 3/2/12 11:02 PM:
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
In my build, I generate some information and write it to a logfile called
{{my_logfile}}. Then I cat out the log file and prefix each line with the
token EMAIL:
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
was (Author: noahsussman):
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
In my build, I generate some information and write it to a logfile called
{{my_logfile}}. Then I cat out the log file and prefix each line with the
token {{EMAIL:}}
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
setenv variables not available to email-ext
Key: JENKINS-5942
URL: https://issues.jenkins-ci.org/browse/JENKINS-5942
Project: Jenkins
Issue Type: Improvement
Components: email-ext
Environment: Hudson Setenv Plugin 1.1
Hudson Email Extension Plugin 2.5
hudson 1.346
Reporter: jminne
It seems like this should work after JENKINS-3605 was fixed so I followed the
documented reference format as clarified in JENKINS-2413 and JENKINS-5322
(i.e. ${ENV, var=VERSION}
I can get access to the default variables, but not ones set by setenv plugin
or by any build steps.
When this is fixed we should make sure that the recipients can be set as well
as the email content.
There are a couple of related patches out there.
http://n4.nabble.com/Email-notification-recipients-as-a-variable-td1578247.html#a1578247
Access to node env variables: JENKINS-5465
I'm not sure if this should be opened against email-ext or setenv plugin.
http://wiki.jenkins-ci.org/display/JENKINS/Setenv+Plugin
http://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
There is not currently a setenv component in jira so I'm opening this against
email-ext.
A recent discussion of this issue:
http://n4.nabble.com/How-to-use-environment-variables-td1012822.html#a1012822
--
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-5942) setenv variables not available to email-ext
[
https://issues.jenkins-ci.org/browse/JENKINS-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159771#comment-159771
]
Noah Sussman edited comment on JENKINS-5942 at 3/2/12 11:03 PM:
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
Let's say my build generates a logfile called {{my_logfile}}, which is what I
want to include. What I do is cat out the log file and prefix each line with
the token EMAIL:
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
was (Author: noahsussman):
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
In my build, I generate some information and write it to a logfile called
{{my_logfile}}. Then I cat out the log file and prefix each line with the
token EMAIL:
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
setenv variables not available to email-ext
Key: JENKINS-5942
URL: https://issues.jenkins-ci.org/browse/JENKINS-5942
Project: Jenkins
Issue Type: Improvement
Components: email-ext
Environment: Hudson Setenv Plugin 1.1
Hudson Email Extension Plugin 2.5
hudson 1.346
Reporter: jminne
It seems like this should work after JENKINS-3605 was fixed so I followed the
documented reference format as clarified in JENKINS-2413 and JENKINS-5322
(i.e. ${ENV, var=VERSION}
I can get access to the default variables, but not ones set by setenv plugin
or by any build steps.
When this is fixed we should make sure that the recipients can be set as well
as the email content.
There are a couple of related patches out there.
http://n4.nabble.com/Email-notification-recipients-as-a-variable-td1578247.html#a1578247
Access to node env variables: JENKINS-5465
I'm not sure if this should be opened against email-ext or setenv plugin.
http://wiki.jenkins-ci.org/display/JENKINS/Setenv+Plugin
http://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
There is not currently a setenv component in jira so I'm opening this against
email-ext.
A recent discussion of this issue:
http://n4.nabble.com/How-to-use-environment-variables-td1012822.html#a1012822
--
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-5942) setenv variables not available to email-ext
[
https://issues.jenkins-ci.org/browse/JENKINS-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159771#comment-159771
]
Noah Sussman edited comment on JENKINS-5942 at 3/2/12 11:05 PM:
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
Let's say my build generates a logfile called {{my_logfile}}, which is what I
want to include. What I do is cat out the log file and prefix each line with
the token EMAIL:
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
was (Author: noahsussman):
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
Let's say my build generates a logfile called {{my_logfile}}, which is what I
want to include. What I do is cat out the log file and prefix each line with
the token EMAIL:
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then when in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
setenv variables not available to email-ext
Key: JENKINS-5942
URL: https://issues.jenkins-ci.org/browse/JENKINS-5942
Project: Jenkins
Issue Type: Improvement
Components: email-ext
Environment: Hudson Setenv Plugin 1.1
Hudson Email Extension Plugin 2.5
hudson 1.346
Reporter: jminne
It seems like this should work after JENKINS-3605 was fixed so I followed the
documented reference format as clarified in JENKINS-2413 and JENKINS-5322
(i.e. ${ENV, var=VERSION}
I can get access to the default variables, but not ones set by setenv plugin
or by any build steps.
When this is fixed we should make sure that the recipients can be set as well
as the email content.
There are a couple of related patches out there.
http://n4.nabble.com/Email-notification-recipients-as-a-variable-td1578247.html#a1578247
Access to node env variables: JENKINS-5465
I'm not sure if this should be opened against email-ext or setenv plugin.
http://wiki.jenkins-ci.org/display/JENKINS/Setenv+Plugin
http://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
There is not currently a setenv component in jira so I'm opening this against
email-ext.
A recent discussion of this issue:
http://n4.nabble.com/How-to-use-environment-variables-td1012822.html#a1012822
--
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-5942) setenv variables not available to email-ext
[
https://issues.jenkins-ci.org/browse/JENKINS-5942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159771#comment-159771
]
Noah Sussman edited comment on JENKINS-5942 at 3/2/12 11:06 PM:
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
Let's say my build generates a logfile called {{my_logfile}}, which is what I
want to include. What I do is cat out the file and prefix each line with the
token EMAIL:
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
was (Author: noahsussman):
Fwiw, this is the workaround I am using in order to generate text and then
email it using the Extended Email plugin. Basically I prefix certain lines of
the console log with a token, and then I use the Extended Email plugin's
BUILD_LOG_REGEX feature to filter for lines that contain that token.
Let's say my build generates a logfile called {{my_logfile}}, which is what I
want to include. What I do is cat out the log file and prefix each line with
the token EMAIL:
{noformat}
cat my_logfile | perl -lpe '$_=qq{EMAIL:\t $_}'
{noformat}
Then in Default Content field of the Extended Email plugin I can say:
{noformat}
${BUILD_LOG_REGEX, regex=EMAIL:\\t (.*), substText=$1,
showTruncatedLines=false}
{noformat}
And that results in sending an email that contains the content of {{my_logfile}}
setenv variables not available to email-ext
Key: JENKINS-5942
URL: https://issues.jenkins-ci.org/browse/JENKINS-5942
Project: Jenkins
Issue Type: Improvement
Components: email-ext
Environment: Hudson Setenv Plugin 1.1
Hudson Email Extension Plugin 2.5
hudson 1.346
Reporter: jminne
It seems like this should work after JENKINS-3605 was fixed so I followed the
documented reference format as clarified in JENKINS-2413 and JENKINS-5322
(i.e. ${ENV, var=VERSION}
I can get access to the default variables, but not ones set by setenv plugin
or by any build steps.
When this is fixed we should make sure that the recipients can be set as well
as the email content.
There are a couple of related patches out there.
http://n4.nabble.com/Email-notification-recipients-as-a-variable-td1578247.html#a1578247
Access to node env variables: JENKINS-5465
I'm not sure if this should be opened against email-ext or setenv plugin.
http://wiki.jenkins-ci.org/display/JENKINS/Setenv+Plugin
http://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin
There is not currently a setenv component in jira so I'm opening this against
email-ext.
A recent discussion of this issue:
http://n4.nabble.com/How-to-use-environment-variables-td1012822.html#a1012822
--
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-12954) Configure accurev server per Jenkins node
[ https://issues.jenkins-ci.org/browse/JENKINS-12954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=159773#comment-159773 ] pickgr1 commented on JENKINS-12954: --- I just discovered that leaving the host field empty in the plugins global configuration is possible. This allows you to use the acclient.cnf configuration on the local node (no -H in the accurev commands) It might save some others some head scratching if this is mentioned on the wiki page for the plugin. Configure accurev server per Jenkins node - Key: JENKINS-12954 URL: https://issues.jenkins-ci.org/browse/JENKINS-12954 Project: Jenkins Issue Type: New Feature Components: accurev Environment: Ubuntu 10.04.04 - Jenkins LTS Reporter: pickgr1 Assignee: Scott Tatum There may be a way to configure this already that I'm overlooking somewhere, but if not, this would be a great feature. In the Jenkins global configuration, it's possible to add multiple servers (replicas) We have replicas that are geographically diverse across a corporate WAN. For example, we have Jenkins nodes/slaves at both site A and site B. Each site also has it's own AccuRev replica. So we want nodes at site A to use their local AccuRev replica and nodes at site B use their local replica. I see that it's possible to configure this on a per-job basis, but what we really need is a per node/slave basis. Otherwise, we have to maintain separate jobs for each site. -- 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-12966) gitTool crashes Jenkins startup
Darren Weber created JENKINS-12966: -- Summary: gitTool crashes Jenkins startup Key: JENKINS-12966 URL: https://issues.jenkins-ci.org/browse/JENKINS-12966 Project: Jenkins Issue Type: Bug Components: core, git Environment: Jenkins 1.452 Red Hat Enterprise Linux Server release 6.2 (Santiago) Linux HOSTNAME 2.6.32-220.4.1.el6.x86_64 #1 SMP Thu Jan 19 14:50:54 EST 2012 x86_64 x86_64 x86_64 GNU/Linux Reporter: Darren Weber Assignee: abayer Priority: Blocker org.jvnet.hudson.reactor.ReactorException: java.lang.Error: java.lang.reflect.InvocationTargetException at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246) at jenkins.InitReactorRunner.run(InitReactorRunner.java:43) at jenkins.model.Jenkins.executeReactor(Jenkins.java:824) at jenkins.model.Jenkins.init(Jenkins.java:736) at hudson.model.Hudson.init(Hudson.java:81) at hudson.model.Hudson.init(Hudson.java:77) at hudson.WebAppMain$2.run(WebAppMain.java:217) Caused by: java.lang.Error: java.lang.reflect.InvocationTargetException at hudson.init.InitializerFinder.invoke(InitializerFinder.java:124) at hudson.init.InitializerFinder$TaskImpl.run(InitializerFinder.java:184) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$5.runTask(Jenkins.java:813) at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: 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 hudson.init.InitializerFinder.invoke(InitializerFinder.java:120) ... 8 more Caused by: java.lang.NullPointerException at hudson.plugins.git.GitTool.onLoaded(GitTool.java:74) ... 13 more -- 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
