[JIRA] (JENKINS-13735) Jenkins starts wrong slave for job restricted to specific one
Marco Lehnort commented on JENKINS-13735 Jenkins starts wrong slave for job restricted to specific one I deployed the jenkins v1.470 today and tested the fis. Works like a charm!!! No irrelevant slaves are powered up, the correct slave required to execute a job is started. Thanks to everyone for the fast responses to my problem! @Jason: thanks for your analysis and fix! Cheers, Marco. This message is automatically generated by JIRA. 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-13735) Jenkins starts wrong slave for job restricted to specific one
Marco Lehnort closed JENKINS-13735 as Fixed Jenkins starts wrong slave for job restricted to specific one Closing as everything seems to work as expected. Change By: Marco Lehnort (14/Jun/12 7:32 AM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13970) Build variable CC_BASELINE not populated with used baseline
SCM/JIRA link daemon commented on JENKINS-13970 Build variable CC_BASELINE not populated with used baseline Code changed in jenkins User: wolfgarnet Path: src/main/java/net/praqma/hudson/CCUCMRunListener.java src/main/java/net/praqma/hudson/scm/CCUCMScm.java http://jenkins-ci.org/commit/clearcase-ucm-plugin/75a302473b471c5e971eb89a8e4390278fe96692 Log: Merge pull request #5 from wolfgarnet/master Fix for issue JENKINS-13970 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
How to secure all web resources
Hi ! just a simple question. I have secured jenkins as described in the manual and we are using an external ldap directory. by default it seems that one can access jenkins without authentication but if I want to start a build by example I have to login. so my question is : how to secure jenkins that all web resources are secured : no access without authentication ? thanks and kind regards marco -- View this message in context: http://jenkins.361315.n4.nabble.com/How-to-secure-all-web-resources-tp4631516.html Sent from the Jenkins issues mailing list archive at Nabble.com.
[JIRA] (JENKINS-13592) Details part of each ccm warning always displays all file
Marc Obrador commented on JENKINS-13592 Details part of each ccm warning always displays all file We are having the same issue after updating ccm plugin to v3.0: when going to CCM Warnings -> details, all we get is this: And, if we select a file, we get the following error: This message is automatically generated by JIRA. 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-13592) Details part of each ccm warning always displays all file
Marc Obrador updated JENKINS-13592 Details part of each ccm warning always displays all file Change By: Marc Obrador (14/Jun/12 11:18 AM) Attachment: jenkins ccm error modified.png This message is automatically generated by JIRA. 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-14097) Allow Script Path/Content to add/override environment variables for the build job
David Ehrenberger edited a comment on JENKINS-14097 Allow Script Path/Content to add/override environment variables for the build job I use the bash built-in 'source' command which executes the script in the context of the current shell. For the purposes of this plugin, doing so will load any exported environment variables into the shell environment. Once the shell is closed, the variables exported into it are gone as well. This is why, if I execute 5 different shell build steps, I must source the environment file in each build step. As an example, if my script called environment.anything contains: #!/bin/bash export MY_VARIABLE="Test Variable" This would be possible in a shell: source environment.anything echo $MY_VARIABLE Test Variable You can read about shells Here but the 'source' command should be supported by most major shell types. Ultimately, I'd like to be able to source a script which sets up my job environment such that all my build steps also share that environment. This message is automatically generated by JIRA. 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-14097) Allow Script Path/Content to add/override environment variables for the build job
David Ehrenberger commented on JENKINS-14097 Allow Script Path/Content to add/override environment variables for the build job I use the bash built-in 'source' command which executes the script in the context of the current shell. For the purposes of this plugin, doing so will load any exported environment variables into the shell environment. Once the shell is closed, the variables exported into it are gone as well. This is why, if I execute 5 differed shell build steps, I must source the environment file in each build step. As an example, if my script called environment.anything contains: #!/bin/bash export MY_VARIABLE="Test Variable" This would be possible in a shell: source environment.anything echo $MY_VARIABLE Test Variable You can read about shells Here but the 'source' command should be supported by most major shell types. Ultimately, I'd like to be able to source a script which sets up my job environment such that all my build steps also share that environment. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13202) Artifact archiving from an ssh slave fails if symlinks are present
Stephen Morrison reopened JENKINS-13202 Artifact archiving from an ssh slave fails if symlinks are present Still broken Change By: Stephen Morrison (14/Jun/12 12:32 PM) Resolution: Fixed Status: Resolved Reopened This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14103) Grails 2.0.4 not listed in installer doropdown
c089 created JENKINS-14103 Grails 2.0.4 not listed in installer doropdown Issue Type: Bug Assignee: jeffg2one Components: grails Created: 14/Jun/12 12:52 PM Description: Grails 2.0.4 has been released a while ago, but the install from mirrors dropdown still does not list the new version. Project: Jenkins Priority: Major Reporter: c089 This message is automatically generated by JIRA. 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-14104) Use same node which has been specified in the "Restrict where this project can be run" field
Victor Martinez created JENKINS-14104 Use same node which has been specified in the "Restrict where this project can be run" field Issue Type: Bug Affects Versions: current Assignee: Gregory Boissinot Components: scripttrigger Created: 14/Jun/12 1:47 PM Description: Hello All, Execute ScriptTrigger using the same slave as was specified in the "Restrict where this project can be run" field For instance: Restrict where this project can be run: Label _expression_: UBUNTU [ScriptTrigger] - Poll with a shell or batch script Polling started on 14-Jun-2012 07:00:59 Polling for the job XXX_2.5 Looking nodes where the poll can be run. Looking for a candidate node to run the poll. Looking for a polling node with the assigned project label ubuntu. Trying to poll on master node. Polling on master. The expected script execution code is 0 Evaluating the script: Thanks Environment: rhel 5.5 64 bits Jenkins 1.464 Project: Jenkins Priority: Major Reporter: Victor Martinez This message is automatically generated by JIRA. 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 We are seeing the same issue after updating to 1.40. The job fails. This is the output: AssertionError: appears to be using unpatched svnkit at file:/tmp/hudson-remoting6567098393035999821/org/tmatesoft/svn/core/wc/SVNEvent.class At revision 5215 AssertionError: appears to be using unpatched svnkit at file:/tmp/hudson-remoting6567098393035999821/org/tmatesoft/svn/core/wc/SVNEvent.class FATAL: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 41 hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 41 at hudson.remoting.Request.call(Request.java:149) at hudson.remoting.Channel.call(Channel.java:646) at hudson.FilePath.act(FilePath.java:821) at hudson.FilePath.act(FilePath.java:814) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:581) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:470) at hudson.model.Run.run(Run.java:1434) 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: hudson.remoting.RequestAbortedException: java.io.StreamCorruptedException: invalid type code: 41 at hudson.remoting.Request.abort(Request.java:273) at hudson.remoting.Channel.terminate(Channel.java:702) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.io.StreamCorruptedException: invalid type code: 41 at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at hudson.remoting.Command.readFrom(Command.java:90) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) This message is automatically generated by JIRA. 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-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
Johan-Kees Vliek commented on JENKINS-13835 upgrading Subversion Plugin to 1.40 totally ruined our CI server Hi, We have the same issue. This only seems to appear on Windows and not on Linux (as far as I can see). We use SVN 1.6, Jenkins 1.470 and SVN Plugin v1.40. We noticed that only new Jobs are affected. Existing jobs are not affected. Plz resolve this issue a.s.a.p. or advice on what to do. Many thanks!!! Regards, Johan-Kees This message is automatically generated by JIRA. 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-11939) Provide a way to add custom xdoc files to describe the checkstyle rules
jan_ruzicka commented on JENKINS-11939 Provide a way to add custom xdoc files to describe the checkstyle rules Would use of PHP Code Sniffer producing checkstyle reports be a case for using the xdoc files? Currently each entry shows "No description available. Please upgrade to latest checkstyle version.". Would the xdoc address this 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-14105) Build timeout plugin 1.9 always sets timeout period to 3 minutes
mwebber created JENKINS-14105 Build timeout plugin 1.9 always sets timeout period to 3 minutes Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: build-timeout Created: 14/Jun/12 2:46 PM Description: The Build Timeout plugin version 1.9 appears to rewrite the timeout period to 3 minutes, regardless of what is specified. Project: Jenkins Priority: Critical Reporter: mwebber This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14105) Build timeout plugin 1.9 always sets timeout period to 3 minutes
mwebber commented on JENKINS-14105 Build timeout plugin 1.9 always sets timeout period to 3 minutes Here are the two bug reports as seen on jenkinsci-users: Report 1 there is a significant bug in Build timeout plugin 1.9. I have job A, with a timeout of 3 minutes. A (using the parameterized plugin) does a "Trigger/call builds on other projects" to job B, which has a timeout of 60 minutes. A does not have "Block until the triggered projects finish their builds" specified. When I upgraded to Build timeout plugin 1.9, job B was timed out after 3 minutes, and when I looked, B's config had been rewritten to have a timeout of 3 minutes. Report 2 Seeing similar behavior. Actually, I'm seeing worse. Regardless of what value I specify, it looks like a 3 minute value is all that every gets saved. This message is automatically generated by JIRA. 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.
Gabe Dagani created JENKINS-14106 Rebuild is broken when coupled with Node Label plugin. Issue Type: Bug Affects Versions: current Assignee: domi Attachments: error.txt Components: nodelabelparameter, rebuild Created: 14/Jun/12 2:52 PM Description: An exception gets thrown when trying to use a Node-label parameter on a rebuild of an executed job. Basically it says: Status Code: 500 Exception: org.apache.commons.jelly.JellyTagException: file:/var/lib/jenkins/plugins/rebuild/WEB-INF/classes/com/sonyericsson/rebuild/RebuildAction/index.jelly:54:63: No page found 'LabelParameterValue.jelly' for class com.sonyericsson.rebuild.RebuildAction Environment: Ubuntu Project: Jenkins Labels: plugin exception Priority: Major Reporter: Gabe Dagani This message is automatically generated by JIRA. 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-14107) Unable to monitor external job in 1.470 (IllegalAccessError)
Chris Bailey created JENKINS-14107 Unable to monitor external job in 1.470 (IllegalAccessError) Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 14/Jun/12 2:59 PM Description: Installed clean Jenkins 1.470 and attempted to set up a remote job. After the job finished jenkins reports the following stacktrace. Eventually I cleaned the jenkins webapp dir and replaced with 1.447.2 (LTS) and the same job then ran fine. Started FATAL: tried to access field hudson.model.Run.charset from class hudson.model.ExternalRun$2 java.lang.IllegalAccessError: tried to access field hudson.model.Run.charset from class hudson.model.ExternalRun$2 at hudson.model.ExternalRun$2.run(ExternalRun.java:121) at hudson.model.Run.execute(Run.java:1460) at hudson.model.ExternalRun.acceptRemoteSubmission(ExternalRun.java:100) at hudson.model.ExternalJob.doPostBuildResult(ExternalJob.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:50) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardCo
[JIRA] (JENKINS-14109) Passing ${NODE_NAME} as Node Parameter to downstream job not possible on master
Dirk Kuypers
created JENKINS-14109
Passing ${NODE_NAME} as Node Parameter to downstream job not possible on master
Issue Type:
Bug
Affects Versions:
current
Assignee:
domi
Components:
nodelabelparameter
Created:
14/Jun/12 3:40 PM
Description:
We use the node label parameter plugin to pass the name of the node where the compile of a software project ran to the downstream jobs to build installlers, apply labels on the SCM and so on (to use the same workspace). Unfortunately this does not work if the compile job runs on master because ${NODE_NAME} is empty there. Is it possible to fix this somehow by having master as default if the passed string is empty f.i.? Or is there some other environment variable I could use for this purpose? If the master job runs on master the downstream jobs will wait forever looking for a node with label ""...
Project:
Jenkins
Priority:
Major
Reporter:
Dirk Kuypers
This message is automatically generated by JIRA.
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 updated JENKINS-14110 plugin download: http://updates.jenkins-ci.org/latest/github.hpi *not found* resulting in failed chef runs. Change By: Sloan Thompson (14/Jun/12 4:03 PM) Summary: plugin download: http://updates.jenkins-ci.org/latest/github.hpi *not found* resulting in failed chef runs. This message is automatically generated by JIRA. 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-12430) Git change trigger generate duplicate build
Paul Eipper commented on JENKINS-12430 Git change trigger generate duplicate build I have the same issue on Mac OSX Lion master (no slaves). Below is an example output. Note the difference of the Last Built Revision on console and on polling log of build #57, I don't know what would cause that. Build #56 Console #56: Started by an SCM change Started by an SCM change Started by an SCM change Started by an SCM change Building in workspace /Volumes/Overmind HD/Jenkins/Home/jobs/Example Project-Develop/workspace Checkout:workspace / /Volumes/Overmind HD/Jenkins/Home/jobs/Example Project-Develop/workspace - hudson.remoting.LocalChannel@53daed73 Using strategy: Default Last Built Revision: Revision e12107b73706720dd27ef14cd8702006464dc8e9 (origin/develop) Wiping out workspace first. Cloning the remote Git repository Cloning repository origin Fetching upstream changes from g...@example.com:example.git Commencing build of Revision 9de64a426e482ce08b3d869899a77de981316336 (origin/develop) Checking out Revision 9de64a426e482ce08b3d869899a77de981316336 (origin/develop) Working directory is /Volumes/Overmind HD/Jenkins/Home/jobs/Example Project-Develop/workspace. [workspace] $ /usr/bin/xcodebuild -version Xcode 4.3.2 Build version 4E2002 Polling Log #56: Started on Jun 14, 2012 2:28:53 PM Using strategy: Default [poll] Last Build : #55 [poll] Last Built Revision: Revision e12107b73706720dd27ef14cd8702006464dc8e9 (origin/develop) Done. Took 6.5 sec Changes found Git Build Data #56: Revision: 9de64a426e482ce08b3d869899a77de981316336 origin/develop Built Branches origin/develop: Build #56 of Revision 9de64a426e482ce08b3d869899a77de981316336 (origin/develop) Build #57 Console #57: Started by an SCM change Building in workspace /Volumes/Overmind HD/Jenkins/Home/jobs/Example Project-Develop/workspace Checkout:workspace / /Volumes/Overmind HD/Jenkins/Home/jobs/Example Project-Develop/workspace - hudson.remoting.LocalChannel@53daed73 Using strategy: Default Last Built Revision: Revision 9de64a426e482ce08b3d869899a77de981316336 (origin/develop) Wiping out workspace first. Cloning the remote Git repository Cloning repository origin Fetching upstream changes from g...@example.com:example.git Commencing build of Revision 9de64a426e482ce08b3d869899a77de981316336 (origin/develop) Checking out Revision 9de64a426e482ce08b3d869899a77de981316336 (origin/develop) Working directory is /Volumes/Overmind HD/Jenkins/Home/jobs/Example Project-Develop/workspace. [workspace] $ /usr/bin/xcodebuild -version Xcode 4.3.2 Build version 4E2002 Polling Log #57: Started on Jun 14, 2012 2:34:53 PM Using strategy: Default [poll] Last Build : #56 [poll] Last Built Revision: Revision e12107b73706720dd27ef14cd8702006464dc8e9 (origin/develop) Done. Took 4.4 sec Changes found Git Build Data #57: Revision: 9de64a426e482ce08b3d869899a77de981316336 origin/develop Built Branches origin/develop: Build #57 of Revision 9de64a426e482ce08b3d869899a77de981316336 (origin/develop) This message is automatically generated by JIRA. 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-13741) Malformed job XML when all executors are busy
Laura Neff resolved JENKINS-13741 as Fixed Malformed job XML when all executors are busy I upgraded my Jenkins from 1.460 to 1.470 and the problem disappeared. Didn't occur in 1.450 either. So somewhere between 450 and 460 it was broken, and somewhere between 460 and 470 was fixed. Change By: Laura Neff (14/Jun/12 6:48 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13007) Git plugin cannot find revision to build on Windows
Matt Todd commented on JENKINS-13007 Git plugin cannot find revision to build on Windows A little late, but we found a work around as well... Set the branch name to **/master or whatever your branch name is. This will work unless your Jenkins box uses multiple remotes. This message is automatically generated by JIRA. 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-13725) Bug encoding file
Andrey Myatlyuk resolved JENKINS-13725 as Cannot Reproduce Bug encoding file Was offered diagnostic procedure, no response from Alexandre, most likely environmental, closing the issue. Change By: Andrey Myatlyuk (14/Jun/12 7:46 PM) Status: Open Resolved Fix Version/s: current Resolution: Cannot Reproduce This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13541) Content Type of JSON API responses is not 'application/json'
Andrey Myatlyuk
resolved JENKINS-13541 as Fixed
Content Type of JSON API responses is not 'application/json'
Fixed in version 1.471
{{
Connection Keep-Alive
Content-Encoding gzip
Content-Length 313
Content-Type application/json;charset=UTF-8
Date Thu, 14 Jun 2012 19:39:10 GMT
Server Winstone Servlet Engine v0.9.10
X-Powered-By Servlet/2.5 (Winstone/0.9.10)
}}
Please verify.
Change By:
Andrey Myatlyuk
(14/Jun/12 7:49 PM)
Status:
Open
Resolved
Fix Version/s:
current
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-13541) Content Type of JSON API responses is not 'application/json'
Andrey Myatlyuk edited a comment on JENKINS-13541 Content Type of JSON API responses is not 'application/json' Fixed in version 1.471 Connection Keep-Alive Content-Encoding gzip Content-Length 313 Content-Type application/json;charset=UTF-8 Date Thu, 14 Jun 2012 19:39:10 GMT Server Winstone Servlet Engine v0.9.10 X-Powered-By Servlet/2.5 (Winstone/0.9.10) Please verify. This message is automatically generated by JIRA. 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-2556) Use svn switch where applicable
Josh Holding commented on JENKINS-2556 Use svn switch where applicable I'm surprised this issue is so old and not resolved yet. We just started using Jenkins not too long ago and ran into this right away. Would be great to have this 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-11786) Could we use masked password variable in Perforce Depot->Password
Richard Lee
commented on JENKINS-11786
Could we use masked password variable in Perforce Depot->Password
This is marked as fixed, but I am unable to get it to work. Is there some trick to how you specify the global variable? I have tried setting P4PASSWD in the global vars, as well as setting ${P4PASSWD} in the project perforce password field, and have tried other variable names other than P4PASSWD, all to no avail.
This message is automatically generated by JIRA.
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-12176) Unable to delete a job that has a fstrigger
Jim Searle resolved JENKINS-12176 as Fixed Unable to delete a job that has a fstrigger Looks like this is fixed now. Thanks for the support! Change By: Jim Searle (14/Jun/12 9:58 PM) 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-13694) Unable to "Add build step" under any circumstances
Andrey Myatlyuk resolved JENKINS-13694 as Cannot Reproduce Unable to "Add build step" under any circumstances No response from Aaditya, unable to reproduce, closing the issue. Change By: Andrey Myatlyuk (14/Jun/12 7:43 PM) Status: Open Resolved Resolution: Cannot Reproduce This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-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 I did some investigation into this, and here's what's going on: The Reload Configuration operation from the UI attempts to load up all the jobs and runs it can find. It loads runs from disk based on the presence of a build.xml in the directory for a particular build number (cf. RunMap.load()). Runs that are in progress do not have a build.xml written to the directory in the course of normal operations (problem #1). Attempt 1: write a piece of code that, at the start of the reload operation (Jenkins.reload()), looks at all running Executors and forces them to marshal their state to disk (creating a build.xml). This would then allow Jenkins to notice those jobs running when it restarts. Then I discovered that the unmarshal procedure for build.xml -> Run assumes that any build.xml it sees is for a run that is in State.COMPLETED. The State is not itself persisted as there's no getState() for xstream to call. Attempt 2: Make the State of a run persist appropriately so that it can be recovered when Jenkins reloads the configuration. This seems to work OK at least in limited tests, and I intend to put up a pull request to let people see the changes I'm proposing in the code. I do wonder, though, what the justification for doing it this way in the first place was; it seems likely that you would not in all cases want Jenkins to totally "trust" the state on disk when starting up, for example if there were a large time or configuration delta between the stop and start. I do, however, think that the specific case of mashing the "Reload Configuration" link should be able to assume that what was running before is still running. Things that could possibly go wrong now would mostly be in the arena of jobs that Jenkins now thinks are running but actually aren't anymore. In a reload case, you can probably expect that to happen minimally (if at all). Another idea I had was based on the fact that the executors clearly are reporting back the fact that they are running a particular job, even if Jenkins doesn't believe that run actually exists due to this bug. It might be possible/better to, instead of persisting everything to disk on the Jenkins master side, have it query the slaves for running jobs when it comes back up and use the information it gets from them to reconstruct its own idea of what is currently running. I don't know how people feel about potential for abuse there, given that it would require the master to "trust" the slaves to tell it what they were working on when it restarted. A combination of the two approaches might be best (trust, but verify). This message is automatically generated by JIRA. 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-13990) Polling find old already considered baselines
Bue Petersen commented on JENKINS-13990 Polling find old already considered baselines The issue is related to threading problems in our dependencies (praqmajutils and ClearCase Orienten Open Library). We are working on fixing these issues. WORK-ARROUND: There is a workarround for this polling issue: make sure to configure your Config Rotator jobs, so that only one job polls and start a build at the time. Eg. if job1 polls 10 minutes paste every hour, and a job1 build takes up to 10 minutes, than make sure job2 start polling 22 minutes past every hour. This message is automatically generated by JIRA. 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-14113) UnprotectedRootAction doesn't work for /github-webhook/
buckett created JENKINS-14113 UnprotectedRootAction doesn't work for /github-webhook/ Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 14/Jun/12 10:17 PM Description: At the moment the github plugin has it's github-webhook marked as being an UnprotectedRootAction which should mean that requests can be made to http://jenkins/github-webhook/ and even if security is enabled in jenkins they should make it through. To see this bug in action: Install jenkins Install the github plugin. Enable security, switch to matrix security, add a group called "authenticated" and grant them administer permission, remove all permissions from anonymous. Attempt to access http://jenkins/github-webhook/ in a browser that isn't logged into jenkins and you get prompted to login. Jenkins has special support for some URL paths in jenkins.model.Jenkins.getTarget() (eg http://jenkins/whoAmI), and it also contains support for UnprotectedRootAction. The problem is that the TokenList class which parses the URL and then rebuilds it when Stapler.getCurrentRequest().getRestOfPath() is called drops all trailing slashes from the returned path. So even if the request path ended /github-webhook/ the value returned from getRestOfPath() is always /github-webhook This then fails to match the test which requires the trailing slash. Project: Jenkins Priority: Major Reporter: buckett This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14110) http://updates.jenkins-ci.org/latest/github.hpi *not found* resulting in failed chef runs.
Sloan Thompson created JENKINS-14110 http://updates.jenkins-ci.org/latest/github.hpi *not found* resulting in failed chef runs. Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: ec2, github, plugin Created: 14/Jun/12 3:55 PM Description: After making some changes to our Jenkins chef recipe I redeployed to have it error out with: FATAL: Net::HTTPServerException: http_request[HEAD http://updates.jenkins-ci.org/latest/github.hpi] (jenkins::default line 70) had an error: Net::HTTPServerException: 404 "Not Found" It seems as though all the other http://updates.jenkins-ci.org/latest/"name" links are working fine; and trying to visit http://updates.jenkins-ci.org/latest/github.hpi for a direct download does result in a page not found on the browser. I've been able to reproduce the issue twice; once while reverting to a previous known working commit. Environment: Mac OS X Project: Jenkins Labels: plugin jenkins github Priority: Blocker Reporter: Sloan Thompson This message is automatically generated by JIRA. 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-13990) Polling find old already considered baselines
Bue Petersen edited a comment on JENKINS-13990 Polling find old already considered baselines The issue is related to threading problems in our dependencies (praqmajutils and ClearCase Orienten Open Library). We are working on fixing these issues. WORK-AROUND: There is a workaround for this polling issue: make sure to configure your Config Rotator jobs, so that only one job polls and start a build at the time. Eg. if job1 polls 10 minutes paste every hour, and a job1 build takes up to 10 minutes, than make sure job2 start polling 22 minutes past every hour. This message is automatically generated by JIRA. 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-14108) Multiple parameterized upstreams with joined in one "blocked while.." job result in multiple executions rather one only
Claus Schneider created JENKINS-14108 Multiple parameterized upstreams with joined in one "blocked while.." job result in multiple executions rather one only Issue Type: Bug Affects Versions: current Assignee: huybrechts Components: parameterized-trigger Created: 14/Jun/12 3:33 PM Description: Job setup: TestRoot - TestP1 - TestJoin - TestP2 / All of the jobs are configurated with parameterized string parameters in pre job and TestRoot, TestP1 and TestP2 uses "Trigger parameterized build on other projects" with file as input. The TestJoin is configurated with "Block while upstreams are build" The issue is as follows: The Jenkins build-in feature works ok and does not execute while jobs are building upstream, but the big problem is that the parameterized trigger kicks off two job executions(or as many as there are parallel upstream) rather than just one. It has been fine one this server when it was original configurated. At some point I moved some upstreams to join in a separated joiner. It seems that changing of configuration triggered the problem. The "funny" thing is that the problem occurs not only on the job I changed configuration but on all using the this setup. The test setup mentioned above is created after the problem occured and it still have the problem. I have updated the plugin to get the latest release, but it did not help on this problem. This is showstopper for me, as I cannot have more than one job execution due to the fact that I need one joined result of my whole "graph" and then continue further actions based on this.. I have not seen it earlier in my use of the this plugin. Due Date: 18/Jun/12 12:00 AM Environment: Linux: Jenkins release: 1.449 Project: Jenkins Labels: plugin plugins jenkins Priority: Blocker Reporter: Claus Schneider This message is automatically generated by JIRA. 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-13592) Details part of each ccm warning always displays all file
Marc Obrador updated JENKINS-13592 Details part of each ccm warning always displays all file Change By: Marc Obrador (14/Jun/12 11:14 AM) Attachment: jenkins ccm details modified.png Attachment: jenkins ccm error modified.png This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14102) Unstable main build leads to post steps being executed even if configured not to
Thomas Demande created JENKINS-14102 Unstable main build leads to post steps being executed even if configured not to Issue Type: Bug Affects Versions: current Assignee: abayer Components: m2-extra-steps Created: 14/Jun/12 12:43 PM Description: When a build "fails" due to test failures, and post steps are configured with the option "Run only if build succeeds", these post steps are still executed. (Jenkins 1.467) Project: Jenkins Priority: Major Reporter: Thomas Demande This message is automatically generated by JIRA. 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-10628) SCM build trigger not working correctly with variables in SVN URL
Alan Birtles commented on JENKINS-10628 SCM build trigger not working correctly with variables in SVN URL Any chance of getting Bela's patch merged in to Jenkins? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14112) The execution (build) of Project will fail on "mkdir" on remote disk.
Macpaul Lin
created JENKINS-14112
The execution (build) of Project will fail on "mkdir" on remote disk.
Issue Type:
Bug
Affects Versions:
current
Assignee:
samngms
Components:
filesystem_scm
Created:
14/Jun/12 4:50 PM
Description:
Hi,
I have a problem - which is almost the same problem of this issue
about mkdir/open files on remote disk.
Currently I'm using Jenkins ver. 1.467 and 1.470 with Windows XP 32bit.
When I want to checkout source code to remote disk whether it is on MAC OS
or Linux, I'll get mkdir fail.
I'm very sure java.exe, jenkins.exe, git.exe, p4.exe are executing as my
account in Windows XP.
And this account has right to read/write/mkdir/delete the files and
directories in the remote disk.
It seems this problem exists a very long time.
Started by user anonymous
Building in workspace Z:\PC12010025
java.io.IOException: Failed to mkdirs: Z:\PC12010025
at hudson.FilePath.mkdirs(FilePath.java:901)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1216)
at
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:587)
at
hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:476)
at hudson.model.Run.run(Run.java:1438)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at
hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:239)
Finished: FAILURE
There are other users encountered this problem like
http://serverfault.com/questions/308774/how-to-make-hudson-write-to-r...
And the relative source code in Jenkins is:
/**
Creates this directory.
*/
public void mkdirs() throws IOException, InterruptedException {
if(!act(new FileCallable() Unknown macro: { public Boolean invoke(File f, VirtualChannel channel) throws IOException, InterruptedException {
if(f.mkdirs() || f.exists())
return true;// OK
// following Ant task to avoid possible race
condition.
Thread.sleep(10);
return f.mkdirs() || f.exists();
} } ))
throw new IOException("Failed to mkdirs: "+remote);
}
Due Date:
22/Jun/12 12:00 AM
Environment:
Jenkins is installed on Windows System and trying to download code to a remote disk. And the disk is on a Linux or MAC system.
Project:
Jenkins
Priority:
Major
Reporter:
Macpaul Lin
This message is automatically generated by JIRA.
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-14113) UnprotectedRootAction doesn't work for /github-webhook/
buckett commented on JENKINS-14113 UnprotectedRootAction doesn't work for /github-webhook/ Fix in https://github.com/jenkinsci/jenkins/pull/498 This message is automatically generated by JIRA. 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-14100) Keep Android SDK updated automatically
candrews created JENKINS-14100 Keep Android SDK updated automatically Issue Type: Improvement Affects Versions: current Assignee: Christopher Orr Components: android-emulator Created: 14/Jun/12 4:24 AM Description: The plugin will automatically install the Android SDK if it isn't already installed on the slave. However, when new versions of the Android SDK and new APIs come out, they aren't automatically installed - so any build that attempts to use them will fail. For example, the plugin automatically installed the Android SDK, and at that time, the latest Android API was 14. Recently, a new project started, and it targetted SDK 15. The build failed for this project with this error: org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.2.0:generate-sources (default-generate-sources) on project callerid: Execution default-generate-sources of goal com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.2.0:generate-sources failed: Invalid SDK: Platform/API level 15 not available. This command should give you all you need: /home/jenkinsslave/data/tools/android-sdk/tools/android update sdk --no-ui --obsolete --force Running that command fixes the problem. All I'm saying is that this problem should be automatically resolved when it does happen, or it shouldn't happen at all. Thanks! Project: Jenkins Priority: Major Reporter: candrews This message is automatically generated by JIRA. 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
Stephane Odul commented on JENKINS-14105 Build timeout plugin 1.9 always sets timeout period to 3 minutes I see the same exact issue, I'm reverting the plugin to 1.8 for now. This message is automatically generated by JIRA. 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-14100) Keep Android SDK updated automatically
Christopher Orr commented on JENKINS-14100 Keep Android SDK updated automatically If you use the "Install Android project prerequisites" build step, any required Android platform images will be detected and installed automatically if not already available. I'd rather not update the SDK itself automatically, as often the SDK Tools component introduces build-breaking Ant changes. Is that sufficient? This message is automatically generated by JIRA. 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-14113) UnprotectedRootAction doesn't work for /github-webhook/
SCM/JIRA link daemon resolved JENKINS-14113 as Fixed UnprotectedRootAction doesn't work for /github-webhook/ Change By: SCM/JIRA link daemon (15/Jun/12 12:01 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-14113) UnprotectedRootAction doesn't work for /github-webhook/
SCM/JIRA link daemon commented on JENKINS-14113 UnprotectedRootAction doesn't work for /github-webhook/ Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/jenkins/model/Jenkins.java core/src/main/resources/hudson/model/EnvironmentContributor/EnvVarsHtml/index.groovy test/src/test/java/jenkins/model/JenkinsTest.java http://jenkins-ci.org/commit/jenkins/4e7a43c5863b5e7ad637a5034f75d3c144c45129 Log: [FIXED JENKINS-14113] The proposed fix https://github.com/buckett/jenkins/commit/eec16f1b6156aea76bd0cc6e0262538713ebffb6 has a problem in that it'd allow anything that has the given URL name as a prefix. This message is automatically generated by JIRA. 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-11786) Could we use masked password variable in Perforce Depot->Password
Richard Lee commented on JENKINS-11786 Could we use masked password variable in Perforce Depot->Password Tried it as a mask password, too. Doesn't work. Am using the latest versions of jenkins and the perforce plugin (1.470 and 1.3.15). Have you seen this actually work? It does not seem like it is doing parameter substitution in the password field of the perforce plugin for the jenkins job. It would be great if there were a way to print out what it thought the password were in the output to tell for sure, but it never gets far enough to run any of my build scripts. This message is automatically generated by JIRA. 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-14100) Keep Android SDK updated automatically
candrews commented on JENKINS-14100 Keep Android SDK updated automatically IMHO, it would be better to update the actual SDK. The SDK on my slave was too old to install API 15 (which my app via the Android Manifest requires), so the "Install Android project prerequisites" option didn't install it, and the build failed. This message is automatically generated by JIRA. 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-14113) UnprotectedRootAction doesn't work for /github-webhook/
dogfood commented on JENKINS-14113 UnprotectedRootAction doesn't work for /github-webhook/ Integrated in jenkins_main_trunk #1762 [FIXED JENKINS-14113] (Revision 4e7a43c5863b5e7ad637a5034f75d3c144c45129) Result = SUCCESS Kohsuke Kawaguchi : 4e7a43c5863b5e7ad637a5034f75d3c144c45129 Files : core/src/main/resources/hudson/model/EnvironmentContributor/EnvVarsHtml/index.groovy core/src/main/java/jenkins/model/Jenkins.java test/src/test/java/jenkins/model/JenkinsTest.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-11786) Could we use masked password variable in Perforce Depot->Password
Rob Petti
commented on JENKINS-11786
Could we use masked password variable in Perforce Depot->Password
Wait, no I just had something configured wrong. It seems to be working on my end... Can you provide as much detail as possible about your setup?
You might also want to test the replacement using the following groovy script console snippet:
project = Jenkins.instance.getItem("test");
build = project.getBuildByNumber(23);
scm = project.scm;
println(scm.getDecryptedP4Passwd(build));
depot = scm.getDepot(null,null,project,build,null);
println(depot.getPassword());
Replace "test" and "23" with the name of your job and the latest build number. It should print out your password as seen by p4.
This message is automatically generated by JIRA.
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-7013) Build fails to archive the artifacts
peter_schuetze reopened JENKINS-7013 Build fails to archive the artifacts Encountered this problem today. Windows 2003 Server SP2 Java 1.6 Jenkins 1.461 21:25:55 Caused by: Failed to copy D:\Hudson\jobs\OCNS_Release_build\workspace\ocns-fitnesse\ocns-fitnesse-fixtures\ocns-fitnesse-fixtures-ear\target\ocns-fitnesse-fixtures-ear-0.1.ear to D:\Hudson\jobs\OCNS_Release_build\builds\2012-06-14_20-20-27\archive\ocns-fitnesse\ocns-fitnesse-fixtures\ocns-fitnesse-fixtures-ear\target\ocns-fitnesse-fixtures-ear-0.1.ear due to Map failed 21:25:55 at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:914) 21:25:55 at hudson.FilePath$34$1CopyImpl.doFileOperations(FilePath.java:1672) 21:25:55 at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:567) 21:25:55 at hudson.FilePath$34.invoke(FilePath.java:1686) 21:25:55 ... 14 more 21:25:55 Caused by: java.io.IOException: Map failed 21:25:55 at sun.nio.ch.FileChannelImpl.map(Unknown Source) 21:25:55 at sun.nio.ch.FileChannelImpl.transferFromFileChannel(Unknown Source) 21:25:55 at sun.nio.ch.FileChannelImpl.transferFrom(Unknown Source) 21:25:55 at org.apache.tools.ant.util.ResourceUtils.copyResource(ResourceUtils.java:532) 21:25:55 at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:559) 21:25:55 at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:899) 21:25:55 ... 17 more 21:25:55 Caused by: java.lang.OutOfMemoryError: Map failed 21:25:55 at sun.nio.ch.FileChannelImpl.map0(Native Method) 21:25:55 ... 23 more 21:26:14 Notifying upstream projects of job completion 21:26:14 Finished: FAILURE Change By: peter_schuetze (15/Jun/12 3:05 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-7013) Build fails to archive the artifacts
peter_schuetze edited a comment on JENKINS-7013 Build fails to archive the artifacts Encountered this problem today. Windows 2003 Server SP2 Java 1.6 Jenkins 1.461 File mentioned below is 45 MB 21:25:55 Caused by: Failed to copy D:\Hudson\jobs\OCNS_Release_build\workspace\ocns-fitnesse\ocns-fitnesse-fixtures\ocns-fitnesse-fixtures-ear\target\ocns-fitnesse-fixtures-ear-0.1.ear to D:\Hudson\jobs\OCNS_Release_build\builds\2012-06-14_20-20-27\archive\ocns-fitnesse\ocns-fitnesse-fixtures\ocns-fitnesse-fixtures-ear\target\ocns-fitnesse-fixtures-ear-0.1.ear due to Map failed 21:25:55 at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:914) 21:25:55 at hudson.FilePath$34$1CopyImpl.doFileOperations(FilePath.java:1672) 21:25:55 at org.apache.tools.ant.taskdefs.Copy.execute(Copy.java:567) 21:25:55 at hudson.FilePath$34.invoke(FilePath.java:1686) 21:25:55 ... 14 more 21:25:55 Caused by: java.io.IOException: Map failed 21:25:55 at sun.nio.ch.FileChannelImpl.map(Unknown Source) 21:25:55 at sun.nio.ch.FileChannelImpl.transferFromFileChannel(Unknown Source) 21:25:55 at sun.nio.ch.FileChannelImpl.transferFrom(Unknown Source) 21:25:55 at org.apache.tools.ant.util.ResourceUtils.copyResource(ResourceUtils.java:532) 21:25:55 at org.apache.tools.ant.util.FileUtils.copyFile(FileUtils.java:559) 21:25:55 at org.apache.tools.ant.taskdefs.Copy.doFileOperations(Copy.java:899) 21:25:55 ... 17 more 21:25:55 Caused by: java.lang.OutOfMemoryError: Map failed 21:25:55 at sun.nio.ch.FileChannelImpl.map0(Native Method) 21:25:55 ... 23 more 21:26:14 Notifying upstream projects of job completion 21:26:14 Finished: FAILURE This message is automatically generated by JIRA. 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-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
