[JIRA] (JENKINS-14092) Support job to watch and build several branches
Dalzeic Dalzeic created JENKINS-14092 Support job to watch and build several branches Issue Type: New Feature Assignee: Unassigned Components: subversion Created: 13/Jun/12 6:52 AM Description: With the Git plugin it is possible to watch for changes in several branches (matched with wildcard or regex). If a change in any of those branches happens, a build is triggered and this specific branch is checked out and built. As we cannot yet use git, but need to use subversion, we would like to have this feature supported by the subversion plugin as well. We need this as we have a team of more than 10 developers (sometimes also feature development branches for multiple developers to share) each one having his own branch. With the help of the subversion merge plugin and this feature improvement, we would set up one master branch job and a job which monitors and builds the feature/developer branches and after successfully building and testing any of these branches automatically merges the changes to the trunk. Currently this is only possible by setting up a job per branch which is pretty tedious. Changes to the job configuration must be done to all branches. As we do not just have one component but several (about 15) depending components (each one having its own build job) this gets really impossible to maintain without this feature as we would need at least 15 (components) times 1 + 10 (developers) = 161 jobs to do this. We also tried to achieve this with multi-config jobs, but it seems the subversion plugin cannot just monitor the branches specifically or checkout just the branch where modifications where detected. Project: Jenkins Priority: Major Reporter: Dalzeic Dalzeic This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14079) LDAP authentication crashes
Kiyotaka Kikuchi
updated JENKINS-14079
LDAP authentication crashes
Change By:
Kiyotaka Kikuchi
(13/Jun/12 12:40 AM)
Description:
jenkins updated to 1.478, and views just displays these message and all preset jobs not worked.{quote}org.jvnet.hudson.reactor.ReactorException: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246) at jenkins.InitReactorRunner.run(InitReactorRunner.java:43) at jenkins.model.Jenkins.executeReactor(Jenkins.java:885) at jenkins.model.Jenkins.(Jenkins.java:790) at hudson.model.Hudson.(Hudson.java:81) at hudson.model.Hudson.(Hudson.java:77) at hudson.WebAppMain$2.run(WebAppMain.java:217)Caused by: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.(LDAPSecurityRealm.java:419) at hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:369) at hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:398) at hudson.security.HudsonFilter.reset(HudsonFilter.java:134) at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:1960) at jenkins.model.Jenkins$17.run(Jenkins.java:2524) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:874) 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.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722){quote}our jenkins set to use LDAP authentication.
Sorry, my report version is incorrect.crashes: 1.468works well: 1.467thanks
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14079) LDAP authentication crashes
Kiyotaka Kikuchi
updated JENKINS-14079
LDAP authentication crashes
Change By:
Kiyotaka Kikuchi
(13/Jun/12 12:41 AM)
Description:
jenkins updated to
-
1.478
- 1.468
, and views just displays these message and all preset jobs not worked.{quote}org.jvnet.hudson.reactor.ReactorException: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246) at jenkins.InitReactorRunner.run(InitReactorRunner.java:43) at jenkins.model.Jenkins.executeReactor(Jenkins.java:885) at jenkins.model.Jenkins.(Jenkins.java:790) at hudson.model.Hudson.(Hudson.java:81) at hudson.model.Hudson.(Hudson.java:77) at hudson.WebAppMain$2.run(WebAppMain.java:217)Caused by: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.(LDAPSecurityRealm.java:419) at hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:369) at hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:398) at hudson.security.HudsonFilter.reset(HudsonFilter.java:134) at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:1960) at jenkins.model.Jenkins$17.run(Jenkins.java:2524) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:874) 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.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722){quote}our jenkins set to use LDAP authentication.Sorry, my report version is incorrect.crashes: 1.468works well: 1.467thanks
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12898) Option for Valgrind report to include each problem as a test failure
Chris Withers commented on JENKINS-12898 Option for Valgrind report to include each problem as a test failure Hi Gregory, I'm sure I emailed the code, will try and attach tomorrow... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14080) Upgrade to from Upgrade to 1.467 to 1.468 breaks entire Jenkins
Kohsuke Kawaguchi resolved JENKINS-14080 as Fixed Upgrade to from Upgrade to 1.467 to 1.468 breaks entire Jenkins This is supposed to be fixed in 1.469 take 2, but I've heard the report that the native packages of 1.469 were broken (presumably because of the failed 1.469 release.) I'll be re-releasing 1.470 from the same point as 1.469 take 2. Change By: Kohsuke Kawaguchi (12/Jun/12 9:30 PM) Status: Open Resolved Assignee: Kohsuke Kawaguchi Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14090) SCMCheckoutStrategy extension is not functional for Matrix projects
Sergey Burkov
created JENKINS-14090
SCMCheckoutStrategy extension is not functional for Matrix projects
Issue Type:
Patch
Affects Versions:
current
Assignee:
Unassigned
Components:
core
Created:
12/Jun/12 9:00 PM
Description:
Please update the MatrixConfiguration class in order to use ScmCheckoutStrategy selected in the parent MatrixProject.
Please add following code, otherwise the default SCM checkout strategy would be still used.
/**
Inherit the value from the parent.
*/
@override
public SCMCheckoutStrategy getScmCheckoutStrategy() {
return getParent().getScmCheckoutStrategy();
}
Project:
Jenkins
Labels:
extension
Priority:
Blocker
Reporter:
Sergey Burkov
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14088) Provide option to disable token macro parsing in description files
bap commented on JENKINS-14088 Provide option to disable token macro parsing in description files New (advanced) option to disable token parsing in the job config. Option in global config to set the default value for new jobs. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14088) Provide option to disable token macro parsing in description files
SCM/JIRA link daemon resolved JENKINS-14088 as Fixed Provide option to disable token macro parsing in description files Change By: SCM/JIRA link daemon (12/Jun/12 8:29 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14088) Provide option to disable token macro parsing in description files
SCM/JIRA link daemon commented on JENKINS-14088 Provide option to disable token macro parsing in description files Code changed in jenkins User: bap2000 Path: src/main/java/org/jenkinsCi/plugins/projectDescriptionSetter/DescriptionSetterWrapper.java src/main/java/org/jenkinsCi/plugins/projectDescriptionSetter/DescriptionSetterWrapperDescriptor.java src/main/resources/org/jenkinsCi/plugins/projectDescriptionSetter/DescriptionSetterWrapper/config.jelly src/main/resources/org/jenkinsCi/plugins/projectDescriptionSetter/DescriptionSetterWrapper/config.properties src/main/resources/org/jenkinsCi/plugins/projectDescriptionSetter/DescriptionSetterWrapper/global.jelly src/main/resources/org/jenkinsCi/plugins/projectDescriptionSetter/DescriptionSetterWrapper/global.properties src/main/resources/org/jenkinsCi/plugins/projectDescriptionSetter/DescriptionSetterWrapper/help-disableTokens.html src/main/resources/org/jenkinsCi/plugins/projectDescriptionSetter/DescriptionSetterWrapper/help-projectDescriptionFilename.jelly http://jenkins-ci.org/commit/project-description-setter-plugin/d021f9e62755f88ffd7d0de122ee65093f0c5db9 Log: [FIXED JENKINS-14088] add option to disable token parsing This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14089) JUnit report - Quarantine intermittent tests
John Muczynski created JENKINS-14089 JUnit report - Quarantine intermittent tests Issue Type: New Feature Affects Versions: current Assignee: Unassigned Components: junit Created: 12/Jun/12 7:35 PM Description: I see other CI systems with a Quarantine feature for their JUnit testing. How about Jenkins keeps pace? Quarantine is a reporting feature. The idea of the feature is that intermittent or misbehaving tests can be quarantined. This means that they wouldn't be reported in the totals of passing/failing tests and would not affect the pass/fail status of the Jenkins job. The tests can later be removed from quarantine when they are consistently passing or otherwise behaving well. The quarantine feature wouldn't change whether a test executes, but rather how it is reported. Project: Jenkins Priority: Major Reporter: John Muczynski This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14080) Upgrade to from Upgrade to 1.467 to 1.468 breaks entire Jenkins
Ted Wexler commented on JENKINS-14080 Upgrade to from Upgrade to 1.467 to 1.468 breaks entire Jenkins I am seeing both of the issues here, the exception in 1.468 and the inability to update to 1.469, as well. Any resolution to this? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14088) Provide option to disable token macro parsing in description files
Patrick Connolly created JENKINS-14088 Provide option to disable token macro parsing in description files Issue Type: Bug Assignee: bap Components: project-description-setter Created: 12/Jun/12 6:17 PM Description: My markdown description files have many references to environment variables with backticks around them (as it explains the jenkins job scripts themselves, which use environment variables). While I'm sure I could ask devs to escape any comments they make, it's confusing to have a build fail for something in the meta-docs. It would be great if I could just disable token macro parsing at global- or job-level. Thanks! Project: Jenkins Priority: Minor Reporter: Patrick Connolly This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14086) LDAP Error
Noel Bernardez commented on JENKINS-14086 LDAP Error Got the same error after upgrading to 1.469 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10025) Calling rebuildDependencyGraph() in cycle
eguess74 commented on JENKINS-10025 Calling rebuildDependencyGraph() in cycle Gregory, would you mind acknowledging the issue, please? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14087) ShellTrigger plugin timer issue
amargono created JENKINS-14087 ShellTrigger plugin timer issue Issue Type: Bug Assignee: Unassigned Components: plugin Created: 12/Jun/12 5:21 PM Description: We have noticed some intermittent issues with the ShellTrigger plugin build timer.The plugin version is 0.11.1. There are two issues: 1. Sometime the build timer does not work per schedule, e.g., a job was run more frequently than the scheduled run time. 2. Sometime the build timer does not work at all, e.g., there are no builds kicked off when a build supposedly to be kicked off per schedule. Environment: CentOS, jenkins ver 1.424.6 Project: Jenkins Priority: Major Reporter: amargono This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14080) Upgrade to from Upgrade to 1.467 to 1.468 breaks entire Jenkins
Bruce Edge commented on JENKINS-14080 Upgrade to from Upgrade to 1.467 to 1.468 breaks entire Jenkins I can confirm this. Also, the next rev, hopefully the fix, cannot be downloaded from the Ubuntu mirror: Get:1 http://pkg.jenkins-ci.org/debian/ binary/ jenkins 1.469 [48.7MB] Fetched 48.7MB in 1min 39s (491kB/s) Failed to fetch http://pkg.jenkins-ci.org/debian/binary/jenkins_1.469_all.deb Size mismatch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6797) Add @DataBoundConstructor
domi commented on JENKINS-6797 Add @DataBoundConstructor yes, that's right This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13904) EnvInject Plugin: option to replace invalid characters in env var names with underscores
Chris Fraser commented on JENKINS-13904 EnvInject Plugin: option to replace invalid characters in env var names with underscores I respect not wanting to bloat out a plugin with unused functionality, but I still don't fully understand why you don't want envinject to have the ability to transform the environment variable names to remove invalid characters, given that it's what's doing the env var injection. Would you recommend that this functionality be introduced in a new/separate plugin that works in tandem with envinject, or actually put into Jenkins core? Thanks again for all of your work on this plugin. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13874) java.lang.NoSuchMethodError: java/lang/String.isEmpty()Z
Thomas Fürer commented on JENKINS-13874 java.lang.NoSuchMethodError: java/lang/String.isEmpty()Z String#isEmpty() is available since java 1.6 so you need a JRE 1.6 which runs your jenkins. do you have a JRE 1.6 or greater installed and is this JRE used from jenkins? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12495) svnmerge fails when running on a Jenkins slave
Dalzeic Dalzeic commented on JENKINS-12495 svnmerge fails when running on a Jenkins slave What is the status of this issue? We also need this rebase/integration feature. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14027) Can't run build flow configuration with parralell jobs
Shailesh Ligade commented on JENKINS-14027 Can't run build flow configuration with parralell jobs The same thing happend to me, I even upgrade to latest jenkins, but its not working.. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14027) Can't run build flow configuration with parralell jobs
Shailesh Ligade edited a comment on JENKINS-14027 Can't run build flow configuration with parralell jobs The same thing happened to me, I even upgrade to latest jenkins, but its not working.. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14086) LDAP Error
Manuel created JENKINS-14086 LDAP Error Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 12/Jun/12 3:14 PM Description: org.jvnet.hudson.reactor.ReactorException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script1.groovy: 32: unable to resolve class hudson.security.LDAPSecurityRealm.AuthoritiesPopulatorImpl @ line 32, column 1. import hudson.security.LDAPSecurityRealm.AuthoritiesPopulatorImpl ^ 1 error at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246) at jenkins.InitReactorRunner.run(InitReactorRunner.java:43) at jenkins.model.Jenkins.executeReactor(Jenkins.java:885) at jenkins.model.Jenkins.(Jenkins.java:790) at hudson.model.Hudson.(Hudson.java:81) at hudson.model.Hudson.(Hudson.java:77) at hudson.WebAppMain$2.run(WebAppMain.java:217) Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script1.groovy: 32: unable to resolve class hudson.security.LDAPSecurityRealm.AuthoritiesPopulatorImpl @ line 32, column 1. import hudson.security.LDAPSecurityRealm.AuthoritiesPopulatorImpl ^ 1 error at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:302) at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:858) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:548) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731) at groovy.lang.GroovyShell.parse(GroovyShell.java:743) at groovy.lang.GroovyShell.parse(GroovyShell.java:723) at groovy.lang.GroovyShell.parse(GroovyShell.java:790) at hudson.util.spring.BeanBuilder.parse(BeanBuilder.java:133) at hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:359) at hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:398) at hudson.security.HudsonFilter.reset(HudsonFilter.java:134) at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:1960) at jenkins.model.Jenkins$17.run(Jenkins.java:2524) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:874) 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.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Project: Jenkins Labels: jenkins Priority: Blocker Reporter: Manuel This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14079) LDAP authentication crashes
James Gedarovich commented on JENKINS-14079 LDAP authentication crashes thought I would mention this is a dealbreaker for me as well. jenkins 1.469 war in tomcat6 on RHEL SEVERE: Failed to initialize Jenkins org.jvnet.hudson.reactor.ReactorException: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246) at jenkins.InitReactorRunner.run(InitReactorRunner.java:43) at jenkins.model.Jenkins.executeReactor(Jenkins.java:885) at jenkins.model.Jenkins.(Jenkins.java:790) at hudson.model.Hudson.(Hudson.java:81) at hudson.model.Hudson.(Hudson.java:77) at hudson.WebAppMain$2.run(WebAppMain.java:217) Caused by: java.lang.IllegalAccessError: tried to access method hudson.security.SecurityRealm.findBean(Ljava/lang/Class;Lorg/springframework/context/ApplicationContext;)Ljava/lang/Object; from class hudson.security.LDAPSecurityRealm$LDAPUserDetailsService at hudson.security.LDAPSecurityRealm$LDAPUserDetailsService.(LDAPSecurityRealm.java:419) at hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:369) at hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:398) at hudson.security.HudsonFilter.reset(HudsonFilter.java:134) at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:1960) at jenkins.model.Jenkins$17.run(Jenkins.java:2524) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:874) 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) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13879) Builds failing to trigger due to changelist number being set incorrectly
Rob Petti resolved JENKINS-13879 as Fixed Builds failing to trigger due to changelist number being set incorrectly Released in 1.3.15. Change By: Rob Petti (12/Jun/12 2:18 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9309) sloccount trend report only works up to last failed build
sogabe commented on JENKINS-9309 sloccount trend report only works up to last failed build @kbrandt It looks good! I'll merge and release in a short time. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14084) Throttle per axis
Thorsten Roemer created JENKINS-14084 Throttle per axis Issue Type: Improvement Affects Versions: current Assignee: abayer Components: matrix, throttle-concurrents Created: 12/Jun/12 1:15 PM Description: I've written an integration test for different OS's and different databases. Now I've created a matrix job with two axis (slaves & "database"). The slaves have multiple executors, being able to run the integration tests in parallel. But for each database there exists only one account, therefor when running the build, axis combinations using the same database must not be running in parallel. How about a (throttle-) flag in the axis definition to mark this axis not to be used in parallel? As a workaround I'm using the "Run each configuration sequentially", but it's unnecessary slow's down the build. Environment: Linux x64 Fix Versions: current Project: Jenkins Priority: Minor Reporter: Thorsten Roemer This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13007) Git plugin cannot find revision to build on Windows
Ilari Mäkimattila reopened JENKINS-13007 Git plugin cannot find revision to build on Windows The fix does not work when using Git plugin with Gerrit Trigger. I've created a fix for this and verified that git plugin still works without Gerrit. Please see https://github.com/Kryil/git-plugin/commit/3de8e933225d7cc5369193866cde6d585621a0a3 Change By: Ilari Mäkimattila (12/Jun/12 1:12 PM) Resolution: Fixed Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10571) Git Plugin crashes when remote branch gets deleted, and its commit is not available.
Lars Bilke commented on JENKINS-10571 Git Plugin crashes when remote branch gets deleted, and its commit is not available. I also have this problem with Git plugin version 1.1.19 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14070) Support max number of retries
SCM/JIRA link daemon resolved JENKINS-14070 as Fixed Support max number of retries Change By: SCM/JIRA link daemon (12/Jun/12 12:05 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14070) Support max number of retries
SCM/JIRA link daemon commented on JENKINS-14070 Support max number of retries Code changed in jenkins User: Nicolas De Loof Path: src/main/java/com/chikli/hudson/plugin/naginator/NaginatorListener.java src/main/java/com/chikli/hudson/plugin/naginator/NaginatorPublisher.java src/main/resources/com/chikli/hudson/plugin/naginator/NaginatorPublisher/config.jelly src/main/resources/com/chikli/hudson/plugin/naginator/NaginatorPublisher/help-maxSchedule.html src/main/resources/com/chikli/hudson/plugin/naginator/NaginatorPublisher/help.html src/main/resources/com/chikli/hudson/plugin/naginator/ProgressiveDelay/help.html src/main/resources/index.jelly src/test/java/com/chikli/hudson/plugin/naginator/NaginatorListenerTest.java http://jenkins-ci.org/commit/naginator-plugin/6a7ba3cf00ec2697e26e8884d88326028504be4f Log: [fixed JENKINS-14070] add limit to number of schedules (also fix tests) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14054) The "Root POM" field value in the Build section of a Maven job configuration is not being read in.
Harry Braun commented on JENKINS-14054 The "Root POM" field value in the Build section of a Maven job configuration is not being read in. We can't use the sonar-plugin and everytime we open the configuration the root pom is empty. So we think about going back to 1.465.. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13797) Unstable or failure reason is not printed in build summary
SCM/JIRA link daemon commented on JENKINS-13797 Unstable or failure reason is not printed in build summary Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/warnings/WarningsPublisher.java http://jenkins-ci.org/commit/warnings-plugin/99a1e9248417df67cb7722f5a51741320e0c43ef Log: [FIXED JENKINS-13797] Evaluate build result for each parser. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13797) Unstable or failure reason is not printed in build summary
SCM/JIRA link daemon resolved JENKINS-13797 as Fixed Unstable or failure reason is not printed in build summary Change By: SCM/JIRA link daemon (12/Jun/12 11:52 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13797) Unstable or failure reason is not printed in build summary
SCM/JIRA link daemon commented on JENKINS-13797 Unstable or failure reason is not printed in build summary Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/analysis/core/HealthAwarePublisher.java http://jenkins-ci.org/commit/analysis-core-plugin/d1f07ac388257823cb4a31a2fb02acc3c3a0271d Log: JENKINS-13797 Make build result evaluation overridable. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14056) Run Groovy scripts from files and environment variables
Geoff Cummings commented on JENKINS-14056 Run Groovy scripts from files and environment variables It sound like this change is the same as what I am currently trying to do: I would like to have a shared groovy script which could calculate environment variables. I would then like to be able to call this script from a job to set the environment variables for that job, instead of pasting the same groovy script into each job. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-3425) Work around javaws incorrectly putting quotes into the PATH environment variable
rad zaw updated JENKINS-3425 Work around javaws incorrectly putting quotes into the PATH environment variable Change By: rad zaw (12/Jun/12 11:40 AM) Issue Type: Improvement Bug This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-3425) Work around javaws incorrectly putting quotes into the PATH environment variable
rad zaw commented on JENKINS-3425 Work around javaws incorrectly putting quotes into the PATH environment variable This bug still exists ! When I try to call Windows SDK command line i got error about quotes in PATH :/ This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14076) Would like the ability to create a changelog for jobs triggered by scripttrigger
Roger Myung commented on JENKINS-14076 Would like the ability to create a changelog for jobs triggered by scripttrigger The polling log doesn't have user info, if you want to send emails. It also is not readable for users. I am referring to the changelog.xml file. Jenkins requires an implementation of ChangeLogParser and ChangeLogEntry to read the xml file. However, it does not require any specific way to create the xml file. This does not need to be done by the plugin. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14072) support Delay time
SCM/JIRA link daemon commented on JENKINS-14072 support Delay time Code changed in jenkins User: Nicolas De Loof Path: src/main/java/com/chikli/hudson/plugin/naginator/FixedDelay.java src/main/java/com/chikli/hudson/plugin/naginator/NaginatorListener.java src/main/java/com/chikli/hudson/plugin/naginator/NaginatorPublisher.java src/main/java/com/chikli/hudson/plugin/naginator/ProgressiveDelay.java src/main/java/com/chikli/hudson/plugin/naginator/ScheduleDelay.java src/main/resources/com/chikli/hudson/plugin/naginator/FixedDelay/config.jelly src/main/resources/com/chikli/hudson/plugin/naginator/NaginatorPublisher/config.jelly src/main/resources/com/chikli/hudson/plugin/naginator/ProgressiveDelay/config.jelly src/test/java/com/chikli/hudson/plugin/naginator/NaginatorListenerTest.java http://jenkins-ci.org/commit/naginator-plugin/1642c63deb692b933d1c3ea6c472abb8ccc0be2e Log: JENKINS-14072 Configurable schedule delay new extension point ScheduleDelay allows to plug alternate re-schedule strategies. ProgressiveDelay is provided for backward compatibility, FixedDelay mostly mimic the retry-failed-builds plugin. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14083) Build can't recover from broken submodule path
buckett created JENKINS-14083 Build can't recover from broken submodule path Issue Type: Bug Affects Versions: current Assignee: Nicolas De Loof Components: git Created: 12/Jun/12 11:12 AM Description: If a build gets pushed that has a broken submodule path then fixing the submodule path doesn't allow the build to start working again as the first thing the plugin tries todo is fetch changes which doesn't work. If there are submodules the plugin should fetch changes in the toplevel git project, then sync the submodule URLs, then fetch changes from the submodule URLs. Project: Jenkins Priority: Major Reporter: buckett This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7414) Git submodules support does not work with relative url path
buckett commented on JENKINS-7414 Git submodules support does not work with relative url path I'm not sure this is an issue any more as we have relative path submodules working with 1.1.18 of the git plugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6604) Possible race condition in RemoteClassLoader renders slave unusable
Stevan Radakovic updated JENKINS-6604 Possible race condition in RemoteClassLoader renders slave unusable Here's the patch for the jenkins-remoting 2.12 library which should deal with this bug. Change By: Stevan Radakovic (12/Jun/12 10:23 AM) Attachment: jenkins-6604-remoting-2.12.patch This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14082) Can't start Jenkins on Upgrade to 1.469 LDAP-related stack trace output.
Bernard McKeever created JENKINS-14082 Can't start Jenkins on Upgrade to 1.469 LDAP-related stack trace output. Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: security Created: 12/Jun/12 10:04 AM Description: The following stack trace is printed to the page when Jenkins is restarted. org.jvnet.hudson.reactor.ReactorException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script1.groovy: 32: unable to resolve class hudson.security.LDAPSecurityRealm.AuthoritiesPopulatorImpl @ line 32, column 1. import hudson.security.LDAPSecurityRealm.AuthoritiesPopulatorImpl ^ 1 error at org.jvnet.hudson.reactor.Reactor.execute(Reactor.java:246) at jenkins.InitReactorRunner.run(InitReactorRunner.java:43) at jenkins.model.Jenkins.executeReactor(Jenkins.java:885) at jenkins.model.Jenkins.(Jenkins.java:790) at hudson.model.Hudson.(Hudson.java:81) at hudson.model.Hudson.(Hudson.java:77) at hudson.WebAppMain$2.run(WebAppMain.java:217) Caused by: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: Script1.groovy: 32: unable to resolve class hudson.security.LDAPSecurityRealm.AuthoritiesPopulatorImpl @ line 32, column 1. import hudson.security.LDAPSecurityRealm.AuthoritiesPopulatorImpl ^ 1 error at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:302) at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:858) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:548) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:497) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:306) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:287) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731) at groovy.lang.GroovyShell.parse(GroovyShell.java:743) at groovy.lang.GroovyShell.parse(GroovyShell.java:723) at groovy.lang.GroovyShell.parse(GroovyShell.java:790) at hudson.util.spring.BeanBuilder.parse(BeanBuilder.java:133) at hudson.security.LDAPSecurityRealm.createSecurityComponents(LDAPSecurityRealm.java:359) at hudson.security.SecurityRealm.getSecurityComponents(SecurityRealm.java:398) at hudson.security.HudsonFilter.reset(HudsonFilter.java:134) at jenkins.model.Jenkins.setSecurityRealm(Jenkins.java:1960) at jenkins.model.Jenkins$17.run(Jenkins.java:2524) at org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) at jenkins.model.Jenkins$7.runTask(Jenkins.java:874) 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.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:679) Project: Jenkins Priority: Major Reporter: Bernard McKeever This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10937) AccuRev: show one stream at the time throws NPE with workspace
wbauer commented on JENKINS-10937 AccuRev: show one stream at the time throws NPE with workspace Happens with 1.468 as well: [myjob] $ "C:\Program Files (x86)\AccuRev\bin\accurev.exe" show -H myaccurev:5050 -fx -p mydepot wspaces This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11381) Subversion Plugin does not support Subversion 1.7
Denis Eperonnier
edited a comment on JENKINS-11381
Subversion Plugin does not support Subversion 1.7
I noticed something strange using Subversion Plugin 1.40, together with Jenkins 1.467.
Some time after the upgrade from plugin 1.39, there were some errors when trying to update a slave workspace:
org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /svn/xx/!svn/vcc/default failed
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289)
at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696)
at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289)
at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:557)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:414)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:324)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:315)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:295)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:391)
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2180)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at hudson.remoting.Engine$1$1.run(Engine.java:60)
at java.lang.Thread.run(Unknown Source)
Caused by: svn: E175002: REPORT /svn//!svn/vcc/default failed
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97)
... 34 more
no change for http://x since the previous build
So I checked svn server log, and I could see that my master node uses the latest SVNKit 1.7.4 ("SVN/1.7.4 SVNKit/1.7.4-jenkins-1 (http://svnkit.com/) t20120507_1224"), but one of my slaves is using an older version ("SVN/1.7.0 SVNKit/1.7.0-dev (http://svnkit.com/) rSNAPSHOT"), can this explain my issue?
edit: I forgot to mention, my svn server is 1.5, and working copy format is configured as 1.5
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14081) Jira is sending HTML formatted email notifications
bap created JENKINS-14081 Jira is sending HTML formatted email notifications Issue Type: Bug Assignee: Unassigned Components: infrastructure Created: 12/Jun/12 8:23 AM Description: Sometime between 22:59:17 BST and 02:47:23 BST the jira email notification have changed from text to HTML. Is there any good reason for this? I'm now required to convert the mail to text before I can read it. Project: Jenkins Priority: Major Reporter: bap This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6421) EMail-Notifiers in multi-module projects are ignored
evernat resolved JENKINS-6421 as Duplicate EMail-Notifiers in multi-module projects are ignored Indeed, this is a duplicate of JENKINS-1201 You can vote for it. Change By: evernat (12/Jun/12 8:01 AM) Status: Open Resolved Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13051) Setting branch name prevents branch from building
Eric Fleischman commented on JENKINS-13051 Setting branch name prevents branch from building +1...same bug/repro/workaround worked for me. I am seeing more reports of this in the wild fwiw. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
