[JIRA] (JENKINS-14108) Multiple parameterized upstreams with joined in one blocked while.. job result in multiple executions rather one only
Claus Schneider commented on JENKINS-14108 Multiple parameterized upstreams with joined in one blocked while.. job result in multiple executions rather one only additional information: The plugin/build in feature: "Build other projects" work fine concerning this issue.. Eg it only generate one build after "Block while upstreams..." has released the block. 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-13972) Concurrent matrix builds abort
Sven Appenrodt updated JENKINS-13972 Concurrent matrix builds abort Change By: Sven Appenrodt (15/Jun/12 6:56 AM) Priority: Minor Major 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-10912) Memory leak (?) in dashboard
Jonas Olsson commented on JENKINS-10912 Memory leak (?) in dashboard We still experience the problem in Jenkins 1.459. Leave the dashboard open during the night and memory will be eaten. Both Firefox and Chrome seems to be affected. OS is Ubuntu. 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-13972) Concurrent matrix builds abort
Sven Appenrodt commented on JENKINS-13972 Concurrent matrix builds abort This seems to be a side effect of the fix of issue 6747. The problem only appears when starting the matrix jobs in concurrent mode. Starting the job in serial mode will not abort the axis-jobs Next problem: the workaround given in issue 6747 is not working anymore. So there is no possibility to patch the job to run them concurrent anymore. 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-14112) The execution (build) of Project will fail on mkdir on remote disk.
Macpaul Lin commented on JENKINS-14112 The execution (build) of Project will fail on mkdir on remote disk. I have found a workaround by using "\\NAS\PC12010025\workspace" to replace "Z:\PC12010025\workspace" to avoid mkdir fail. However, when you use perforce-plugin with this workaround, the perforce plugin cannot take "\\NAS\PC12010025\workspace" as its root directory. The string will be converted as "\NAS\PC12010025\workspace" which is not correct when p4.exe sync source code on windows system. Whether you configured the string like "NAS\PC12010025\workspace" or "NAS/PC12010025/workspace", it will finally converted as "\NAS\PC12010025\workspace. So there are 2 problems related to this 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-14114) CPU on 100% when sending mail
Cees Bos created JENKINS-14114 CPU on 100% when sending mail Issue Type: Bug Assignee: Slide-O-Mix Attachments: extendedmail_publisher.png Components: email-ext Created: 15/Jun/12 8:30 AM Description: Our Jenkins server was on 100% CPU usage. 4 threads were very busy with sending an email. All 4 thread had the same stacktrace, see screenshot. Looks like that lookup of emailadresses is consuming too much CPU. Project: Jenkins Priority: Blocker Reporter: Cees Bos 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-14024) Disable resolving relative to absolute paths
SCM/JIRA link daemon commented on JENKINS-14024 Disable resolving relative to absolute paths Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/analysis/core/FilesParser.java src/main/java/hudson/plugins/analysis/core/HealthAwarePublisher.java http://jenkins-ci.org/commit/analysis-core-plugin/991752ce43d115a1039dc33e606c82710990e8c6 Log: JENKINS-14024 Added option to disable resolving of relative paths. 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-14024) Disable resolving relative to absolute paths
SCM/JIRA link daemon commented on JENKINS-14024 Disable resolving relative to absolute paths Code changed in jenkins User: Ulli Hafner Path: pom.xml src/main/java/hudson/plugins/warnings/WarningsPublisher.java src/main/resources/hudson/plugins/warnings/WarningsPublisher/config.jelly src/main/resources/hudson/plugins/warnings/WarningsPublisher/config.properties src/main/resources/hudson/plugins/warnings/WarningsPublisher/config_de.properties http://jenkins-ci.org/commit/warnings-plugin/1e119381e25747f638c2022d1bd31de0a85eff7f Log: FIXED JENKINS-14024 Added option to allow disabling of time expensive operation that resolves relative paths by scanning the whole workspace. 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-14024) Disable resolving relative to absolute paths
SCM/JIRA link daemon resolved JENKINS-14024 as Fixed Disable resolving relative to absolute paths Change By: SCM/JIRA link daemon (15/Jun/12 8:53 AM) Status: InProgress 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-13532) Changing analysis-core's tab makes breadcrumbs bar move down
SCM/JIRA link daemon commented on JENKINS-13532 Changing analysis-cores tab makes breadcrumbs bar move down Code changed in jenkins User: OHTAKE Tomohiro Path: src/main/resources/result/main.jelly src/main/webapp/yui/tabview-min.js src/main/webapp/yui/utilities.js http://jenkins-ci.org/commit/analysis-core-plugin/181e2fc0a497c7bf4399346e0a4c4cc4cda1fa52 Log: FIXED JENKINS-13532 Use YUI 2.9 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-13532) Changing analysis-core's tab makes breadcrumbs bar move down
SCM/JIRA link daemon resolved JENKINS-13532 as Fixed Changing analysis-cores tab makes breadcrumbs bar move down Change By: SCM/JIRA link daemon (15/Jun/12 9:02 AM) Status: Reopened 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-13532) Changing analysis-core's tab makes breadcrumbs bar move down
SCM/JIRA link daemon commented on JENKINS-13532 Changing analysis-cores tab makes breadcrumbs bar move down Code changed in jenkins User: Ulli Hafner Path: src/main/resources/result/main.jelly src/main/webapp/yui/tabview-min.js src/main/webapp/yui/utilities.js http://jenkins-ci.org/commit/analysis-core-plugin/0a8c612801aefb73cb29980eb2e59d041eddfe4c Log: Merge pull request #7 from ohtake/yui29 FIXED JENKINS-13532 Upgrade to YUI 2.9. Compare: https://github.com/jenkinsci/analysis-core-plugin/compare/991752ce43d1...0a8c612801ae 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-14116) Updating to specific revision doesn't work
Dmitry Kholodilov
created JENKINS-14116
Updating to specific revision doesnt work
Issue Type:
Bug
Assignee:
Unassigned
Attachments:
jenkins-subversion-error-log.txt
Components:
subversion
Created:
15/Jun/12 10:32 AM
Description:
Suppose we have SVN repository https://svnserver/rep1 with HEAD=3.
Test case:
1. Create Jenkins job (free-style build)
2. Check "This build is parameterized", add String parameter "REVISION"
3. Select "Source Code Management" = "Subversion", specify Repository URL = "" href="https://svnserver/rep1/trunk@$">https://svnserver/rep1/trunk@${REVISION}
4. Save configuration, click "Build now", specify REVISION parameter with value=HEAD
5. Wait for build finish (it should succeed), click "Build now" again, specify REVISION parameter with value=2
Expected result:
Build succeeds with working copy in workspace at revision 2.
Actual results:
Build fails on working copy update step (full log attached):
Updating https://svnserver/rep1/trunk@2
U Test.java
At revision 2
hudson.util.IOException2: revision check failed on https://svnserver/rep1/trunk
at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:170)
at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:112)
at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:563)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:710)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1242)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
at hudson.model.Run.execute(Run.java:1460)
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: org.tmatesoft.svn.core.SVNException: svn: E160006: No such revision 4
svn: E175002: REPORT of '/rep1/!svn/bc/3/trunk': 500 Internal Server Error (https://svnserver)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
...
Error is reproduced with different versions of Jenkins, Subversion plugin and different values of "Check-out Strategy" parameter.
Environment:
Windows 7 x86_64, Jenkins 1.470, Subversion plugin 1.40
Project:
Jenkins
Priority:
Major
Reporter:
Dmitry Kholodilov
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-14117) The plugin hasn't been performed correctly: remote file operation failed
Thomas Oeding created JENKINS-14117 The plugin hasnt been performed correctly: remote file operation failed Issue Type: Bug Assignee: Gregory Boissinot Components: xunit Created: 15/Jun/12 10:38 AM Description: We got always this error! Seems the same like http://issues.hudson-ci.org/browse/HUDSON-7081 We can reproduce it. monospaced == Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped == G_master_xUnit_test $ cmd /c call D:\TEMP\hudson426846465795215396.bat xUnit INFO - Starting to record. xUnit INFO - Processing BoostTest-1.x (default) xUnit WARNING - Can't create the path d:HUDSON\workspace\G_master_xUnit_test\generatedJUnitFiles. Maybe the directory already exists. xUnit INFO - BoostTest-1.x (default) - 30 test report file(s) were found with the pattern 'build/bin/x64/DEBUG/Test*.xml' relative to 'd:HUDSON\workspace\G_master_xUnit_test' for the testing framework 'BoostTest-1.x (default)'. xUnit ERROR - There is at least one problem. Check the Jenkins system log for more information. (if you don't have configured yet the system log before, you have to rebuild). xUnit INFO - Processing BoostTest-1.x (default) xUnit WARNING - Can't create the path d:HUDSON\workspace\G_master_xUnit_test\generatedJUnitFiles. Maybe the directory already exists. xUnit INFO - BoostTest-1.x (default) - No test report file(s) were found with the pattern 'build/bin/x64/Release/Test*.xml' relative to 'd:HUDSON\workspace\G_master_xUnit_test' for the testing framework 'BoostTest-1.x (default)'. Did you enter a pattern relative to the correct directory? Did you generate the result report(s) for 'BoostTest-1.x (default)'? xUnit ERROR - No test reports found for the metric 'BoostTest' with the resolved pattern 'build/bin/x64/Release/Test*.xml'. Configuration error?. xUnit ERROR - The plugin hasn't been performed correctly: remote file operation failed: d:/_HUDSON/workspace/G_master_xUnit_test at hudson.remoting.Channel@693ed7e2:MUCBPC002 Build step 'Publish xUnit test result report' changed build result to FAILURE Build step 'Publish xUnit test result report' marked build as failure monospaced Environment: Jenkins 1.469 Linux master Windows 7 slaves Project: Jenkins Labels: xunit cppunit Priority: Major Reporter: Thomas Oeding 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-14119) Rebuilding only stable configurations in an otherwise unstable full matrix produces false succesful reloaded build
Mads Nielsen created JENKINS-14119 Rebuilding only stable configurations in an otherwise unstable full matrix produces false succesful reloaded build Issue Type: Bug Affects Versions: current Assignee: Praqma Support Components: matrix-reloaded Created: 15/Jun/12 11:41 AM Description: This bug occurs if you rebuild only healty configurations in an otherwise unstable full matrix. Project: Jenkins Priority: Major Reporter: Mads Nielsen 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-14120) Node/label parameter plugin output is confusing for users
Costin Caraivan created JENKINS-14120 Node/label parameter plugin output is confusing for users Issue Type: Improvement Affects Versions: current Assignee: domi Components: nodelabelparameter Created: 15/Jun/12 12:17 PM Description: When using the nodelabel factory to trigger another job, the console output looks like this: Found nodes: hudson.slaves.DumbSlave@a08c262c, hudson.slaves.DumbSlave@9c8db50b, hudson.slaves.DumbSlave@a48a974d I know this was probably convenient, but just printing .toString() isn't really user friendly. http://javadoc.jenkins-ci.org/hudson/model/Slave.html#getNodeName%28%29 would be better, IMO. Project: Jenkins Labels: ux user Priority: Minor Reporter: Costin Caraivan 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-14110) plugin download: http://updates.jenkins-ci.org/latest/github.hpi *not found* resulting in failed chef runs.
Sloan Thompson resolved JENKINS-14110 as Fixed plugin download: http://updates.jenkins-ci.org/latest/github.hpi *not found* resulting in failed chef runs. The link is working again. Change By: Sloan Thompson (15/Jun/12 1:03 PM) Status: Open Resolved Assignee: KohsukeKawaguchi SloanThompson 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-14122) Build Executors on Nodes enter infinite hang
Martin Schröder created JENKINS-14122 Build Executors on Nodes enter infinite hang Issue Type: Bug Affects Versions: current Assignee: Unassigned Attachments: ThreadDump.zip Components: core Created: 15/Jun/12 1:03 PM Description: Hello everyone. We experience a major and persistent issue with Build Executors hanging infinitely. This affects all recent versions of Jenkins. The bug expresses itself like this: After some time of successfully building job (sometimes days, sometimes weeks), the executors of at first some nodes and then progressively more nodes just start failing. They accept a new job, start it on one of their executors, begin calling the SCM and then just ... stop. Here's an example log output (full paths excised with angled brackets): - 13:57:38 Started by command line by sys_swmdev 13:57:38 Building remotely on musxbird015 in workspace /local/path/project@3 13:57:38 Checkout:XMM6260_SDLGEN@3 / /local/path/project@3 - hudson.remoting.Channel@2aa89e44:musxbird015 13:57:38 Using strategy: Default 13:57:38 Last Built Revision: Revision 501d0dbbd090f3dd338ad107b4d84f0e35544a9c (GIT TAG) - Even waiting hours will not cause this to progress. Sometime, other executor s on the same node still work and other nodes can execute the same job just fine ... until they too fail one by one. Also, sometimes the job crashes hangs in the middle of execution, instead of during the GIT checkout. The load on the hung node is next to zero during all of this; same is true for the remote GIT server. If you break the connection to the node and restart the connection again (Which will, by the way, not remove those jobs from the Jenkins UI. A manual cancel is necessary!), the node starts working again; at least for some time. Only a full restart of Jenkins can solve this issue; until it recurrs some days or weeks later. All jobs are affected, even the most simple ones that don't do anything. As soon as an Executor has hung, it does not recuperate. Additionally, this problem is completely independent of the load. It can happen with hundreds of jobs in the queue with only a single job executing at a time on the entire build cluster. It is as if the server can't read/send responses from/to the nodes anymore. The machines themselves are not hanging and can be accessed normally. Additionally, the script console for these nodes also still works. Over all, this bug is extremely strange and difficult to replicate. It happens reliably, just after a seemingly arbitrary amount of time. I have attached a thread-dump of one particular machine, and the entire server to this bug report. If you need further information to debug this, feel free to ask for them. Environment: Jenkins Server: Ubuntu 10.4.4 Jenkins Nodes: Ubutnu 10.4.4 Project: Jenkins Labels: jenkins core hang Priority: Major Reporter: Martin Schröder This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9309) sloccount trend report only works up to last failed build
SCM/JIRA link daemon commented on JENKINS-9309 sloccount trend report only works up to last failed build Code changed in jenkins User: Karsten Brandt Path: src/main/java/hudson/plugins/sloccount/SloccountProjectAction.java src/main/java/hudson/plugins/sloccount/SloccountPublisher.java http://jenkins-ci.org/commit/sloccount-plugin/ba86876f210ffc7e210d740fd938cef7b9cf04d3 Log: FIXED JENKINS-9309 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9309) sloccount trend report only works up to last failed build
SCM/JIRA link daemon resolved JENKINS-9309 as Fixed sloccount trend report only works up to last failed build Change By: SCM/JIRA link daemon (15/Jun/12 1:05 PM) Status: InProgress Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9309) sloccount trend report only works up to last failed build
SCM/JIRA link daemon commented on JENKINS-9309 sloccount trend report only works up to last failed build Code changed in jenkins User: Karsten Brandt Path: src/main/java/hudson/plugins/sloccount/ReportSummary.java src/main/java/hudson/plugins/sloccount/SloccountBuildAction.java src/main/java/hudson/plugins/sloccount/SloccountProjectAction.java src/main/java/hudson/plugins/sloccount/SloccountPublisher.java http://jenkins-ci.org/commit/sloccount-plugin/92f5ca9855f4bbf65f95c61b4ab9ca1e606c6f37 Log: FIXED JENKINS-9309 sloccount trend report only works up to last failed build (second version) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9309) sloccount trend report only works up to last failed build
SCM/JIRA link daemon commented on JENKINS-9309 sloccount trend report only works up to last failed build Code changed in jenkins User: Karsten Brandt Path: src/main/java/hudson/plugins/sloccount/SloccountPublisher.java src/main/java/hudson/plugins/sloccount/model/SloccountParser.java http://jenkins-ci.org/commit/sloccount-plugin/2d0f2d6358cad6ae144abef5e6f304c4e3e5bb94 Log: FIXED JENKINS-9309 sloccount trend report only works up to last failed build (3th version) Compare: https://github.com/jenkinsci/sloccount-plugin/compare/2a42be3148e1...2d0f2d6358ca 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-11729) Cannot install Jenkins on a fresh copy of Solaris 11
Thorsten Heit commented on JENKINS-11729 Cannot install Jenkins on a fresh copy of Solaris 11 This ticket is now open for more than half a year, and I already suggested a solution. Any hints on when this will be worked on? 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-13547) Jenkins runs extremely slow with remote crowd server
Thorsten Heit commented on JENKINS-13547 Jenkins runs extremely slow with remote crowd server Surely there is a better way? Maybe there should be an option to allow crowd to wait until the session times out or something? I'm guessing checking every request is just to see if the account is still allowed to login to Jenkins? There's already a patch contained in the master branch contributed by John Crawford for exactly that AFAICT the Crowd libraries themselves have a feature to let you skip the validation for a certain amount of time. The plugin itself so far doesn't make use of this, i.e. each request to be processed gets validated against Crowd. In the next version you'll be able to specify that validation interval 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-14118) Builds triggered through Conditional buildstep plugin are not reported as downstream builds for the current build.
Richard Lok commented on JENKINS-14118 Builds triggered through Conditional buildstep plugin are not reported as downstream builds for the current build. I am seeing this problem as well. Mainly I want to be able to indicate a build as downstream with conditional-buildstep so that I can use the "Block build when upstream project is building" and "Block build when downstream project is building" option. 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-13790) Subversion externals fail
Stephan Grimm commented on JENKINS-13790 Subversion externals fail I have probably the same problem and I'm getting frustrated because I really don't know how to solve it (using Jenkins 1.470, Subversion Plugin 1.40) The repository contains an external directory. Within the Main folder I changed a source file (main.c), but the changes are not updated in jobs workspace directory at the beginning of the run. Does anybody know why? Is it a bug or maybe just a wrong configuration? If it's a subversion plugin problem: Is there a newer version? How could I install that version? The log: Building in workspace C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace Cleaning up C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace\. Deleting C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace\BuildPlan.xml Deleting C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace\WLP.c Updating https://repos.xxx.com/svn/trunk U main.c AssertionError: appears to be using unpatched svnkit at jar:file:/C:/Jenkins/Config/plugins/subversion/WEB-INF/lib/svnkit-1.7.4-jenkins-1.jar!/org/tmatesoft/svn/core/wc/SVNEvent.class At revision 11875 At revision 11874 no change for https://repos.xxx.com/svn/trunk since the previous 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-13790) Subversion externals fail
Stephan Grimm edited a comment on JENKINS-13790 Subversion externals fail I have probably the same problem and I'm getting frustrated because I really don't know how to solve it (using Jenkins 1.470, Subversion Plugin 1.40, Check-out Strategy: "Emulate clean checkout by...") The repository contains an external directory. Within the Main folder I changed a source file (main.c), but the changes are not updated in jobs workspace directory at the beginning of the run. Does anybody know why? Is it a bug or maybe just a wrong configuration? If it's a subversion plugin problem: Is there a newer version? How could I install that version? The log: Building in workspace C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace Cleaning up C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace\. Deleting C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace\BuildPlan.xml Deleting C:\Jenkins\Config\jobs\WAP2-Trunk_DB-Build\workspace\WLP.c Updating https://repos.xxx.com/svn/trunk U main.c AssertionError: appears to be using unpatched svnkit at jar:file:/C:/Jenkins/Config/plugins/subversion/WEB-INF/lib/svnkit-1.7.4-jenkins-1.jar!/org/tmatesoft/svn/core/wc/SVNEvent.class At revision 11875 At revision 11874 no change for https://repos.xxx.com/svn/trunk since the previous 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-14106) Rebuild is broken when coupled with Node Label plugin.
domi resolved JENKINS-14106 as Duplicate Rebuild is broken when coupled with Node Label plugin. this is the same as JENKINS-11770 and its nothing we can fix in the nodelabel plugin, this is an issue of the rebuild plugin Change By: domi (15/Jun/12 5:50 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-14069) Access denied when installing email-ext.jpi through Update Center
Slide-O-Mix resolved JENKINS-14069 as Cannot Reproduce Access denied when installing email-ext.jpi through Update Center Known issue with update center Change By: Slide-O-Mix (15/Jun/12 6:07 PM) Status: Open Resolved Resolution: CannotReproduce 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-14123) rootPOM disappears
Andrei_Pozolotin created JENKINS-14123 rootPOM disappears Issue Type: Bug Assignee: Unassigned Components: core Created: 15/Jun/12 7:36 PM Description: https://groups.google.com/forum/?fromgroups#!topic/jenkinsci-users/Im7IBwUqWUc jenkns version 1.467 problem: project uses rootPOM path spec such as parent/child/pom.xml if you edit job config after change rootPOM entry looks fine after jenkins restart, if you edit job config now, rootPOM entry looks empty, despite appropriate entry is present OK in job/config.xml and job builds fine; if you now merely edit and save job config, the rootPOM entry is lost in job/config.xml and job does not build any more Environment: 1.467 Project: Jenkins Priority: Major Reporter: Andrei_Pozolotin 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-7992) fails to parse dependency analysis results in recent hudson
Miquel Martin updated JENKINS-7992 fails to parse dependency analysis results in recent hudson These are the compiled binaries after fixing the color parsing issues Change By: Miquel Martin (15/Jun/12 7:41 PM) Attachment: binaries.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-7992) fails to parse dependency analysis results in recent hudson
Miquel Martin updated JENKINS-7992 fails to parse dependency analysis results in recent hudson Here's the patched file, which simply considers colors in the log output Change By: Miquel Martin (15/Jun/12 7:42 PM) Attachment: BuildLogFileParser.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-7992) fails to parse dependency analysis results in recent hudson
Miquel Martin commented on JENKINS-7992 fails to parse dependency analysis results in recent hudson Hi guys, It was indeed a problem of the color, but a little bit more than Guy suggested, since the log parser can also output things like "colorsINFOmore_colors actual content". The start and end seem to be all right, since by the time the tests come up, all maven-dependency output is already parsed. I have uploaded the compiled plugin and the actual changed file if anyone needs it, this is working for me. I don't know if vsellier is still checking this: I'm happy to commit to svn if you prefer! 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-7992) fails to parse dependency analysis results in recent hudson
Miquel Martin started work on JENKINS-7992 fails to parse dependency analysis results in recent hudson Change By: Miquel Martin (15/Jun/12 7:47 PM) Status: Open InProgress 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-3265) Reload Configuration from Disk (or POSTing config.xml) loses info on running builds
Matt Mitchell commented on JENKINS-3265 Reload Configuration from Disk (or POSTing config.xml) loses info on running builds Change is here: https://github.com/antifun/jenkins/commit/2793ce3721de8c6a1e9d7912b92e437d6e827b2e 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-14063) Images are broken when not logged in
S. Morris Rose commented on JENKINS-14063 Images are broken when not logged in I have this identical issue on a Fedora 15 x86_64 install. What I can add is that the reason the images are broken is because accessing their URLs generates a 500 Server Error. The backtrace shows the underlying issue to be a NullPointerException. I've tried pretty much every upgrade between 1.462 and 1.470 and each exhibits this same behaviour. I'd really like to be able to move up so that I can see if a (presumably) unrelated issue I have is healed by a later release. Wit's end, 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-6609) Fitnesse publisher plugin fails to parse XML file.
Kohsuke Kawaguchi resolved JENKINS-6609 as Duplicate Fitnesse publisher plugin fails to parse XML file. I assume this is parsing a report from a remote slave. If so, this looks like the same problem as in JENKINS-11251. Change By: Kohsuke Kawaguchi (15/Jun/12 9:05 PM) Status: Open Resolved Assignee: KohsukeKawaguchi 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-10274) Can this plugin support CLOC for even more languages and better Windows support
Karsten Brandt commented on JENKINS-10274 Can this plugin support CLOC for even more languages and better Windows support The tool cloc has an option to create xml output. This output can transformed via a short XSLT script into the sloccount format. Therefore, no changes are required within the sloccount source. Please, reject this change request! 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-11251) Cannot parse coverage results Premature end of file.
Kohsuke Kawaguchi commented on JENKINS-11251 Cannot parse coverage results Premature end of file. Notice that in the original reported case, the stack trace includes "determineDocVersion", so this indicates that the pipe was lost very early in the connection. Possibly even before a single byte was read. That sounds like JENKINS-8703, which was released in remoting 1.420. So if anyone is running older version of master/slave.jar, the first thing to do is to upgrade. But the comment from Philippe indicates that it's still happening in a newer version of Jenkins, so there must be still something going on. JENKINS-7871 has different stack trace, and that is happening toward the end of the 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-11251) Cannot parse coverage results Premature end of file.
Kohsuke Kawaguchi edited a comment on JENKINS-11251 Cannot parse coverage results Premature end of file. Looking at the cobertura plugin, I see that it's not reading from a pipe (which I assumed so incorrectly earlier.) Instead, this is loading a local file. That changes everything. 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-13790) Subversion externals fail
Markus Hjerto commented on JENKINS-13790 Subversion externals fail Stephan, We downgraded to 1.39 and it seems to have "solved" the problem. YMMV. 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-13790) Subversion externals fail
Stephan Grimm commented on JENKINS-13790 Subversion externals fail Because of some build scripts we need the subversion 1.7 working copy format. as I know, the version 1.39 of the subversion plugin does use the 1.6 working copy format. is someone working on a solution? 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-11251) Cannot parse coverage results Premature end of file.
Kohsuke Kawaguchi commented on JENKINS-11251 Cannot parse coverage results Premature end of file. Bumped up the priority of this plugin to make it a candidate for LTS backporting. 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-11251) Cannot parse coverage results Premature end of file.
Kohsuke Kawaguchi updated JENKINS-11251 Cannot parse coverage results Premature end of file. Change By: Kohsuke Kawaguchi (16/Jun/12 1:31 AM) Priority: Major Blocker 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-11251) Cannot parse coverage results Premature end of file.
SCM/JIRA link daemon commented on JENKINS-11251 Cannot parse coverage results Premature end of file. Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html core/src/main/java/hudson/FilePath.java pom.xml http://jenkins-ci.org/commit/jenkins/f49d6258451155c716976d7af5433c0fde7fe890 Log: FIXED JENKINS-11251 The actual meat of the change is in remoting. 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-9189) truncation or corruption of zip workspace archive from slave
SCM/JIRA link daemon commented on JENKINS-9189 truncation or corruption of zip workspace archive from slave Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/remoting/ProxyOutputStream.java src/main/java/hudson/remoting/Request.java http://jenkins-ci.org/commit/remoting/8ffed0da4996934bfc28bf6b08c258d367a1c526 Log: JENKINS-11251 JENKINS-9189 Resurrecting what's deleted in e0e154d12d7a10759287b187467389c6e643c12b When communicating with remoting 2.15, this allows them to continue to perform some degree of syncing, so that they can still enjoy the fix for JENKINS-9189. None of these code is exposed via API outside remoting, so at some point we can revert this change to simplify the code a bit and eliminate the redundancy, because as long as = 2.15 remoting talk to each other, PipeWriter does everything we need. 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-11251) Cannot parse coverage results Premature end of file.
SCM/JIRA link daemon resolved JENKINS-11251 as Fixed Cannot parse coverage results Premature end of file. Change By: SCM/JIRA link daemon (16/Jun/12 2:36 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-9189) truncation or corruption of zip workspace archive from slave
SCM/JIRA link daemon commented on JENKINS-9189 truncation or corruption of zip workspace archive from slave Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/remoting/Channel.java src/main/java/hudson/remoting/Pipe.java src/main/java/hudson/remoting/PipeWriter.java src/main/java/hudson/remoting/ProxyOutputStream.java src/main/java/hudson/remoting/Request.java src/main/java/hudson/remoting/Response.java http://jenkins-ci.org/commit/remoting/e0e154d12d7a10759287b187467389c6e643c12b Log: FIXED JENKINS-11251 reimplemented I/O and Request/Response sync See PipeWriter javadoc for the discussion and the context of this. This change re-implements the original fix for JENKINS-9189. 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-11251) Cannot parse coverage results Premature end of file.
SCM/JIRA link daemon commented on JENKINS-11251 Cannot parse coverage results Premature end of file. Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/remoting/ProxyOutputStream.java src/main/java/hudson/remoting/Request.java http://jenkins-ci.org/commit/remoting/8ffed0da4996934bfc28bf6b08c258d367a1c526 Log: JENKINS-11251 JENKINS-9189 Resurrecting what's deleted in e0e154d12d7a10759287b187467389c6e643c12b When communicating with remoting 2.15, this allows them to continue to perform some degree of syncing, so that they can still enjoy the fix for JENKINS-9189. None of these code is exposed via API outside remoting, so at some point we can revert this change to simplify the code a bit and eliminate the redundancy, because as long as = 2.15 remoting talk to each other, PipeWriter does everything we need. 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-11251) Cannot parse coverage results Premature end of file.
SCM/JIRA link daemon commented on JENKINS-11251 Cannot parse coverage results Premature end of file. Code changed in jenkins User: Kohsuke Kawaguchi Path: src/main/java/hudson/remoting/Channel.java src/main/java/hudson/remoting/Pipe.java src/main/java/hudson/remoting/PipeWriter.java src/main/java/hudson/remoting/ProxyOutputStream.java src/main/java/hudson/remoting/Request.java src/main/java/hudson/remoting/Response.java http://jenkins-ci.org/commit/remoting/e0e154d12d7a10759287b187467389c6e643c12b Log: FIXED JENKINS-11251 reimplemented I/O and Request/Response sync See PipeWriter javadoc for the discussion and the context of this. This change re-implements the original fix for JENKINS-9189. 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-11251) Cannot parse coverage results Premature end of file.
SCM/JIRA link daemon commented on JENKINS-11251 Cannot parse coverage results Premature end of file. Code changed in jenkins User: Kohsuke Kawaguchi Path: src/test/java/hudson/remoting/PipeWriterTest.java src/test/java/hudson/remoting/PipeWriterTestChecker.java src/test/java/hudson/remoting/RmiTestBase.java http://jenkins-ci.org/commit/remoting/00609519a68bb2b488d6217d49f53a76d955bed0 Log: Added a test case for JENKINS-11251. Compare: https://github.com/jenkinsci/remoting/compare/cb1854b81ac8...00609519a68b 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-14105) Build timeout plugin 1.9 always sets timeout period to 3 minutes
SCM/JIRA link daemon commented on JENKINS-14105 Build timeout plugin 1.9 always sets timeout period to 3 minutes Code changed in jenkins User: Seiji Sogabe Path: src/main/java/hudson/plugins/build_timeout/BuildTimeoutWrapper.java http://jenkins-ci.org/commit/build-timeout-plugin/f1ca983dea997e5cf8311e5f77383c73f0493648 Log: FIXED JENKINS-14105 Build timeout plugin 1.9 always sets timeout period to 3 minutes 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-14105) Build timeout plugin 1.9 always sets timeout period to 3 minutes
SCM/JIRA link daemon resolved JENKINS-14105 as Fixed Build timeout plugin 1.9 always sets timeout period to 3 minutes Change By: SCM/JIRA link daemon (16/Jun/12 3:44 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-12763) Excessive lock contention when using mercurial cache with multiple repos and slaves
SCM/JIRA link daemon commented on JENKINS-12763 Excessive lock contention when using mercurial cache with multiple repos and slaves Code changed in jenkins User: Jesse Glick Path: src/main/java/hudson/plugins/mercurial/Cache.java http://jenkins-ci.org/commit/mercurial-plugin/dc0bd85a0a396b1f83caebba3080f673ca16a99c Log: Merge pull request #21 from nimeacuerdo/master FIXED JENKINS-12763 Reduce lock contention while updating caches Compare: https://github.com/jenkinsci/mercurial-plugin/compare/116ab226f746...dc0bd85a0a39 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-12763) Excessive lock contention when using mercurial cache with multiple repos and slaves
SCM/JIRA link daemon resolved JENKINS-12763 as Fixed Excessive lock contention when using mercurial cache with multiple repos and slaves Change By: SCM/JIRA link daemon (16/Jun/12 4:36 AM) Status: InProgress 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-12452) WallDisplay Plugin incompatible with IE8
SCM/JIRA link daemon commented on JENKINS-12452 WallDisplay Plugin incompatible with IE8 Code changed in jenkins User: pellepelster Path: src/main/webapp/walldisplay.html http://jenkins-ci.org/commit/walldisplay-plugin/97bdfddbe660903012b84613f00371674971e3f5 Log: Merge pull request #6 from petehayes/master Fix for JENKINS-12452 WallDisplay Plugin incompatible with IE8 Compare: https://github.com/jenkinsci/walldisplay-plugin/compare/ccd4c4431f33...97bdfddbe660 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
