[JIRA] (JENKINS-15490) Analysis parsers don't work with maven 2 jobs
Ulli Hafner commented on JENKINS-15490 Analysis parsers don't work with maven 2 jobs I don't have spare time to work on a fix right now. So it would be good if you find a workaround for your setup... 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-15588) TestLink is not getting Updated
Abhijit Valvekar created JENKINS-15588 TestLink is not getting Updated Issue Type: Bug Affects Versions: current Assignee: Bruno P. Kinoshita Attachments: expected.JPG, TestLink.JPG Components: testlink Created: 22/Oct/12 7:15 AM Description: I am using TestLink plugin for my UI Automation framework. My requirement is to update Testlink with result. By using this plugin TCs gets updated but in a half way, find the attched screenshots 1. Actual Result in TestLink 2. Expected Result in TestLink Environment: Windows Project: Jenkins Priority: Minor Reporter: Abhijit Valvekar 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-4354) Make Hudson user names case insensitive
Andreas Schilling commented on JENKINS-4354 Make Hudson user names case insensitive we're having the same issue as O H, so +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-14953) Exclusion plugin sometimes reports a resource as locked when it is not. Jobs hang as a result.
Yury Pukhalsky commented on JENKINS-14953 Exclusion plugin sometimes reports a resource as locked when it is not. Jobs hang as a result. Can you please clear the situation with the tickets? The ticket was neglected until mwebber had reassigned it to the maintainer. Heretofore i thought that specifying the plugin should be enough, the maintainers get the feed on their respective plugin bugs. Was i wrong? 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-15569) draft-published trigger doesn't work
rsandell assigned JENKINS-15569 to David Pursehouse draft-published trigger doesn't work Change By: rsandell (22/Oct/12 8:31 AM) Assignee: rsandell David Pursehouse 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-15589) build URL in failed emails is broken
robsimon created JENKINS-15589 build URL in failed emails is broken Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 22/Oct/12 8:45 AM Description: The URL of the build number (http://JENKINS/job/JOBNAME/BUILD_NR/) in the email notification of failed builds leads to Status code 404 page. However, if you remove the build number and click on the job page on the build number then this side is available and you notice that before visiting the side the link to that build number is already marked as visited. Environment: Jenkins v1.486, Windows 7 64bit Project: Jenkins Priority: Major Reporter: robsimon 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-3350) Cannot connect to plugin center behind HTTP proxy that requires authentication
Matthew O'Connell commented on JENKINS-3350 Cannot connect to plugin center behind HTTP proxy that requires authentication Yes, I look to have the same issue, we are running Jenkins as a windows service on a virtualised Win2008 server and get the following when we try to do any updates - even after supplying the proxy details in the advanced tab (we have configured proxy exactly as it is setup in IE internet options, and the username provided is the same domain user that the service runs under - this user has proxy access, surfing the web from the server works when logged in as this user): Checking internet connectivity Checking update center connectivity java.io.IOException: Authentication failure at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at hudson.model.UpdateCenter$UpdateCenterConfiguration.testConnection(UpdateCenter.java:737) at hudson.model.UpdateCenter$UpdateCenterConfiguration.checkUpdateCenter(UpdateCenter.java:586) at hudson.model.UpdateCenter$ConnectionCheckJob.run(UpdateCenter.java:884) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) 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 java.lang.Thread.run(Unknown Source) I see this issue on StackOverflow saying to supply parms to the JRE directly when starting Jenkins, but am unsure as to how we could do this with the windows service setup - in any case from the comment above, it sounds as if it should work when the service user has proxy access: http://stackoverflow.com/questions/1975564/how-can-i-get-hudson-to-update-through-proxy 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-15517) Findbugs total issue is not displaying properly
Ulli Hafner updated JENKINS-15517 Findbugs total issue is not displaying properly Change By: Ulli Hafner (22/Oct/12 8:50 AM) Priority: Major Minor 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-11344) xUnit fails to parse boost test log
Christoph Torens reopened JENKINS-11344 xUnit fails to parse boost test log Hi, i am using boost 1.45 and the latest version of xunit plugin. It seems that boost messages are still not parsed corectly if they appear out of a for example the following xml snippet produces an error, but cut/paste into a it works: [code] [code] best regards Change By: Christoph Torens (22/Oct/12 8:48 AM) 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-15589) build URL in failed emails is broken
robsimon commented on JENKINS-15589 build URL in failed emails is broken The URL seems to work when you add an question mark behind the URL like .../BUILD_NR/? . Maybe then the default URL string should include this question mark right away. 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-11344) xUnit fails to parse boost test log
Christoph Torens edited a comment on JENKINS-11344 xUnit fails to parse boost test log Hi, i am using boost 1.45 and the latest version of xunit plugin. It seems that boost messages are still not parsed corectly if they appear out of a for example the following xml snippet produces an error, but cut/paste into a it works: "unittests2/main.cpp" line="111"> "Master Test Suite"> best regards 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-15589) build URL in failed emails is broken
robsimon edited a comment on JENKINS-15589 build URL in failed emails is broken The URL only works when the job page has been visited before. Could this be related to the lazy load? 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-11344) xUnit fails to parse boost test log
Christoph Torens edited a comment on JENKINS-11344 xUnit fails to parse boost test log Hi, i am using boost 1.45 and the latest version of xunit plugin. It seems that boost messages are still not parsed correctly if they appear out of a for example the following xml snippet produces an error, but cut/paste into a it works: "unittests2/main.cpp" line="111"> "Master Test Suite"> best regards 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-14764) Videos aren't being embedded for Maven 2/3 Jobs (ie. non-freestyle)
Ross Rowe commented on JENKINS-14764 Videos aren't being embedded for Maven 2/3 Jobs (ie. non-freestyle) The behaviour outlined in JENKINS-1171 causes this issue, the current workaround is to use Freestyle projects or to access the embedded Sauce Job details via the build summary page 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-14764) Videos aren't being embedded for Maven 2/3 Jobs (ie. non-freestyle)
Ross Rowe edited a comment on JENKINS-14764 Videos aren't being embedded for Maven 2/3 Jobs (ie. non-freestyle) The behaviour outlined in JENKINS-11712 causes this issue, the current workaround is to use Freestyle projects or to access the embedded Sauce Job details via the build summary page 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-14764) Videos aren't being embedded for Maven 2/3 Jobs (ie. non-freestyle)
Ross Rowe edited a comment on JENKINS-14764 Videos aren't being embedded for Maven 2/3 Jobs (ie. non-freestyle) The behaviour outlined in JENKINS-11721 causes this issue, the current workaround is to use Freestyle projects or to access the embedded Sauce Job details via the build summary page 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-15418) Git fails to clean windows workspace with long path
Julien Carsique commented on JENKINS-15418 Git fails to clean windows workspace with long path Hi, Thanks for that interesting link. You're right and we already worked on shortening our paths. We also wrote a few scripts which automatically map the current path on a new drive letter in order to reduce the risk to encounter that ridiculous Windows issue. But anything we do is only delaying the issue. And it came back with that job. The point here is: the job is a "matrix" job so the working dir path is longer (C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS). Reducing too much the job name is an issue when you have 400 jobs. in the currently failing path, the only part we could still reduce is not very long: nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss. The deletion fails in Java File.delete() so there's no quick solution for that issue. But we could imagine some workarounds to reduce the times it's happening: Jenkins could mount the working directory on a new drive letter, Jenkins could propose to use a specific short path when on Windows (ie c:\ws\buildNumber or c:\ws\jobName\buildNumber), when failing to delete a file on Windows, the code could try to fallback on calling a delete windows command (rmdir /s /q path/to/file), ... I can't see a "clean" solution but anything that could help to shorten the path when working on windows would help... 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-15418) Fails to clean windows workspace with long path
Julien Carsique
updated JENKINS-15418
Fails to clean windows workspace with long path
Change By:
Julien Carsique
(22/Oct/12 9:30 AM)
Summary:
Git fails
Fails
to clean windows workspace with long path
Priority:
Major
Minor
Description:
I see that issue happening on long paths. A workaround was to use drive mapping in order to reduce the length but it doesn't solve the issue and we came to the limit of path shortening possibilities.Here's a stacktrace from a Matrix job:https://qa.nuxeo.org/jenkins/job/nuxeo-master-fullbuild-part2-distribution-multios/218/Slave=MULTIDB_WINDOWS{code}08:59:26 Building remotely on tweedledum in workspace C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS08:59:26 Checkout:MULTIDB_WINDOWS / C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS - hudson.remoting.Channel@4a58a509:tweedledum08:59:26 Using strategy: Default08:59:26 Last Built Revision: Revision 3676821964588c85aa8b71e288c743c24edd00a3 (origin/master)08:59:27 Cloning the remote Git repository08:59:27 Cloning repository git://github.com/nuxeo/nuxeo-distribution.git08:59:27 git --version08:59:27 git version 1.7.6.msysgit.008:59:27 ERROR: Failed to clean the workspace08:59:27 java.io.IOException: Unable to delete C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS\nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss\server\default\deploy\jbossws.sar\jbossws-management.war\META-INF\maven\org.jboss.ws.native\jbossws-native-management - files in dir: [C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS\nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss\server\default\deploy\jbossws.sar\jbossws-management.war\META-INF\maven\org.jboss.ws.native\jbossws-native-management\pom.properties, C:\Jenkins\workspace\nuxeo-master-fullbuild-part2-distribution-multios\Slave\MULTIDB_WINDOWS\nuxeo-distribution-jboss\target\nuxeo-cap-5.7-SNAPSHOT-jboss\server\default\deploy\jbossws.sar\jbossws-management.war\META-INF\maven\org.jboss.ws.native\jbossws-native-management\pom.xml]08:59:27 at hudson.Util.deleteFile(Util.java:238)08:59:27 at hudson.Util.deleteRecursive(Util.java:289)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.Util.deleteContentsRecursive(Util.java:200)08:59:27 at hudson.Util.deleteRecursive(Util.java:280)08:59:27 at hudson.FilePath$11.invoke(FilePath.java:910)08:59:27 at hudson.FilePath$11.invoke(FilePath.java:908)08:59:27 at hudson.FilePath.act(FilePath.java:842)08:59:27 at hudson.FilePath.act(FilePath.java:824)08:59:27 at hudson.FilePath.deleteRecursive(FilePath.java:908)08:59:27 at hudson.plugins.git.GitAPI.clone(GitAPI.java:239)08:59:27 at hudso
[JIRA] (JENKINS-15418) Fails to clean windows workspace with long path
onemanbucket commented on JENKINS-15418 Fails to clean windows workspace with long path We're also running into the windows MAX_PATH problem. I tried calling File.delete with the unicode prefix (\\?\C:\...) but it didn't work. 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-15419) TAP published results hide JUnit published results
Tim Mason commented on JENKINS-15419 TAP published results hide JUnit published results Hi Bruno, thanks for the fix 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-15045) Support Github commit status API
SCM/JIRA link daemon commented on JENKINS-15045 Support Github commit status API Code changed in jenkins User: Nicolas De Loof Path: pom.xml src/main/java/com/cloudbees/jenkins/GitHubCommitNotifier.java http://jenkins-ci.org/commit/github-plugin/1919a272a244043c5ca5cd0f7e6ed300b3e55c8f Log: JENKINS-15045 use github commit status API 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-15045) Support Github commit status API
Nicolas De Loof commented on JENKINS-15045 Support Github commit status API Created an experimental notifier to use this API : https://github.com/jenkinsci/github-plugin/tree/commit-status-api Status only get's displayed on github UI when commit is part of a pull request, so there is no benefits for github plugin ghprb-plugin may use it to set status in replacement for comments 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-15382) Memory exhaustion parsing large test stdio from Surefire
SCM/JIRA link daemon commented on JENKINS-15382 Memory exhaustion parsing large test stdio from Surefire Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/hudson/tasks/junit/CaseResult.java core/src/main/java/hudson/tasks/junit/SuiteResult.java http://jenkins-ci.org/commit/jenkins/4acc879bf56dc727838086c8c93816ad69222552 Log: [FIXED JENKINS-15382] Memory exhaustion parsing large test stdio from Surefire.(cherry picked from commit fe934aac007a20c43e803de61ef8b6cf28c4434f) Conflicts: 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-15418) Fails to clean windows workspace with long path
onemanbucket commented on JENKINS-15418 Fails to clean windows workspace with long path I have a fix for the issue, but it needs review. The two main issues are: 1) safe guard that the pivot point in the path is in the workspace so we don't delete too much 2) should the code go in deleteRecursive What it does is move the subtree close to the MAX_PATH limit to a temp directory and try to delete from there. Commit at: https://github.com/onemanbucket/jenkins/commit/0ab18187eb60dd89cf5759eb231c326cb31c866b 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-9913) Concurrent builds getting batched/nodes not getting released when jobs are completed
Sergey Smirnov commented on JENKINS-9913 Concurrent builds getting batched/nodes not getting released when jobs are completed Created:08/Jun/11 9:43 PM date Mon Oct 22 16:15:51 MSK 2012 Resolution: Unresolved 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-15590) Publisher should have an option to always run even if the build failed
chanti vlad created JENKINS-15590 Publisher should have an option to always run even if the build failed Issue Type: New Feature Affects Versions: current Assignee: bap Components: publish-over-ssh Created: 22/Oct/12 1:11 PM Description: In the Publisher Advanced Option, there shall be a checkbox to allow the publisher to run even if the build was unsuccessful. Project: Jenkins Priority: Critical Reporter: chanti vlad 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-15591) Clearcase plugin (greater than 1.3.5) doesn't display activity chain in change log.
Yakov Shossel created JENKINS-15591 Clearcase plugin (greater than 1.3.5) doesn't display activity chain in change log. Issue Type: Bug Affects Versions: current Assignee: Vincent Latombe Attachments: activity_chain.patch Components: clearcase Created: 22/Oct/12 1:15 PM Description: Activity chain was extracted correctly in clearcase plugin 1.3.5 In all subsequent releases this feature doesn't work. I found that in changelog.xml the "" section is not written at all. Attached fix-patch for 1.3.10.1 Environment: OS - Linux/Windows Project: Jenkins Labels: scm plugin Priority: Minor Reporter: Yakov Shossel 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-15590) Publisher should have an option to always run even if the build failed
bap closed JENKINS-15590 as Won't Fix Publisher should have an option to always run even if the build failed Change By: bap (22/Oct/12 2:26 PM) 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-15590) Publisher should have an option to always run even if the build failed
bap resolved JENKINS-15590 as Won't Fix Publisher should have an option to always run even if the build failed Use "Send files or execute commands over SSH after the build runs" https://wiki.jenkins-ci.org/display/JENKINS/Publish+Over+SSH+Plugin#PublishOverSSHPlugin-wrappers Change By: bap (22/Oct/12 2:25 PM) Status: Open Resolved Resolution: Won't Fix 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-14693) Conditional BuildStep Fails Build with NullPointerException
bap closed JENKINS-14693 as Cannot Reproduce Conditional BuildStep Fails Build with NullPointerException Change By: bap (22/Oct/12 2:27 PM) 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-13831) Need a way to copy empty directories with Publish Over SSH Plugin
bap closed JENKINS-13831 as Fixed Need a way to copy empty directories with Publish Over SSH Plugin Change By: bap (22/Oct/12 2:29 PM) 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-13126) Create empty directories on remote server
bap closed JENKINS-13126 as Fixed Create empty directories on remote server Change By: bap (22/Oct/12 2:29 PM) 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-13230) Not able to use Jenkins Environment Variables and variables injected through Env Inject plugin when executing commands over ssh in Publish over SSH plugin
bap commented on JENKINS-13230 Not able to use Jenkins Environment Variables and variables injected through Env Inject plugin when executing commands over ssh in Publish over SSH plugin IMO this is a fundamental design problem Without EnvInject, the build environment can be accessed directly. If someone installs EnvInject then it "hijacks" the environment variables and moves them to its own action - they are no longer available directly from the build object. This requires every plugin to code for the existence of an optional plugin if it wants to be able to access the environment variables that the EnvInject plugin has moved. @gbois is there some method in core that can be called to access the variables that EnvInject would contribute to so that this dependency can be broken? 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-15499) HistoryWidget/entry.jelly throws NullPointerException
Noam Tamim commented on JENKINS-15499 HistoryWidget/entry.jelly throws NullPointerException Is there a workaround? Anything? Even a CGI script that directly parses the build history files is ok. 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-14188) shiningpanda python plugin doesn't allow choosing name of python executable
Michael van Tellingen commented on JENKINS-14188 shiningpanda python plugin doesn't allow choosing name of python executable We have the same issue. We install python versions on CentOS via the recommended 'make altinstall' method. Thus the pythonhome for these versions is /usr/local but there is no python, only python2.6 python2.7 etc 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-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
cjo9900 commented on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Which version of jenkins/ parameterized trigger are you using? How is Job A configured? Is the parameterized trigger done as a post build trigger? Are the git hashes parameters passed using "Pass-Through Git commit that was built" Parameters? If the answers to above are both yes, then the issue seems to be that the action RevisionParameterAction[1] that the git-plugin is providing via the GitRevisionBuildParameters[2] class does not support the QueueAction[3] interface that would allow the Queue class to add separate builds for the different revisions. Alternatively the issue is that the RevisionParameterAction[1] does not implement the FoldableAction[4] interface, that would allow the multiple revisions to be merged together so only the latest revision is passed to the next build, as shown in the Queue Class[5]. In most use cases the behaviour would want to be trigger the downstream job for every commit Job A built. In a smaller number of cases there might be the need for the downstream job to run only for the latest commit in Job A, (not sure how that would work if Job A worked on multiple branches). [1] https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/RevisionParameterAction.java [2] https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitRevisionBuildParameters.java [3] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Queue.java#L1467 [4] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/queue/FoldableAction.java [5] https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/Queue.java#L526 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-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
cjo9900 assigned JENKINS-15160 to cjo9900 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Change By: cjo9900 (22/Oct/12 2:54 PM) Assignee: huybrechts cjo9900 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-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
cjo9900 updated JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Change By: cjo9900 (22/Oct/12 2:55 PM) Component/s: git 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-15592) Endless loop in hudson.model.Job.getLastFailedBuild
Marcus Klein created JENKINS-15592 Endless loop in hudson.model.Job.getLastFailedBuild Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 22/Oct/12 3:01 PM Description: The link for the lastStable build of a job pointed to a not anymore existing build. I don't know what caused this misleading link. But this misleading link caused an endless loop in Jenkins: "Handling GET / : RequestHandlerThread15" daemon prio=10 tid=0x444fb800 nid=0x13bf runnable [0x7fa3eafea000] java.lang.Thread.State: RUNNABLE at hudson.model.Job.getLastFailedBuild(Job.java:780) at sun.reflect.GeneratedMethodAccessor151.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) at org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.IncludeTag.doTag(IncludeTag.java:146) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$1.run(CoreTagLibrary.java:98) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.kohsuke.stapler.jelly.groovy.JellyBuilder.doInvokeMethod(JellyBuilder.java:283) at org.kohsuke.stapler.jelly.groovy.Namespace$ProxyImpl.invoke(Namespace.java:92) at $Proxy36.projectView(Unknown Source) at lib.JenkinsTagLib$projectView.call(Unkno
[JIRA] (JENKINS-15592) Endless loop in hudson.model.Job.getLastFailedBuild
Marcus Klein commented on JENKINS-15592 Endless loop in hudson.model.Job.getLastFailedBuild Jenkins should ignore the misleading link and create the link newly after a new stable build was done. Or it should even delete the misleading link. 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-15592) Endless loop in hudson.model.Job.getLastFailedBuild
Marcus Klein
commented on JENKINS-15592
Endless loop in hudson.model.Job.getLastFailedBuild
I found the broken links using this command:
find . -type l -exec file {} \; | grep broken
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-13032) Updating cvs plugin to version 2.0 causes "java.lang.RuntimeException: CVS authentication failure while running rlog command"
Joël Royer commented on JENKINS-13032 Updating cvs plugin to version 2.0 causes "java.lang.RuntimeException: CVS authentication failure while running rlog command" The bug re-occurs today. I joined a zip file which contains thread dumps before and after server reboot. 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-13032) Updating cvs plugin to version 2.0 causes "java.lang.RuntimeException: CVS authentication failure while running rlog command"
Joël Royer updated JENKINS-13032 Updating cvs plugin to version 2.0 causes "java.lang.RuntimeException: CVS authentication failure while running rlog command" The bug re-occurs today. Here is a zip file which contains thread dumps: 1 before restart and 1 after restart Change By: Joël Royer (22/Oct/12 3:22 PM) Attachment: threadDumps.zip 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-13032) Updating cvs plugin to version 2.0 causes "java.lang.RuntimeException: CVS authentication failure while running rlog command"
Joël Royer edited a comment on JENKINS-13032 Updating cvs plugin to version 2.0 causes "java.lang.RuntimeException: CVS authentication failure while running rlog command" The bug re-occurs today. Here is a zip file which contains thread dumps: 1 before restart and 1 after restart 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-13032) Updating cvs plugin to version 2.0 causes "java.lang.RuntimeException: CVS authentication failure while running rlog command"
Joël Royer edited a comment on JENKINS-13032 Updating cvs plugin to version 2.0 causes "java.lang.RuntimeException: CVS authentication failure while running rlog command" The bug re-occurs today. Here is a zip file which contains thread dumps: 1 before restart and 1 after restart Seems to have a problem joining the zip file. How can I send you this 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-15593) Both DryPublisher and PmdPublisher abort due to exception
Bob Ballantyne created JENKINS-15593 Both DryPublisher and PmdPublisher abort due to exception Issue Type: Bug Affects Versions: current Assignee: Unassigned Attachments: System_Info.pdf Components: analysis-collector, analysis-core, dry, pmd Created: 22/Oct/12 3:31 PM Description: I am running Jenkins 1.486 on an OpenSUSE linux with various plugins (see attached System_Info.pdf for full list). I have 2 Windows slaves attached on which I run FLEX build/analysis/unit-test/flexcover. For the static analysis, I use FlexPMD which produces pmd.xml and cpd.xml files. Whenever I try to publish either of these files, I get an exception with basically the same stack trace in either case. It does not matter if I use one, or the other (or both), I get a build failure because of the exception. When I do not use either, the build is successful. I am using the DRY (v2.33) publisher and PMD (v3.33) publisher plugins, with the analysis-collector (v1.34) and analysis-core (v1.48). The DRY publisher plugin gives the following error [DRY] Collecting duplicate code analysis files... ERROR: Publisher hudson.plugins.dry.DryPublisher aborted due to exception The PMD publisher plugin gives the following error [PMD] Collecting PMD analysis files... ERROR: Publisher hudson.plugins.pmd.PmdPublisher aborted due to exception The following stack trace follows either error: [DRY] Collecting duplicate code analysis files... ERROR: Publisher hudson.plugins.dry.DryPublisher aborted due to exception [PMD] Collecting PMD analysis files... ERROR: Publisher hudson.plugins.pmd.PmdPublisher aborted due to exception hudson.util.IOException2: remote file operation failed: d:\views\jenkins\workspace\KH_._efx at hudson.remoting.Channel@512c512c:Slave Windows-HW-10.X.Y.Z at hudson.FilePath.act(FilePath.java:847) at hudson.FilePath.act(FilePath.java:824) at hudson.plugins.pmd.PmdPublisher.perform(PmdPublisher.java:139) at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:144) at hudson.plugins.analysis.core.HealthAwareRecorder.perform(HealthAwareRecorder.java:329) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:807) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:782) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:729) at hudson.model.Run.execute(Run.java:1541) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: java.io.IOException: Remote call on Slave Windows-HW-10.244.160.82 failed at hudson.remoting.Channel.call(Channel.java:673) at hudson.FilePath.act(FilePath.java:840) ... 13 more Caused by: javax.xml.parsers.FactoryConfigurationError: Provider org.apache.xerces.jaxp.SAXParserFactoryImpl not found at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) at org.apache.commons.digester.Digester.getFactory(Digester.java:490) at org.apache.commons.digester.Digester.getParser(Digester.java:693) at org.apache.commons.digester.Digester.getXMLReader(Digester.java:899) at org.apache.commons.digester.Digester.parse(Digester.java:1666) at hudson.plugins.pmd.parser.PmdParser.parse(PmdParser.java:70) at hudson.plugins.analysis.core.AbstractAnnotationParser.parse(AbstractAnnotationParser.java:53) at hudson.plugins.analysis.core.FilesParser.parseFile(FilesParser.java:261) at hudson.plugins.analysis.core.FilesParser.parseFiles(FilesParser.java:220) at hudson.plugins.analysis.core.FilesParser.invoke(FilesParser.java:169) at hudson.plugins.analysis.core.FilesParser.invoke(FilesParser.java:31) at hudson.FilePath$FileCallableWrappe
[JIRA] (JENKINS-15590) Publisher should have an option to always run even if the build failed
chanti vlad commented on JENKINS-15590 Publisher should have an option to always run even if the build failed Thanks. This feature was well hidden 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-15117) env Variables can not be resolved in "predefined parameters" textfield
cjo9900
commented on JENKINS-15117
env Variables can not be resolved in "predefined parameters" textfield
looks like the issue is fixed in commit
https://github.com/jenkinsci/parameterized-trigger-plugin/commit/16586248c382ef417e0aaa1d2cdb00baee87ec18
for inclusion into version 2.17.
Note you need to specify the predefined parameters using the myJobName=$JOB_NAME instead of the windows %JOB_NAME% style, as mentioned in the help "Current build parameters and/or environment variables can be used in form: ${PARAM} or $PARAM."
You can test using the built version at https://jenkins.ci.cloudbees.com/job/plugins/job/parameterized-trigger-plugin/1/org.jenkins-ci.plugins$parameterized-trigger/
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-15117) env Variables can not be resolved in "predefined parameters" textfield
cjo9900 commented on JENKINS-15117 env Variables can not be resolved in "predefined parameters" textfield @Stein Welberg if you want to use variables that are set in a shell, you will need to add them to the Jenkins build Environment first, otherwise they will only be available for the life of that shell session (buildstep). You can do this by writing them to a properties file (KEY=VALUE format) in the workspace and then using the EnvInject plugin[1] to add them from that as the next build step, which will make the variables available from that point on. [1] https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+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-15594) CopyArtifact plugin cannot always copy artifacts
Jason Swager created JENKINS-15594 CopyArtifact plugin cannot always copy artifacts Issue Type: Bug Assignee: Unassigned Components: copyartifact, core Created: 22/Oct/12 4:26 PM Description: Several of our jobs will intermittently fail. Examination of the logs show the same problem: (SAMPLE) 08:55:39 Unable to find a build for artifact copy from: BUILD_WINDOWS_ALL 08:55:39 Build step 'Copy artifacts from another project' marked build as failure That's all that is in the console. We haven't upgraded to CopyArtifact v1.24 (the only fix was for Jenkins master running on Unix, which we are not). The problem is highly intermittent. We've gone for days without having the problem, then get numerous occurrences (perhaps 20 out of 200 similar jobs being run). These problems begin after the the job lazy-load was introduced into Jenkins core. Given the nature of the failures and the environment at the time of the failures, it may be a locking/race problem with several jobs all trying to access the same artifacts from the same source build at the same time. If there anything else that I can provide to resolve this issue. Environment: Jenkins Windows 1.486. CopyArtifact v1.23 Project: Jenkins Priority: Critical Reporter: Jason Swager 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-15594) CopyArtifact plugin cannot always copy artifacts
Jason Swager commented on JENKINS-15594 CopyArtifact plugin cannot always copy artifacts Some additional information: I've confirmed that when the failure occurs, the source job/build of the artifacts DOES exist. I just had some jobs run where 20 jobs all referenced the same job/build to download artifacts from; 5 worked and got the artifacts, the other 15 failed to download any artifacts and eventually failed due to the missing files. 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-15500) Null pointer exception getting envVars of 1st time promotion
Brett Biba commented on JENKINS-15500 Null pointer exception getting envVars of 1st time promotion Any update here? 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-12708) Null pointer execption in buildEnvVars
Brett Biba commented on JENKINS-12708 Null pointer execption in buildEnvVars What was the solution here? I am seeing a similar issue. 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-15418) Fails to clean windows workspace with long path
Julien Carsique commented on JENKINS-15418 Fails to clean windows workspace with long path Interesting solution. I commented your commit with my tests results: https://github.com/onemanbucket/jenkins/commit/0ab18187eb60dd89cf5759eb231c326cb31c866b#commitcomment-2033773 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-14336) Too many open files upon HTTP listener init or shutdown
Jason Stanley commented on JENKINS-14336 Too many open files upon HTTP listener init or shutdown Also on 1.482 running on CentOS release 5.8 Oct 22, 2012 12:07:23 PM winstone.Logger logInternal SEVERE: Error during HTTP listener init or shutdown java.net.SocketException: Too many open files at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375) at java.net.ServerSocket.implAccept(ServerSocket.java:470) at java.net.ServerSocket.accept(ServerSocket.java:438) at winstone.HttpListener.run(HttpListener.java:136) at java.lang.Thread.run(Thread.java:679) Oct 22, 2012 12:42:40 PM hudson.model.Run execute 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-14550) "Checksum mismatch while updating" with Subversion Plugin 1.42
john broome commented on JENKINS-14550 "Checksum mismatch while updating" with Subversion Plugin 1.42 I'm experiencing this issue with version 1.43 of the subversion plugin on Jenkins 1.466.2: svn: E155017: Checksum mismatch while updating '/opt/hudson/data/jobs//workspace/test/cucumber/.svn/text-base/job.feature.svn-base'; expected: '1e29e62bb3d127678d36ea0d24594bc9', actual: '0bb53e0a9560a2dc6abd225e2771297d' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:675) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:298) 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-15595) XmlPullParserException when reading corrupted fingerprint file.
Andrew Kujtan created JENKINS-15595 XmlPullParserException when reading corrupted fingerprint file. Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: copyartifact, fingerprint Created: 22/Oct/12 6:33 PM Description: After a power failure a bunch of fingerprint files were corrupted and were just filled with 5kb of null chars. This caused any build that ran after to fail on the copyartifacts task. It should probably be made to handle parse exceptions. As I understand it there is a fingerprint cleanup thread that runs periodically, can it be triggered manually? and will it remove fingerprint files that can't be parsed? To fix the below error I just deleted all the corrupted files. ERROR: Failed to copy artifacts from Workspace Processor with filter: install/** hudson.util.IOException2: Failed to copy D:\jenkins\jobs\Workspace Processor\builds\2012-10-22_07-43-43\archive\install\Proxy\build.xml to D:\jenkins\jobs\Common\workspace\install\Proxy\build.xml at hudson.plugins.copyartifact.FingerprintingCopyMethod.copyOne(FingerprintingCopyMethod.java:97) at hudson.plugins.copyartifact.FingerprintingCopyMethod.copyAll(FingerprintingCopyMethod.java:64) at hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:243) at hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:215) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:807) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:589) at hudson.model.Run.execute(Run.java:1516) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.util.IOException2: Unable to read D:\jenkins\fingerprints\0a\f0\9d4fd69dbb48671e2b504323d9b8.xml at hudson.XmlFile.read(XmlFile.java:139) at hudson.model.Fingerprint.load(Fingerprint.java:910) at hudson.model.Fingerprint.load(Fingerprint.java:898) at hudson.model.FingerprintMap.load(FingerprintMap.java:94) at hudson.model.FingerprintMap.load(FingerprintMap.java:45) at hudson.util.KeyedDataStorage.get(KeyedDataStorage.java:154) at hudson.model.FingerprintMap.get(FingerprintMap.java:79) at hudson.model.FingerprintMap.get(FingerprintMap.java:45) at hudson.util.KeyedDataStorage.getOrCreate(KeyedDataStorage.java:108) at hudson.model.FingerprintMap.getOrCreate(FingerprintMap.java:65) at hudson.plugins.copyartifact.FingerprintingCopyMethod.copyOne(FingerprintingCopyMethod.java:90) ... 12 more Caused by: com.thoughtworks.xstream.io.StreamException: : only whitespace content allowed before start tag and not \u0 (position: START_DOCUMENT seen \u0... @1:1) at com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.java:78) at com.thoughtworks.xstream.io.xml.AbstractPullReader.readRealEvent(AbstractPullReader.java:154) at com.thoughtworks.xstream.io.xml.AbstractPullReader.readEvent(AbstractPullReader.java:147) at com.thoughtworks.xstream.io.xml.AbstractPullReader.move(AbstractPullReader.java:126) at com.thoughtworks.xstream.io.xml.AbstractPullReader.moveDown(AbstractPullReader.java:111) at com.thoughtworks.xstream.io.xml.XppReader.(XppReader.java:48) at com.thoughtworks.xstream.io.xml.XppDriver.createReader(XppDriver.java:44) at com.thoughtworks.xstream.io.xml.XppDriver.createReader(XppDriver.java:49) at com.thoughtworks.xstream.XStream.fromXML(XStream.java:864) at hudson.XmlFile.read(XmlFile.java:137) ... 22 more Caused by: org.xmlpull.v1.XmlPullParserException: only whitespace content allowed before start tag and not \u0 (position: START_DOCUMENT seen \u0... @1:1) at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1519) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395) at org.xmlpull.mxp1.MXParser.next(MXParser.java:109
[JIRA] (JENKINS-15596) Jenkins will not start as a Windows Service after KB2661254
Richard Koretke created JENKINS-15596 Jenkins will not start as a Windows Service after KB2661254 Issue Type: Bug Assignee: wolfs Components: all-changes Created: 22/Oct/12 7:16 PM Description: Jenkins will no longer start as a Windows Service after windows patch KB2661254 is installed. When trying to the start Jenkins as a service, the following error is received "Error 1053: The service did not respond to the start or control request in a timely fashion.". No logging is captured in any of the Jenkins logs and the Windows Event screen shows the same error as listed above. Due Date: 31/Dec/12 12:00 AM Environment: Windows Server 2008 R2, JDK 1.6.0_35, Jenkins 486 installed Project: Jenkins Priority: Major Reporter: Richard Koretke 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-14028) Embedding .mobileprovision for IPA build doesn't work XCode 4.2 (4C199)
Joe Hainline commented on JENKINS-14028 Embedding .mobileprovision for IPA build doesn't work XCode 4.2 (4C199) This bug is still a problem in the latest version of XCode (4.5.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-14028) Embedding .mobileprovision for IPA build doesn't work XCode 4.2 (4C199)
Joe Hainline commented on JENKINS-14028 Embedding .mobileprovision for IPA build doesn't work XCode 4.2 (4C199) This has been fixed in my fork of the plugin here: https://github.com/josephhainline/xcode-plugin If you clone this fork, the readme describes how to install it into Jenkins. The pull request to get this into the main repo is here: https://github.com/jenkinsci/xcode-plugin/pull/15 Upvote this if you're interested in this fix. Thanks! 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-15562) Support setting the client version
johno commented on JENKINS-15562 Support setting the client version Created pull request for this @ https://github.com/jenkinsci/ircbot-plugin/pull/3 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-15562) Support setting the client version
johno updated JENKINS-15562 Support setting the client version Change By: johno (22/Oct/12 8:28 PM) Issue Type: Improvement 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-7376) git - clean before build does not clean submodules
SCM/JIRA link daemon commented on JENKINS-7376 git - clean before build does not clean submodules Code changed in jenkins User: Nicolas De loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/cb2e9c911b597b205a78e67f3c7cb624236cf5f3 Log: Merge pull request #105 from rzwierz/master Fix for JENKINS-7376 Compare: https://github.com/jenkinsci/git-plugin/compare/eecf24474587...cb2e9c911b59 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-7376) git - clean before build does not clean submodules
SCM/JIRA link daemon commented on JENKINS-7376 git - clean before build does not clean submodules Code changed in jenkins User: Rafal Zwierz Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/abe5ceb1a045655d1df2177347babc5f4f6ff3c7 Log: JENKINS-7376 Clean submodules whenever cleaning superproject (after checkout), unless submodules are disabled 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-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
hlau commented on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times I have experienced this issue in various versions of jenkins and parameterized trigger plugin. I have been upgrading both in the far chance that it might have been fixed from work on other bugs for the plugin. I am now using the latest versions: 1.486 for jenkins and 3.16 for parameterized trigger plugin and I'm still seeing the problem. Indeed Job A triggers job B through the post build parameterized trigger plugin using Pass-through Git commit that was built. This is one example of the problem that I saw as recent as in the last hour: Job B was triggered by both #414 and #415 of job A: Started by upstream project A build number 414 originally caused by: Started by remote host 127.0.0.1 Started by upstream project A build number 415 originally caused by: Started by remote host 127.0.0.1 Revision: 49576ce4db911825ea0b40bca6278669ae72 Note that the git commit hash of 4957 was actually from #414 of job A: Build #414 (Oct 22, 2012 12:28:07 PM) ... Started by remote host 127.0.0.1 Revision: 49576ce4db911825ea0b40bca6278669ae72 The git commit hash of 4c41 from #415 was not what the triggered job B is building ... in fact, this commit never will get built if no more pushes come in: Build #415 (Oct 22, 2012 1:04:17 PM) ... Revision: 4c41dd60bdff7557133ebfe5229d7f9d06722cef As a result, the developers (justifiably) complain that the latest build artifacts often do not reflect the latest push. Since the continuous integration system is broken, I have to continually monitor the jobs and manually kick them when necessary. 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-15160) earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times
hlau commented on JENKINS-15160 earliest git hash passed by parameterized build trigger when downstream job was triggered multiple times Ideally, there would be a checkbox for the user to indicate whether s/he wants every commit built, or just the latest commit built. In my case, job B runs many times slower than job A. If every commit is built, it would take days for job B to catch up. That would mean I would need to manually kill some runs in job B to help it catching up. constant manual intervention is very undesirable. 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-15285) scm-sync-configuration upgrade from 0.0.5 to 0.0.6 results in NullPointerException
Frédéric Camblor commented on JENKINS-15285 scm-sync-configuration upgrade from 0.0.5 to 0.0.6 results in NullPointerException Hi, could you all confirm you're facing this issue under 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-15597) Overriden authentication not used when invoking Sauce REST API as part of results parsing
Ross Rowe created JENKINS-15597 Overriden authentication not used when invoking Sauce REST API as part of results parsing Issue Type: Bug Assignee: Ross Rowe Components: sauce-ondemand Created: 22/Oct/12 11:34 PM Description: The plugin attempts to use the default Sauce authentication information when invoking the Sauce REST API, regardless of whether the user has specified that it should be overriden for a specific Job. Project: Jenkins Priority: Major Reporter: Ross Rowe 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-15598) Include support for linking Sauce Job to Test result by parsing 'job-name'
Ross Rowe created JENKINS-15598 Include support for linking Sauce Job to Test result by parsing 'job-name' Issue Type: Improvement Assignee: Ross Rowe Components: sauce-ondemand Created: 23/Oct/12 12:32 AM Description: Currently, the Sauce plugin links Sauce Jobs to Test results by parsing the stdout component of the test result XML. In the absence of the stdout from the XML, the plugin should compare the value of the 'job-name' component of the SauceOnDemandSessionID line against the test name, and if it matches, link the Sauce job to the test. Project: Jenkins Priority: Major Reporter: Ross Rowe 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-7957) Hudson Parsing POMs Hanging
Matthew Sheppard updated JENKINS-7957 Hudson Parsing POMs Hanging Change By: Matthew Sheppard (23/Oct/12 12:48 AM) Attachment: matt_sheppard_system_info.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-7957) Hudson Parsing POMs Hanging
Matthew Sheppard commented on JENKINS-7957 Hudson Parsing POMs Hanging I'm seeing the same behaviour on several jobs with openjdk-1.7.0.5.x86_64 running Jenkins 1.484. The what seems to be the interesting bit of the thread dump from systeminfo (which I'll attach) is included below. (The thread dump contains several threads with stacks along the lines of...) "pool-1-thread-16797" Id=287264 Group=main WAITING at sun.misc.Unsafe.park(Native Method) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:315) at org.sonatype.aether.util.concurrency.RunnableErrorForwarder.awaitTerminationOfAllRunnables(RunnableErrorForwarder.java:115) at org.sonatype.aether.util.concurrency.RunnableErrorForwarder.await(RunnableErrorForwarder.java:88) at org.sonatype.aether.impl.internal.DefaultMetadataResolver.resolve(DefaultMetadataResolver.java:348) at org.sonatype.aether.impl.internal.DefaultMetadataResolver.resolveMetadata(DefaultMetadataResolver.java:173) at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(DefaultVersionResolver.java:225) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:272) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:216) at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:193) at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:286) at org.apache.maven.project.ProjectModelResolver.resolveModel(ProjectModelResolver.java:155) at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:813) at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:664) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:310) at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:232) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:410) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:379) at org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:343) at hudson.maven.MavenEmbedder.buildProjects(MavenEmbedder.java:361) at hudson.maven.MavenEmbedder.readProjects(MavenEmbedder.java:331) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1227) at hudson.maven.MavenModuleSetBuild$PomParser.invoke(MavenModuleSetBuild.java:1045) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2308) 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:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Number of locked synchronizers = 1 - java.util.concurrent.ThreadPoolExecutor$Worker@2b10adb6 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-15569) draft-published trigger doesn't work
David Pursehouse commented on JENKINS-15569 draft-published trigger doesn't work This seems to be a problem in the implementation of the event firing in Gerrit itself. The event is not visible to other users. I will upload a patch on Gerrit. 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-15569) draft-published trigger doesn't work
David Pursehouse closed JENKINS-15569 as Not A Defect draft-published trigger doesn't work Not a defect in the trigger plugin. Needs to be fixed in Gerrit. Separate issue report is raised on Gerrit: http://code.google.com/p/gerrit/issues/detail?id=1621 Change By: David Pursehouse (23/Oct/12 2:54 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-6965) GT seems to lose it's connection to Gerrit without re-connecting
David Pursehouse updated JENKINS-6965 GT seems to lose it's connection to Gerrit without re-connecting Change By: David Pursehouse (23/Oct/12 2:55 AM) Summary: GT seems to loose lose it's connection to Gerrit without re-connecting 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-14767) Add Reporting Values for Aborted jobs. Currently an aborted job uses the fail value not something everyone will want.
David Pursehouse updated JENKINS-14767 Add Reporting Values for Aborted jobs. Currently an aborted job uses the fail value not something everyone will want. Change By: David Pursehouse (23/Oct/12 2:57 AM) Summary: Add Reporting Values for Aborted jobs. Currently an apported aborted job uses the fail value not something everyone will want. 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-15597) Overriden authentication not used when invoking Sauce REST API as part of results parsing
SCM/JIRA link daemon commented on JENKINS-15597 Overriden authentication not used when invoking Sauce REST API as part of results parsing Code changed in jenkins User: Ross Rowe Path: src/main/java/hudson/plugins/sauce_ondemand/SauceOnDemandBuildAction.java src/main/java/hudson/plugins/sauce_ondemand/SauceOnDemandReportPublisher.java http://jenkins-ci.org/commit/sauce-ondemand-plugin/dfb6e74c464649df0511efc2a302e452eac25c6a Log: JENKINS-15597 Use authentication details from build action 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-15593) Both DryPublisher and PmdPublisher abort due to exception
Ulli Hafner updated JENKINS-15593 Both DryPublisher and PmdPublisher abort due to exception Change By: Ulli Hafner (23/Oct/12 6:48 AM) Component/s: analysis-core 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-15593) Both DryPublisher and PmdPublisher abort due to exception
Ulli Hafner commented on JENKINS-15593 Both DryPublisher and PmdPublisher abort due to exception Since the error is from the slave node I need some more information from your slave. What JDK are use using on the slaves? Typically, the class org.apache.xerces.jaxp.SAXParserFactoryImpl should be available on your slave. How do you connect your slaves with the master? 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-15593) Both DryPublisher and PmdPublisher abort due to exception
Ulli Hafner assigned JENKINS-15593 to Ulli Hafner Both DryPublisher and PmdPublisher abort due to exception Change By: Ulli Hafner (23/Oct/12 6:52 AM) Assignee: Ulli Hafner 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-15593) Both DryPublisher and PmdPublisher abort due to exception
Ulli Hafner commented on JENKINS-15593 Both DryPublisher and PmdPublisher abort due to exception BTW: you can run the analysis on your master by copying the results (pmd.xml and cpd.xml) to the master node and running a new job that does only analyse these files (just as a workaround). 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
