[JIRA] (JENKINS-15667) Choice parameters not passed to P4 workspace / view
Tom Greer resolved JENKINS-15667 as Cannot Reproduce Choice parameters not passed to P4 workspace / view Rob, sorry for the miscue. I thought I ran across this last week and didn't log the bug then. Now when I try to reproduce it, I can't. So it must have been user error. I'm happy that it's working – and sorry for your trouble. Thanks again, Tom Change By: Tom Greer (31/Oct/12 3:08 AM) Status: Open Resolved Fix Version/s: current Resolution: Cannot Reproduce 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-15675) Release updated Nant plugin to support use with conditional build step plugin
Peter Loron created JENKINS-15675 Release updated Nant plugin to support use with conditional build step plugin Issue Type: Task Affects Versions: current Assignee: domi Components: conditional-buildstep, nant Created: 31/Oct/12 1:27 AM Description: Currently the Nant plugin is not an available step type when using the conditional build step plugin. There is a pending pull request (see below) that apparently fixes this issue, but it has not been released yet. https://github.com/jenkinsci/nant-plugin/pull/1 Environment: All Project: Jenkins Priority: Minor Reporter: Peter Loron 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-15667) Choice parameters not passed to P4 workspace / view
Rob Petti commented on JENKINS-15667 Choice parameters not passed to P4 workspace / view Odd, this should be working fine. Which fields does this occur in? I'm currently using a choice parameter to select a branch by referencing the value in the view spec, and it works great. 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-14102) Unstable main build leads to post steps being executed even if configured not to
Daniel Haas commented on JENKINS-14102 Unstable main build leads to post steps being executed even if configured not to I have the same as Thomas 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-15674) Choosing strategy resets randomly from 'Gerrit Trigger' to 'Default'
Vivek Ayer created JENKINS-15674 Choosing strategy resets randomly from 'Gerrit Trigger' to 'Default' Issue Type: Bug Affects Versions: current Assignee: rsandell Components: gerrit-trigger, git Created: 31/Oct/12 12:06 AM Description: Under the Git Plugin Advanced setting, I have 'Gerrit Trigger' set for choosing strategy, but occasionally, this gets reset back to Default, which doesn't default to Gerrit Trigger. This can let bad builds get through my build system because the build essentially doesn't pick up the bad changeset. Doesn't happen on all projects at the same time that have this setting enabled, just a few projects. Quite random and strange. Environment: CentOS 6.3 Project: Jenkins Priority: Major Reporter: Vivek Ayer 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-15673) InvalidClassException after modifying job matrix
Ted Aronson created JENKINS-15673 InvalidClassException after modifying job matrix Issue Type: Bug Assignee: Unassigned Components: matrix Created: 30/Oct/12 11:42 PM Description: I have a matrix configured job restricted to run on an OSX slave that launched via JNLP. Builds worked fine until I modified the matrix and removed all but one option from one of the three axes. After that, every single build fails with the following stacktrace: hudson.util.IOException2: remote file operation failed: /Users/jenkins/jenkins-slave/workspace/mindsnacks_ios_develop at hudson.remoting.Channel@5858ba4b:ms1 at hudson.FilePath.act(FilePath.java:847) at hudson.FilePath.act(FilePath.java:824) at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:978) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1134) at hudson.model.AbstractProject.checkout(AbstractProject.java:1308) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:676) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:581) at hudson.model.Run.execute(Run.java:1516) at hudson.matrix.MatrixBuild.run(MatrixBuild.java:304) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) at hudson.model.OneOffExecutor.run(OneOffExecutor.java:66) Caused by: java.io.InvalidClassException: hudson.plugins.git.util.BuildChooser; local class incompatible: stream classdesc serialVersionUID = 1, local class serialVersionUID = -798759162364037 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:560) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1946) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1870) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1752) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) at hudson.remoting.UserRequest.deserialize(UserRequest.java:182) at hudson.remoting.UserRequest.perform(UserRequest.java:98) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:680) Environment: master: Jenkins 1.488 - Ubuntu Server 10 slave: JNLP launched slave - OSX Lion Project: Jenkins
[JIRA] (JENKINS-15673) InvalidClassException after modifying job matrix
Ted Aronson updated JENKINS-15673 InvalidClassException after modifying job matrix Change By: Ted Aronson (30/Oct/12 11:42 PM) Priority: Major Critical 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-15128) Renaming job doesn't work with Git
Frédéric Camblor edited a comment on JENKINS-15128 Renaming job doesn't work with Git SCM-694 improvement should be available in Maven SCM 1.8.1 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-15128) Renaming job doesn't work with Git
Frédéric Camblor commented on JENKINS-15128 Renaming job doesn't work with Git SCM-694 improvement should be available in 1.8.1 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-13202) Artifact archiving from an ssh slave fails if symlinks are present
Jesse Glick commented on JENKINS-13202 Artifact archiving from an ssh slave fails if symlinks are present @bdellegrazie: I know of no particular process for nominating these patches for a hypothetical 1.466.3. But 1.480.1, the next planned LTS, will have both af9977c and 95c1728 applied (the former in its branch, the latter because that was committed prior to 1.480). As someone running on a relatively unusual platform (which cannot to my knowledge be easily tested by other Jenkins developers in e.g. VirtualBox), you are urged to help test the LTS release candidates: https://wiki.jenkins-ci.org/display/JENKINS/LTS+Release+Line I think 1.480.1 RC was built before af9977c was cherry-picked, so ask on the dev list before using the RC, or build your own from the stable branch. 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-15672) Cobertura unable to find report
hlau created JENKINS-15672 Cobertura unable to find report Issue Type: Bug Affects Versions: current Assignee: stephenconnolly Components: cobertura Created: 30/Oct/12 9:41 PM Description: Using jenkins 1.486, cobertura 1.7.1 12:02:04 Publishing Cobertura coverage report... 12:02:04 FATAL: Unable to find coverage results 12:02:04 hudson.util.IOException2: remote file operation failed: /hudson_analysis/workspace/pro-cobertura at hudson.remoting.Channel@14f13b8:linux-9 12:02:04 at hudson.FilePath.act(FilePath.java:847) 12:02:04 at hudson.FilePath.act(FilePath.java:824) 12:02:04 at hudson.plugins.cobertura.CoberturaPublisher.perform(CoberturaPublisher.java:335) 12:02:04 at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) 12:02:04 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:807) 12:02:04 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:782) 12:02:04 at hudson.model.Build$BuildExecution.post2(Build.java:183) 12:02:04 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:729) 12:02:04 at hudson.model.Run.execute(Run.java:1541) 12:02:04 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) 12:02:04 at hudson.model.ResourceController.execute(ResourceController.java:88) 12:02:04 at hudson.model.Executor.run(Executor.java:236) 12:02:04 Caused by: java.io.IOException: Remote call on b-linux64-09 failed 12:02:04 at hudson.remoting.Channel.call(Channel.java:673) 12:02:04 at hudson.FilePath.act(FilePath.java:840) 12:02:04 ... 11 more 12:02:04 Caused by: java.lang.NoClassDefFoundError: javax/xml/stream/XMLStreamException 12:02:04 at java.lang.Class.getDeclaredFields0(Native Method) 12:02:04 at java.lang.Class.privateGetDeclaredFields(Class.java:2259) 12:02:04 at java.lang.Class.getDeclaredField(Class.java:1852) 12:02:04 at java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1582) 12:02:04 at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52) 12:02:04 at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:408) 12:02:04 at java.security.AccessController.doPrivileged(Native Method) 12:02:04 at java.io.ObjectStreamClass.(ObjectStreamClass.java:400) 12:02:04 at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java:297) 12:02:04 at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:531) 12:02:04 at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552) 12:02:04 at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) 12:02:04 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) 12:02:04 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) 12:02:04 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) 12:02:04 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) 12:02:04 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) 12:02:04 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) 12:02:04 at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) 12:02:04 at hudson.remoting.UserRequest.deserialize(UserRequest.java:182) 12:02:04 at hudson.remoting.UserRequest.perform(UserRequest.java:98) 12:02:04 at hudson.remoting.UserRequest.perform(UserRequest.java:48) 12:02:04 at hudson.remoting.Request$2.run(Request.java:326) 12:02:04 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) 12:02:04 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269) 12:02:04 at java.util.concurrent.FutureTask.run(FutureTask.java:123) 12:02:04 at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) 12:02:04 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) 12:02:04 at java.lang.Thread.run(Threa
[JIRA] (JENKINS-15638) Xvfb 'display name offset' defaults to 0, not 1 as described, if unset
zregvart resolved JENKINS-15638 as Fixed Xvfb 'display name offset' defaults to 0, not 1 as described, if unset Fixed in version 1.0.5, thank you for reporting the issue Change By: zregvart (30/Oct/12 9:34 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-15638) Xvfb 'display name offset' defaults to 0, not 1 as described, if unset
SCM/JIRA link daemon commented on JENKINS-15638 Xvfb 'display name offset' defaults to 0, not 1 as described, if unset Code changed in jenkins User: Zoran Regvart Path: src/main/java/org/jenkinsci/plugins/xvfb/XvfbBuildWrapper.java http://jenkins-ci.org/commit/xvfb-plugin/fd33fe3d2da6690259b19126c2ba2c689b58186a Log: JENKINS-15638 Xvfb 'display name offset' defaults to 0, not 1 as described, if unset 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-12799) When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data
SCM/JIRA link daemon resolved JENKINS-12799 as Fixed When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data Change By: SCM/JIRA link daemon (30/Oct/12 8:33 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-12799) When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data
SCM/JIRA link daemon commented on JENKINS-12799 When project configuration is changed, Promoted Builds Plugin continues to use "old" configuration data Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/plugins/promoted_builds/PromotionProcess.java http://jenkins-ci.org/commit/promoted-builds-plugin/2f054ac0702768e0091a23c7a492d5bab475c1ae Log: [FIXED JENKINS-12799] Do not allow non-active promotion process to promote a build 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-13202) Artifact archiving from an ssh slave fails if symlinks are present
Brett Delle Grazie commented on JENKINS-13202 Artifact archiving from an ssh slave fails if symlinks are present @Jesse Glick and others. I can confirm that with both patches applied, 1.466.x works successfully on AIX 6.1 with IBM Java 6. Thanks very much for your help! Any chance of a LTS build with these patches applied? Or if not, can we ensure that they are included in the next LTS release 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-15671) User inside a AD group with name with "slash" can´t login or be added in admin or project member
HERLANI JUNIOR started work on JENKINS-15671 User inside a AD group with name with "slash" can´t login or be added in admin or project member Change By: HERLANI JUNIOR (30/Oct/12 7:42 PM) Status: Open In Progress 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-15671) User inside a AD group with name with "slash" can´t login or be added in admin or project member
HERLANI JUNIOR assigned JENKINS-15671 to HERLANI JUNIOR User inside a AD group with name with "slash" can´t login or be added in admin or project member Change By: HERLANI JUNIOR (30/Oct/12 7:42 PM) Assignee: HERLANI JUNIOR 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-14253) Discard Old Builds does not remove builds from Matrix-Axes
dlavelle commented on JENKINS-14253 Discard Old Builds does not remove builds from Matrix-Axes I believe we are experiencing the same issue. Discard old builds on a Matrix job deletes the build from the server but the GUI still shows it is there. If you try to click on the job you get a 404 error. Does anyone have a fix or this or an update? 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-14253) Discard Old Builds does not remove builds from Matrix-Axes
dlavelle commented on JENKINS-14253 Discard Old Builds does not remove builds from Matrix-Axes BTW we are using Jenkins 1.486 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-15671) User inside a AD group with name with "slash" can´t login or be added in admin or project member
HERLANI JUNIOR created JENKINS-15671 User inside a AD group with name with "slash" can´t login or be added in admin or project member Issue Type: Bug Affects Versions: current Assignee: Unassigned Attachments: EXCEPTION.PLUGIN.AD.txt Components: active-directory, security Created: 30/Oct/12 7:38 PM Description: Windows AD allow to create group/DN with "slash" char. If you add a DN base (user search) and the bind is done after searching the user, the exception attached is generated. During a searching to troubleshooting I´ve found that in this cases with slash is necessary add another slash or change to a backslash. I´m downloading the source code of plugin to make a test with this suggested solution. Environment: RHEL, Tomcat 6, JDK 7 Project: Jenkins Labels: plugin Priority: Minor Reporter: HERLANI JUNIOR 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-15519) BuildFlow job randomly fails with FATAL: null java.lang.NullPointerException
Scott Sandler commented on JENKINS-15519 BuildFlow job randomly fails with FATAL: null java.lang.NullPointerException I'm seeing this issue intermittently as well, same exact stack trace. 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-15670) Clearer display of completable text fields and combo boxes
Jesse Glick created JENKINS-15670 Clearer display of completable text fields and combo boxes Issue Type: Improvement Assignee: Unassigned Components: gui Created: 30/Oct/12 6:39 PM Description: textbox.jelly (when autoCompleteUrl defined) and combobox.jelly both present a text field with special behavior: you can select likely completions from your browser. Unfortunately there is no visual indication that these are anything other than plain text fields, and if you were not familiar with Jenkins and paying attention you might think that the completion popup was merely your browser’s form completion function, with no Jenkins domain information, which you would then be inclined to ignore. Also completion appears to be case-sensitive, unlike typical completion UIs, reducing the likelihood that you would even see the completion popup at all. Ought to accept case-insensitive prefixes (correcting to the true case if the completion is accepted). Project: Jenkins Priority: Minor Reporter: Jesse Glick This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9709) Feature to copy artifact from different upstream projects
Adam Hawthorne
commented on JENKINS-9709
Feature to copy artifact from different upstream projects
@Alan - the workaround doesn't quite for us. Here's our scenario:
Jobs:
BuildTrunk - builds the project files from trunk
BuildBranch1_00 - builds project files from branch 1.00
BuildBranch2_00 - builds project files from branch 2.00
PackageTrunk - packages the results of BuildTrunk
PackageBranch1_00 - packages the results of BuildBranch1_00
PackageBranch2_00 - packages the results of BuildBranch2_00
Test - Test is downstream from PackageXYZ
'Test' can run from any of the package jobs, but we create new build and package jobs for each branch. It would be helpful to us to avoid having to duplicate yet another project for each job to maintain our test configurations. What would make this easy is if I could select "Upstream project that triggered this job" in addition to "Upstream build". I see that the information is available on the build page ("Started by ..." on the individual build page). Is it possible to use that same information to implement this 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-15653) Filter changes by viewspec
Rob Petti commented on JENKINS-15653 Filter changes by viewspec I compared fstat performance on several systems across several versions of perforce (including 2012.1) and they all perform poorly compared to describe -s. This makes a lot of sense to me, since fstat needs to query several databases in order to get the information it needs, whereas describe just needs to query one or two. Performance aside, I suggested using client-side filtering because it's actually easier and quicker to implement. The filtering code is already in the plugin, and is being actively used for some features. It would be far simpler to just use that instead of writing a new parsing algorithm to handle fstat output. Just my 2c... I honestly don't mind how it's implemented as long as it doesn't break anything. 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-15669) Include a test button
kutzi resolved JENKINS-15669 as Duplicate Include a test button Change By: kutzi (30/Oct/12 5:37 PM) 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-15653) Filter changes by viewspec
Ben Golding commented on JENKINS-15653 Filter changes by viewspec Finally, just to clarify: I don't have an issue with the way data is currently pulled from Perforce. As a programmer it's natural when suggesting a new feature, to immediately start thinking about the best way to implement it 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-15666) Label.getTiedJobs ignores non-top-level jobs
dogfood commented on JENKINS-15666 Label.getTiedJobs ignores non-top-level jobs Integrated in jenkins_main_trunk #2045 [FIXED JENKINS-15666] Label.getTiedJobs ignores non-top-level jobs. (Revision 08459c328f014a97d969fa35d9d76bb8c7bc8c33) Result = UNSTABLE Jesse Glick : 08459c328f014a97d969fa35d9d76bb8c7bc8c33 Files : core/src/main/resources/hudson/views/JobColumn/column.jelly core/src/main/resources/lib/hudson/projectView.jelly core/src/main/java/hudson/model/Label.java core/src/main/resources/hudson/model/Computer/index.jelly changelog.html core/src/main/resources/hudson/model/Label/index.jelly 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-15653) Filter changes by viewspec
Ben Golding commented on JENKINS-15653 Filter changes by viewspec Server side filtering would be more efficient in many real cases, such as an integrate to create a new branch, or an automated nightly integrate between branches (we do both): i.e. when you're only interested in a few files from a big changelist. It also means you don't have to implement your own client side filter algorithm which is just duplicating Perforce's own functionality, and a potential home where new bugs can nest I don't see an advantage to the client side filtering, except that you save a few seconds and some unnecessary traffic on older servers (we use 2011.1 where I could measure no real difference). From my side, either should be acceptable in practice - but client-side seems like more work for little payback. IMHO better to spend the time adding server version detection (so you can use fstat -T and many other new features) than worry about performance with older versions. 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-15653) Filter changes by viewspec
Rob Petti commented on JENKINS-15653 Filter changes by viewspec Unfortunately, checkout processes cannot be forked into the background to run parallel with the build. All checkout operations need to be completed during the checkout phase. I assumed you were having some kind of issue with the way it currently pulls data from perforce when you brought up network efficiency... Sorry for the confusion. If it's not that big of a deal, then I'd like to just do the filtering on the client-side as it's pulling data down. As for having a separate option to control this, I don't think it's really necessary. It's perfectly reasonable for this to be the default, and most people won't even notice because they don't check in across multiple projects at the same 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-15669) Include a test button
wernight created JENKINS-15669 Include a test button Issue Type: Bug Assignee: kutzi Components: jabber Created: 30/Oct/12 4:37 PM Description: Like the email a "Send Test Message" button should be there to check it works. Project: Jenkins Priority: Major Reporter: wernight 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-13202) Artifact archiving from an ssh slave fails if symlinks are present
Jesse Glick commented on JENKINS-13202 Artifact archiving from an ssh slave fails if symlinks are present @bdellegrazie: for 1.466.x you also need to backport 95c1728. 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-15653) Filter changes by viewspec
Ben Golding commented on JENKINS-15653 Filter changes by viewspec I don't see a big time difference between fstat/describe. Each takes around 0.1 second in my tests: bash-2.05b$ time p4 -c VPOM6430_bgolding-e4310 describe -s 2448248 | wc 18095408 225392 real0m0.085s user0m0.010s sys 0m0.020s $ time p4 -c VPOM6430_bgolding-e4310 fstat -Rc -e 2448248 //... | wc 13523557 46302 real0m0.060s user0m0.000s sys 0m0.010s Anyhow I'm not really sure whether time to complete is an important metric. The fstat commands could be run in a background thread, in parallel with the actual build. Multiple commands can also be batched up with p4 -x . [Of course, either describe or fstat could benefit from such improvements] Regarding network traffic / filtering efficiency: it depends what % of the files in each changelist are mapped to the client. In the worst case, fstat has almost 300% overhead vs. describe, but with -T only ~ 2%. Regarding -s and -T switches: I assumed your plugin already queries the server version, and adjusts p4 commands appropriately. Anyhow we should not complain about inefficiency while also taking a 'lowest common denominator' approach. Bottom line: Which is faster/better comes down to many variables: p4d version; bandwidth; latency; server load/performance; size of server depot; # files in typical changelist; # files in typical client; etc. So I suggest to let the user decide whether to enable filtering or not, perhaps even in a per-client advanced setting. For me, this is a very important missing feature when doing triage of broken builds, and saves much more (human) time than a few seconds (machine time) overhead of fstat commands. 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-15666) Label.getTiedJobs ignores non-top-level jobs
SCM/JIRA link daemon commented on JENKINS-15666 Label.getTiedJobs ignores non-top-level jobs Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/model/Label.java core/src/main/resources/hudson/model/Computer/index.jelly core/src/main/resources/hudson/model/Label/index.jelly core/src/main/resources/hudson/views/JobColumn/column.jelly core/src/main/resources/lib/hudson/projectView.jelly http://jenkins-ci.org/commit/jenkins/08459c328f014a97d969fa35d9d76bb8c7bc8c33 Log: [FIXED JENKINS-15666] Label.getTiedJobs ignores non-top-level 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-15666) Label.getTiedJobs ignores non-top-level jobs
SCM/JIRA link daemon resolved JENKINS-15666 as Fixed Label.getTiedJobs ignores non-top-level jobs Change By: SCM/JIRA link daemon (30/Oct/12 4:12 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-15668) SSH passwords are retrievable from the configure nodes page.
matthew churcher
created JENKINS-15668
SSH passwords are retrievable from the configure nodes page.
Issue Type:
Bug
Affects Versions:
current
Assignee:
Kohsuke Kawaguchi
Components:
slave-setup, ssh-slaves
Created:
30/Oct/12 4:03 PM
Description:
SSH passwords are retrievable from the configure nodes page. Passwords are only masked when displayed and are retrievable from the page source. This means passwords are being leaked to all users with configure-node access which may be a security concern in some use cases. It is also a potential point of privilege escalation if an attacker is able to gain access through other means.
Steps to reproduce:
1.) Create hudson unix slave launched via SSH with password authentication.
2.) Navigate to configure node page for new job. https://jenkins/computer/{my_computer}/configure
3.) Expand advanced section of launch method
result:
Passwords are masked when displayed but viewing page source shows plain text password.
expected:
It would be safer to mask passwords server side before serving up the page.
Environment:
Found with Jenkins 1.466.1
Project:
Jenkins
Priority:
Major
Reporter:
matthew churcher
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-15653) Filter changes by viewspec
Ben Golding edited a comment on JENKINS-15653 Filter changes by viewspec I agree, linked to JENKINS-15515 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-15667) Choice parameters not passed to P4 workspace / view
Tom Greer
created JENKINS-15667
Choice parameters not passed to P4 workspace / view
Issue Type:
Bug
Affects Versions:
current
Assignee:
Unassigned
Components:
perforce
Created:
30/Oct/12 3:06 PM
Description:
[BTW, Thanks for your help and efforts with the P4 plugin. It is a fantastic tool!]
Using a parameterized build I can set a string parameter X to a string value then reference ${X} in the Perforce workspace form where it resolves at build time to the value of ${X}.
Alternately, using choice parameters (having pre-defined values) I set the value of X in the Perforce workspace form (or view) and it does not resolve the value, but rather passes it as a literal string: "${X}".
The ability to resolve choice parameters seems to be a valuable functionality to have.
Environment:
Jenkins 1.488, Perforce plugin 1.3.17, 64-bit Windows OS, JRE 1.6.0.33, Tomcat 5.5
Project:
Jenkins
Labels:
scm
plugin
Priority:
Major
Reporter:
Tom Greer
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-15653) Filter changes by viewspec
Ben Golding edited a comment on JENKINS-15653 Filter changes by viewspec - 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-15653) Filter changes by viewspec
Rob Petti commented on JENKINS-15653 Filter changes by viewspec Your comment on #3 is probably the same issue described in JENKINS-15515. rpetti@petti:~/workspace/$ time p4 describe -s 297622 | wc 5021498 47760 real 0m0.016s user 0m0.000s sys 0m0.004s rpetti@petti:~/workspace/$ time p4 fstat -Rc -e 297622 //... | wc 5447 14360 186203 real 0m1.430s user 0m0.004s sys 0m0.000s In my tests, fstat is about 100 times times slower and grossly inefficient in terms of network traffic. It's true that '-T depotFile' will reduce the amount of network traffic, but we're not able to use it because we need to support older servers. I'm not sure that using fstat is the best option here... We might need to do client-side filtering if the need is great enough. 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-15666) Label.getTiedJobs ignores non-top-level jobs
Jesse Glick created JENKINS-15666 Label.getTiedJobs ignores non-top-level jobs Issue Type: Bug Assignee: Jesse Glick Components: core Created: 30/Oct/12 2:57 PM Description: If a job is defined in a folder and tied to a slave or label then it does not show up in the “Projects tied to” report for either /computer/* or /label/*. A job with the same configuration in the root folder does show up in these reports. The reason is that Label.getTiedJobs calls Jenkins.getItems() which will ignore the contents of folders; should be using getAllItems(AbstractProject.class). (This call is potentially slow so not a great idea to call synchronously from a Jelly view; better to use ProgressiveRendering. Not as big of an issue as e.g. /asynchPeople for which builds, not just projects, are loaded.) Environment: 1.466.x, CloudBees Folders plugin Project: Jenkins Labels: labels folders Priority: Minor Reporter: Jesse Glick This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13202) Artifact archiving from an ssh slave fails if symlinks are present
Brett Delle Grazie edited a comment on JENKINS-13202 Artifact archiving from an ssh slave fails if symlinks are present @Jesse Glick and others. I've applied the patch on AIX-6.1 slave (Windows master) Running 1.466.3-SNAPSHOT (i.e. 1.466.2 patched) http://jenkins-ci.org/commit/jenkins/af9977c1b28c2e212f707ab88b4f2ac561e37e50 However the problem is still occurring. I've got a test job which simply attempts to archive dummy stuff. the result is: [test-archive-artefacts-aix] $ /bin/bash -ex /home/apps/DP/jenkins/tmp/hudson2194465448671283236.sh + mkdir -p a/b a/c dist + touch a/1.txt a/b/2.txt + ln -sf a/1.txt a/c/3.txt + /opt/freeware/bin/tar -czf dist/test.tar.gz a/ Archiving artifacts ERROR: Failed to archive artifacts: dist/*.tar.gz hudson.util.IOException2: java.lang.UnsupportedOperationException at hudson.FilePath.copyRecursiveTo(FilePath.java:1784) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1463) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: java.util.concurrent.ExecutionException: java.lang.UnsupportedOperationException at hudson.remoting.Channel$4.adapt(Channel.java:696) at hudson.remoting.Channel$4.adapt(Channel.java:691) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55) at hudson.FilePath.copyRecursiveTo(FilePath.java:1782) ... 10 more Caused by: java.lang.UnsupportedOperationException at hudson.os.PosixAPI$1.getCurrentWorkingDirectory(PosixAPI.java:59) at org.jruby.ext.posix.util.ExecIt.run(ExecIt.java:59) at org.jruby.ext.posix.util.ExecIt.runAndWait(ExecIt.java:51) at org.jruby.ext.posix.JavaLibCHelper.readlink(JavaLibCHelper.java:196) at org.jruby.ext.posix.JavaPOSIX.readlink(JavaPOSIX.java:160) at hudson.Util.resolveSymlink(Util.java:1067) at hudson.util.DirScanner$Glob.scan(DirScanner.java:121) at hudson.FilePath.writeToTar(FilePath.java:1820) at hudson.FilePath.access$1000(FilePath.java:166) at hudson.FilePath$36.invoke(FilePath.java:1761) at hudson.FilePath$36.invoke(FilePath.java:1758) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2193) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) at java.util.concurrent.FutureTask.run(FutureTask.java:149) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:736) Finished: SUCCESS Looks like its failing to find 'readlink' 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-13202) Artifact archiving from an ssh slave fails if symlinks are present
Brett Delle Grazie commented on JENKINS-13202 Artifact archiving from an ssh slave fails if symlinks are present @Jesse Glick and others. I've applied the patch on AIX-6.1 slave (Windows master) Running 1.466.3-SNAPSHOT (i.e. 1.466.2 patched) http://jenkins-ci.org/commit/jenkins/af9977c1b28c2e212f707ab88b4f2ac561e37e50 However the problem is still occurring. I've got a test job which simply attempts to archive a simple text file in the workspace (not even a symlink). the result is: [test-archive-artefacts-aix] $ /bin/bash -ex /home/apps/DP/jenkins/tmp/hudson2194465448671283236.sh + mkdir -p a/b a/c dist + touch a/1.txt a/b/2.txt + ln -sf a/1.txt a/c/3.txt + /opt/freeware/bin/tar -czf dist/test.tar.gz a/ Archiving artifacts ERROR: Failed to archive artifacts: dist/*.tar.gz hudson.util.IOException2: java.lang.UnsupportedOperationException at hudson.FilePath.copyRecursiveTo(FilePath.java:1784) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1463) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: java.util.concurrent.ExecutionException: java.lang.UnsupportedOperationException at hudson.remoting.Channel$4.adapt(Channel.java:696) at hudson.remoting.Channel$4.adapt(Channel.java:691) at hudson.remoting.FutureAdapter.get(FutureAdapter.java:55) at hudson.FilePath.copyRecursiveTo(FilePath.java:1782) ... 10 more Caused by: java.lang.UnsupportedOperationException at hudson.os.PosixAPI$1.getCurrentWorkingDirectory(PosixAPI.java:59) at org.jruby.ext.posix.util.ExecIt.run(ExecIt.java:59) at org.jruby.ext.posix.util.ExecIt.runAndWait(ExecIt.java:51) at org.jruby.ext.posix.JavaLibCHelper.readlink(JavaLibCHelper.java:196) at org.jruby.ext.posix.JavaPOSIX.readlink(JavaPOSIX.java:160) at hudson.Util.resolveSymlink(Util.java:1067) at hudson.util.DirScanner$Glob.scan(DirScanner.java:121) at hudson.FilePath.writeToTar(FilePath.java:1820) at hudson.FilePath.access$1000(FilePath.java:166) at hudson.FilePath$36.invoke(FilePath.java:1761) at hudson.FilePath$36.invoke(FilePath.java:1758) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2193) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314) at java.util.concurrent.FutureTask.run(FutureTask.java:149) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:897) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:919) at hudson.remoting.Engine$1$1.run(Engine.java:60) at java.lang.Thread.run(Thread.java:736) Finished: SUCCESS Looks like its failing to find 'readlink' 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-15439) Jenkins build records lazy-loading failed to load some of my jobs.
Ben McDonie commented on JENKINS-15439 Jenkins build records lazy-loading failed to load some of my jobs. I am running version 1.488 and am still having issues with LazyLoading. My stack trace is in JENKINS-15642. It happens near the end of Maven builds that were triggered by SCM changes. 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-14102) Unstable main build leads to post steps being executed even if configured not to
Thomas Demande commented on JENKINS-14102 Unstable main build leads to post steps being executed even if configured not to I got this in the end of the job config file: SUCCESS 0 BLUE 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-12777) Publish N'SIQ Collector is not visible for Multi configuration jobs
Jan Goyvaerts commented on JENKINS-12777 Publish N'SIQ Collector is not visible for Multi configuration jobs I can only see it for free-form projects. Nothing's visible for Maven projects. The widget to set the executable is visible however. Damn shame - there's not one decent plugin to show basic metrics at "manager" level. Running Jenkins 1.488 - x64 Linux. 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-15653) Filter changes by viewspec
Ben Golding commented on JENKINS-15653 Filter changes by viewspec #2: Can be done using 'p4 fstat' in place of 'p4 describe': p4 -c fstat -Rc -e //... will list only files mapped through the client view. [Changelist description is also included at the end] In case you want to also keep supporting an 'unfiltered' changes view, you can replace p4 describe -s by simply p4 fstat -e Further optimizations of fstat output (-> reduced network traffic). Measured using a moderate size real changelist on my Perforce: 47654 bytes 33125 bytes with -s 12676 bytes with -s -T depotFile [p4d >= 2009.1] 12676 bytes with-T depotFile [p4d >= 2009.1] [I could not find documentation of exactly when -s was added. Probably p4d < 1999] 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-15653) Filter changes by viewspec
Ben Golding commented on JENKINS-15653 Filter changes by viewspec Thanks Rob. #1: I validated this works OK in my Jenkins. #3: This seems to work OK if one or more changes occurred since the last build. In that case P4_CHANGELIST matches the most recent entry on the /changes page. However when /changes shows 'no changes since last build' I would expect P4_CHANGELIST to be the same as the previous build, but it's not the case. I think this is a 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-14102) Unstable main build leads to post steps being executed even if configured not to
Peter S commented on JENKINS-14102 Unstable main build leads to post steps being executed even if configured not to Could you check, does success exists in job's xml config 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-14825) winstone.ClientSocketException: Failed to write to client after upgrade to 1.477
hudsonfsc updated JENKINS-14825 winstone.ClientSocketException: Failed to write to client after upgrade to 1.477 Change By: hudsonfsc (30/Oct/12 12:56 PM) Description: hudsonfsc: Update for 1.486 --> see label hudsonfsc beneath. We're facing an issue since upgrading Jenkins from version 1.464 to version 1.477Immediately after start-up we start seeing the following stack-trace in the jenkins.log file: 8< Aug 15, 2012 3:09:13 PM org.kohsuke.stapler.compression.CompressionFilter reportExceptionWARNING: Untrapped servlet exceptionjavax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/u01/jenkins/home/war/WEB-INF/lib/jenkins-core-1.477.jar!/hudson/model/View/index.jelly:44:43: org.apache.commons.jelly.JellyTagException: jar:file:/u01/jenkins/home/war/WEB-INF/lib/jenkins-core-1.477.jar!/lib/hudson/buildHealth.jelly:67:80: Failed to write to client at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:625) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.sec
[JIRA] (JENKINS-14825) winstone.ClientSocketException: Failed to write to client after upgrade to 1.477
hudsonfsc updated JENKINS-14825 winstone.ClientSocketException: Failed to write to client after upgrade to 1.477 Change By: hudsonfsc (30/Oct/12 12:53 PM) Environment: Running on RHEL 5.4, Sun Java 1.6.0_16 X64. Jenkins is being run from the command line using 'java -jar jenkins.war' hudsonfsc:Running on Windows 2003 x64, Sun Java 1.6.0_35 X64 as a service. Description: We're facing an issue since upgrading Jenkins from version 1.464 to version 1.477Immediately after start-up we start seeing the following stack-trace in the jenkins.log file: 8< Aug 15, 2012 3:09:13 PM org.kohsuke.stapler.compression.CompressionFilter reportExceptionWARNING: Untrapped servlet exceptionjavax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/u01/jenkins/home/war/WEB-INF/lib/jenkins-core-1.477.jar!/hudson/model/View/index.jelly:44:43: org.apache.commons.jelly.JellyTagException: jar:file:/u01/jenkins/home/war/WEB-INF/lib/jenkins-core-1.477.jar!/lib/hudson/buildHealth.jelly:67:80: Failed to write to client at org.kohsuke.stapler.jelly.JellyClassTearOff.serveIndexJelly(JellyClassTearOff.java:112) at org.kohsuke.stapler.jelly.JellyFacet.handleIndexRequest(JellyFacet.java:127) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:563) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:625) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionCon
[JIRA] (JENKINS-15665) More Link broken
Robert Lachner created JENKINS-15665 More Link broken Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: infrastructure Created: 30/Oct/12 12:05 PM Description: Getting this Exception if i click on the "more" Link in Build Job History. Jenkins 1.486-1.488 Status Code: 500 Exception: org.apache.commons.jelly.JellyTagException: jar:file:/D:/Dienste/Tomcat7/webapps/jenkins/WEB-INF/lib/jenkins-core-1.488.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: java.lang.NullPointerException Stacktrace: javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/D:/Dienste/Tomcat7/webapps/jenkins/WEB-INF/lib/jenkins-core-1.488.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: java.lang.NullPointerException at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) Project: Jenkins Priority: Major Reporter: Robert Lachner 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-15465) RunList returning null from its elements in 1.485
Robert Lachner commented on JENKINS-15465 RunList returning null from its elements in 1.485 Error still exists in 1.488: Status Code: 500 Exception: org.apache.commons.jelly.JellyTagException: jar:file:/D:/Dienste/Tomcat7/webapps/jenkins/WEB-INF/lib/jenkins-core-1.488.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: java.lang.NullPointerException Stacktrace: javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/D:/Dienste/Tomcat7/webapps/jenkins/WEB-INF/lib/jenkins-core-1.488.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: java.lang.NullPointerException at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) 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-15664) Help text for EnvInject plugin is wrong
mwebber created JENKINS-15664 Help text for EnvInject plugin is wrong Issue Type: Bug Assignee: Gregory Boissinot Components: envinject Created: 30/Oct/12 11:47 AM Description: This is with EnvInject plugin 1.72, Jenkins 1.488. In a job configuration, "Build Environment" --> "Inject environment variables to the build process", the help text for "Properties File Path" says "the process is executed before a SCM checkout". However, when I run it, it's quite clear that this is processed AFTER the SCM checkout - which is good, since it means I can have my properties file under source control. The console shows this: [EnvInject] - Executing scripts and injecting environment variables after the SCM step. [EnvInject] - Injecting as environment variables the properties file path 'builder/hudson/env-vars-GDA-master-set1.properties' The help text needs changing so that it describes what actually happens. The same wrong help text appears when you have a "Build Step" of "Inject environment variables". Project: Jenkins Priority: Major Reporter: mwebber 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-14102) Unstable main build leads to post steps being executed even if configured not to
Thomas Demande commented on JENKINS-14102 Unstable main build leads to post steps being executed even if configured not to I'm using "Invoke top-level Maven targets" post steps. 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-14102) Unstable main build leads to post steps being executed even if configured not to
Daniel Haas commented on JENKINS-14102 Unstable main build leads to post steps being executed even if configured not to I'm executing a shell script afterwards. Actually what it is it should test first my build (maven build) and if the tests fail the script should be not executed. I put it into the Post Steps... Actually publishers is empty: There are stored postbuilders: env && ./jdeploy $Server In the jenkins web interface it is: Post Steps Run only if build succeeds Run only if build succeeds or is unstable Run regardless of build result Should the post-build steps run only for successful builds, etc. Execute shell Command env && ./jdeploy $Server This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9753) Plugins bundled with core Jenkins are old versions
mwebber closed JENKINS-9753 as Not A Defect Plugins bundled with core Jenkins are old versions Change By: mwebber (30/Oct/12 11:00 AM) Status: Open Closed Resolution: Not A Defect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15109) Stacktrace introduced in 1.481 when going to http:// /computer/(master)/api/xml
mwebber closed JENKINS-15109 as Fixed Stacktrace introduced in 1.481 when going to http:// /computer/(master)/api/xml Change By: mwebber (30/Oct/12 10:59 AM) Status: Open Closed 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-9312) Failed to instantiate class hudson.plugins.git.browser.GithubWeb
mwebber closed JENKINS-9312 as Incomplete Failed to instantiate class hudson.plugins.git.browser.GithubWeb I am no longer interest in this issue. Change By: mwebber (30/Oct/12 10:58 AM) Status: Open Closed Resolution: Incomplete 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-14825) winstone.ClientSocketException: Failed to write to client after upgrade to 1.477
hudsonfsc commented on JENKINS-14825 winstone.ClientSocketException: Failed to write to client after upgrade to 1.477 Same here on Windows Server 2003 x64 SP2 with Java 1.6.0_35, running as a service. I've upgraded from 1.480 to 1.486. When I reload the Jenkins Webpage it takes about 1min and after that I see this error every time in jenkins.err.log. 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-9195) If the slave node that a build ran on is subsequently deleted, Jenkins thinks that the build ran on "master"
mwebber closed JENKINS-9195 as Fixed If the slave node that a build ran on is subsequently deleted, Jenkins thinks that the build ran on "master" This was fixed at some point. Change By: mwebber (30/Oct/12 10:57 AM) Status: Open Closed 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-14102) Unstable main build leads to post steps being executed even if configured not to
Peter S edited a comment on JENKINS-14102 Unstable main build leads to post steps being executed even if configured not to please give more details - which post-build steps you use? or provide section content of job's xml config file 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-14102) Unstable main build leads to post steps being executed even if configured not to
Peter S commented on JENKINS-14102 Unstable main build leads to post steps being executed even if configured not to please give more details - which post builds steps you use? or provide section content of job's xml config file 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-13871) Using "Conditional build step" and "Parameterized build step" in same step is preventing parallel executions of same job
Peter S commented on JENKINS-13871 Using "Conditional build step" and "Parameterized build step" in same step is preventing parallel executions of same job You can try my fix https://github.com/jenkinsci/conditional-buildstep-plugin/pull/7 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-13871) Using "Conditional build step" and "Parameterized build step" in same step is preventing parallel executions of same job
Kevin Chiu edited a comment on JENKINS-13871 Using "Conditional build step" and "Parameterized build step" in same step is preventing parallel executions of same job Turns out the blocking I encountered is due to the post-build steps of a concurrent tasks. It seems to be a more general one on plugins that do artifcats copy/upload: JENKINS-10234 Before we are using copy artifacts back to master, now have changed to use the Publish over SSH plugin instead. Tested concurrent build couple of times and issue gone. 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-15663) disk usage plugin doesn't collect matrix configuration size on parent job
kevincai created JENKINS-15663 disk usage plugin doesn't collect matrix configuration size on parent job Issue Type: Bug Assignee: vjuranek Components: disk-usage Created: 30/Oct/12 9:26 AM Description: 1. disk-usage plugin doesn't collect size correctly for matrix job. It only shows parent job size. 2. Click any sub configuration, the disk usage data is empty in the history. Downgrade to disk-usage-0.16 works fine. Environment: Jenkins 1.466.2, disk-usage plugin 0.18 Project: Jenkins Priority: Major Reporter: kevincai 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-13871) Using "Conditional build step" and "Parameterized build step" in same step is preventing parallel executions of same job
Kevin Chiu commented on JENKINS-13871 Using "Conditional build step" and "Parameterized build step" in same step is preventing parallel executions of same job Turns out the blocking I encountered is due to the post-build steps of a concurrent tasks. It seems to be a more general one on plugins that do artifcats copy/upload: https://issues.jenkins-ci.org/browse/JENKINS-10234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel Before we are using copy artifacts back to master, now have changed to use the Publish over SSH plugin instead. Tested concurrent build couple of times and issue gone. 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-15662) Cannot add post-build action for JaCoCo
Carsten Pfeiffer created JENKINS-15662 Cannot add post-build action for JaCoCo Issue Type: Bug Affects Versions: current Assignee: Ognjen Bubalo Components: jacoco Created: 30/Oct/12 9:18 AM Description: I cannot add the JaCoCo post-build action to any job. Nothing happens when I invoke the entry in the post-build action menu of the job configuration. Also, nothing is logged when I do this. Environment: Linux, Oracle JDK 6, Jenkins 1.488 Project: Jenkins Priority: Major Reporter: Carsten Pfeiffer 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-10569) When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times
dogfood commented on JENKINS-10569 When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times Integrated in jenkins_main_trunk #2044 JENKINS-10569 changelog entry (Revision 2fd5f247c4aa1fa92f11f9be9d26cf17a27ea142) Result = SUCCESS Olivier Lamy : 2fd5f247c4aa1fa92f11f9be9d26cf17a27ea142 Files : changelog.html This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15634) Ignore aborted builds in age calculation for failing tests
Kamil Janyga closed JENKINS-15634 as Fixed Ignore aborted builds in age calculation for failing tests Change By: Kamil Janyga (30/Oct/12 9:17 AM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15634) Ignore aborted builds in age calculation for failing tests
Kamil Janyga resolved JENKINS-15634 as Fixed Ignore aborted builds in age calculation for failing tests Pull request created. Change By: Kamil Janyga (30/Oct/12 9:16 AM) Status: In Progress 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-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Andre Kelpe edited a comment on JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 We are seeing a similar issue with 1.486. WARNING: Untrapped servlet exception javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.486.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: java.lang.NullPointerException at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatch
[JIRA] (JENKINS-15533) Jobs disappearing with Jenkins 1.485 and 1.486
Andre Kelpe commented on JENKINS-15533 Jobs disappearing with Jenkins 1.485 and 1.486 We are seeing a similar issue with 1.486. WARNING: Untrapped servlet exception javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/cache/jenkins/war/WEB-INF/lib/jenkins-core-1.486.jar!/hudson/widgets/HistoryWidget/entry.jelly:39:106: java.lang.NullPointerException at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:384) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:58) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.ja
[JIRA] (JENKINS-15652) All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs
Michael Glauche edited a comment on JENKINS-15652 All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs I'm having exactly the same issue with 1.487 (running jenkins with jdk 1.6.0_27-b07, on 64bit Windows) 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-15652) All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs
Michael Glauche commented on JENKINS-15652 All executors dead with item.isStuck(): ArrayIndexOutOfBoundsException and more in logs I'm having exactly the same issue with 1.487 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-10569) When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times
dogfood commented on JENKINS-10569 When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times Integrated in jenkins_main_trunk #2043 [FIX JENKINS-10569] When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times (Revision 6c83004dc1abe65f578c29846dc04e07cecf83bc) Result = SUCCESS unknown : 6c83004dc1abe65f578c29846dc04e07cecf83bc Files : core/src/main/java/hudson/model/UpdateSite.java 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-15660) Custom findbugs detector detail description is not shown in Hudson results
Ulli Hafner resolved JENKINS-15660 as Duplicate Custom findbugs detector detail description is not shown in Hudson results Please have a look at the comments of JENKINS-1528 to make at least the short description visible. Change By: Ulli Hafner (30/Oct/12 8:10 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-15660) Custom findbugs detector detail description is not shown in Hudson results
Ulli Hafner updated JENKINS-15660 Custom findbugs detector detail description is not shown in Hudson results Change By: Ulli Hafner (30/Oct/12 7:59 AM) Issue Type: Bug Improvement Priority: Major Minor Component/s: findbugs Component/s: analysis-collector 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-15661) Jenkins-RTC auto-pull SCM problem
whu shine created JENKINS-15661 Jenkins-RTC auto-pull SCM problem Issue Type: Bug Assignee: Deluan Quintão Components: rtc Created: 30/Oct/12 7:56 AM Description: I am try to use your Jenkins-RTC plugin to my project. Looking forward to your reply and help. T try to make Jenkins pulling SCM each minute. It seems that the Jenkins-RTC plugin have problem to detect the changeset of the RTC repository automatically. But the manual trigger works well to pull the source code changeset from the RTC respository. Does anybody have the same problem? Project: Jenkins Priority: Major Reporter: whu shine 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-10569) When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times
SCM/JIRA link daemon commented on JENKINS-10569 When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times Code changed in jenkins User: Olivier Lamy Path: changelog.html http://jenkins-ci.org/commit/jenkins/2fd5f247c4aa1fa92f11f9be9d26cf17a27ea142 Log: JENKINS-10569 changelog entry 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-10569) When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times
SCM/JIRA link daemon resolved JENKINS-10569 as Fixed When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times Change By: SCM/JIRA link daemon (30/Oct/12 7:40 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-10569) When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times
SCM/JIRA link daemon commented on JENKINS-10569 When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times Code changed in jenkins User: Olivier Lamy Path: core/src/main/java/hudson/model/UpdateSite.java http://jenkins-ci.org/commit/jenkins/52f18562ab3f1f255774b13df2f3b69e8de1819e Log: Merge pull request #598 from evernat/master [FIXED JENKINS-10569] When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times Compare: https://github.com/jenkinsci/jenkins/compare/ff3cf5e1047f...52f18562ab3f 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-10569) When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times
SCM/JIRA link daemon commented on JENKINS-10569 When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times Code changed in jenkins User: unknown Path: core/src/main/java/hudson/model/UpdateSite.java http://jenkins-ci.org/commit/jenkins/6c83004dc1abe65f578c29846dc04e07cecf83bc Log: [FIX JENKINS-10569] When installing plugins with overlapping dependencies, Jenkins downloads the duplicate plugins multiple times 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-15660) Custom findbugs detector detail description is not shown in Hudson results
Jan Stolze created JENKINS-15660 Custom findbugs detector detail description is not shown in Hudson results Issue Type: Bug Affects Versions: current Assignee: Ulli Hafner Components: analysis-collector Created: 30/Oct/12 7:01 AM Description: We have developed our own FindBugs detectors which is deployed as a plugin to the findbugs framework, all work fine potential bugs are detected also by the plugin run through Hudson, but the priority and description are ignored completely. All High prio bugs are marked as low, and description is not displayed at all. The only description which is being displayed is 'No description available.' This is not true it is present in the plugin.jar file which is provided throught the messages.xml file but the Hudson FB framework seems to ignore this. Project: Jenkins Priority: Major Reporter: Jan Stolze 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
