RE: important email 30/08/2012.
RE: important email 30/08/2012. My name is Mr. Daniel Tsai from Hong Kong. I need to discuss a business project with you of 44.5MUSD. Please reply back via my private e-mail Address for more details danieltsa...@yahoo.com.hk Or danielts...@aol.com thank you. Mr. Daniel Tsai.
[JIRA] (JENKINS-14989) NPE in WarningsResult.java: group is null
Ulli Hafner commented on JENKINS-14989 NPE in WarningsResult.java: group is null Can you please attach the stack trace? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14980) User unknown in Email leads to exception, making job failed
Martin Jost commented on JENKINS-14980 User unknown in Email leads to exception, making job failed In the response header I get: This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14980) User unknown in Email leads to exception, making job failed
Martin Jost edited a comment on JENKINS-14980 User unknown in Email leads to exception, making job failed In the response header I get: X-Hudson: 1.395 X-Jenkins: 1.454 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14991) Matrix jobs are kept forever even if it's not needed
vjuranek created JENKINS-14991 Matrix jobs are kept forever even if its not needed Issue Type: Bug Assignee: vjuranek Components: matrix Created: 30/Aug/12 2:44 PM Description: Matrix configurations can refer previous builds if given configuration didn't run. Such linked builds are marked as "keep forever" and cannot be deleted. Only linked build should be kept, but currently all builds among linking build and linked build are kept, even if it's not needed at all. Project: Jenkins Priority: Major Reporter: vjuranek This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14980) User unknown in Email leads to exception, making job failed
Slide-O-Mix commented on JENKINS-14980 User unknown in Email leads to exception, making job failed Sorry, I mean what version of the email-ext plugin? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6268) Make checking for modification time of junit results be configurable and off by default
Stanislav Tyurikov commented on JENKINS-6268 Make checking for modification time of junit results be configurable and off by default I have multi-module maven project, which rebuilds only changed modules. I want to display test results for old modules too. But this issue is a blocker for this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-6268) Make checking for modification time of junit results be configurable and off by default
Stanislav Tyurikov updated JENKINS-6268 Make checking for modification time of junit results be configurable and off by default Change By: Stanislav Tyurikov (30/Aug/12 2:56 PM) 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-5393) Hudson falsely fails builds due to aggressive up-to-date check on junit artifacts
Stanislav Tyurikov commented on JENKINS-5393 Hudson falsely fails builds due to aggressive up-to-date check on junit artifacts This is a stopper for some cases of build execution time optimization. I even can't imagine the reasons why this feature exists. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14992) Can add build other projects trigger to a project we cannot otherwise configure
jglick created JENKINS-14992 Can add build other projects trigger to a project we cannot otherwise configure Issue Type: Bug Assignee: Unassigned Components: core Created: 30/Aug/12 3:04 PM Description: Not sure if this is actually a bug or not. AbstractProject.doConfigSubmit modifies the publishersList of an upstream project regardless of your permissions on that project. I would expect that you would need to have CONFIGURE permission on it. Not clear that there is a specific security threat from adding a BuildTrigger to an arbitrary project, but it will at a minimum result in a config.xml change from an unauthorized user, which might raise eyebrows. BuildTrigger.DescriptorImpl.doCheck also ought to issue an error if you have no CONFIGURE permission. doAutoCompleteUpstreamProjects can probably be left alone - complete everything we can see but show an error if you cannot really touch it. Also doCheck neglects to check AbstractProject.isConfigurable as doConfigSubmit does. Project: Jenkins Labels: upstream security Priority: Minor Reporter: jglick This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14411) Build Flow jobs display “Post-build Actions” which are never saved
jglick updated JENKINS-14411 Build Flow jobs display “Post-build Actions” which are never saved Change By: jglick (30/Aug/12 3:09 PM) Summary: BuildFlowjobs notabletostartotherjobsin display“ Post- Build buildActions”whichareneversaved 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-14411) Build Flow jobs not able to start other jobs in Post-Build
jglick commented on JENKINS-14411 Build Flow jobs not able to start other jobs in Post-Build Reproducible. This applies to any of the publishers that appear in the Post-build Actions list as of pull request #15. The reason seems to be this bit of code in BuildFlow: @Override public DescribableListPublisher, DescriptorPublisher getPublishersList() { return new DescribableListPublisher,DescriptorPublisher(this); } In other words, as of pull #15 it pretends to support publishers, but the list is always empty regardless of what you do. Adding a post-build action to start another job to a Build Flow job does not make a lot of sense; it would be clearer and simpler to just add build('thatJob') to your script. However, if the option appears in the UI it ought to work. More to the point, if you configure a downstream job to use the “Build after other projects are built” trigger and point to a Build Flow project, you expect that to either work or report an error; currently it is offered as an option but has no effect, which is very confusing. Probably the fix is to copy Project.publishers into BuildFlow, returning it from getPublishersList, and editing/overriding various associated methods to match: onLoad, getResourceActivities, buildDependencyGraph, and most importantly submit. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14993) JDK auto-installer for OSX
cowwoc created JENKINS-14993 JDK auto-installer for OSX Issue Type: New Feature Affects Versions: current Assignee: Unassigned Components: core Created: 30/Aug/12 3:21 PM Description: In the past Oracle didn't support MacOS X, however as of JDK 7 update 6 this is no longer the case. When I run the JDK auto installer against an OSX machine I am getting "JDK installation skipped: Unknown CPU name: mac os x". Expected behavior: Add support for auto-installing Oracle's JDK on MacOS X. Environment: MacOS X 10.7 Project: Jenkins Priority: Major Reporter: cowwoc This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14994) Misleading documentation on tool auto-installers
cowwoc created JENKINS-14994 Misleading documentation on tool auto-installers Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 30/Aug/12 3:25 PM Description: Looking at https://wiki.jenkins-ci.org/display/JENKINS/Tool+Auto-Installation it's not clear which auto-installers are supported on which platforms. For example, there is no indication that the JDK and Mercurial installers are not supported on MacOS X. Perhaps you could put up a matrix of operating systems and tools. The intersection would indicate the version number that introduced support for that combination. Project: Jenkins Priority: Major Reporter: cowwoc This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14994) Misleading documentation on tool auto-installers
cowwoc commented on JENKINS-14994 Misleading documentation on tool auto-installers Another problem is that it's not clear how to configure different installers for different platforms. The help bubble reads "For a platform-independent tool (such as Ant), configuring multiple installers for a single tool makes not much sense, but for a platform dependent tool, multiple installer configurations allow you to run a different set up script depending on the slave environment." But when I configure JDK installers, there is no obvious way for me to indicate which installer should be used for which platform. Specifically, I wish to avoid the JDK auto-installer from running under OSX because it is currently unsupported and prints a warning message every 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-13604) On startup, Error injecting constructor, java.lang.NoClassDefFoundError: hudson/ivy/AntIvyBuildWrapper
cowwoc commented on JENKINS-13604 On startup, Error injecting constructor, java.lang.NoClassDefFoundError: hudson/ivy/AntIvyBuildWrapper This issue depends on https://issues.jfrog.org/jira/browse/HAP-268 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14995) Abuse of getDescriptor(ShortName)
jglick created JENKINS-14995 Abuse of getDescriptor(ShortName) Issue Type: Bug Assignee: jglick Components: core, parameterized-trigger Created: 30/Aug/12 3:42 PM Description: If you install the Parameterized Trigger plugin in an older version of Jenkins, you can get a 404 in the validation area for “Build after other projects are built”. This is because Jenkins.instance.getDescriptor('BuildTrigger') (used from the /job/downstream/descriptorByName/BuildTrigger/check?value=upstream URL) may return either a hudson.tasks.BuildTrigger.DescriptorImpl or a hudson.plugins.parameterizedtrigger.BuildTrigger.DescriptorImpl, apparently at random. 4d33b6a should have fixed this in core 1.480. However it would be better for this method to actively check for ambiguities so similar problems do not recur. Project: Jenkins Priority: Major Reporter: jglick This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14995) Abuse of getDescriptor(ShortName)
SCM/JIRA link daemon commented on JENKINS-14995 Abuse of getDescriptor(ShortName) Code changed in jenkins User: Jesse Glick Path: changelog.html http://jenkins-ci.org/commit/jenkins/4b64f13d3c2c754f988ebe472cd4e8d7839069eb Log: JENKINS-14995 Noting, retroactively. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14996) Jenkins does not find Mercurial that is on the PATH
cowwoc created JENKINS-14996 Jenkins does not find Mercurial that is on the PATH Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: mercurial Created: 30/Aug/12 4:07 PM Description: I have a Windows master node and Mac slave node. I installed Mercurial 2.3 myself on the Mac. The installer outputs the binaries into /usr/local/bin which is on my PATH. Invoking "hg" in a local terminal or over SSH (from Windows) works fine. However, when I run a task on the Mac that uses Mercurial I get: Building remotely on MacOS X 10.7 in workspace workspace JDK installation skipped: Unknown CPU name: mac os x $ hg clone --rev default --noupdate repository workspace ERROR: Failed to clone repository because hg could not be found; check that you've properly configured your Mercurial installation ERROR: Failed to clone repository I suspect this is failing because Jenkins is configured to auto-install Mercurial to "INSTALLATION/bin/hg" and run it from there but it does not because (apparently) Mercurial auto-installation is not supported for OSX. Expected behavior: Invoke "hg" off the PATH on platforms that do not support auto-installer. Environment: MacOS X 10.7 Project: Jenkins Priority: Major Reporter: cowwoc This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14996) Jenkins does not find Mercurial that is on the PATH
cowwoc commented on JENKINS-14996 Jenkins does not find Mercurial that is on the PATH Additionally, I would update the error message so any time "hg" could not be found it outputs the full command-line it tried executing. It took me a very long time to figure out what was wrong because I couldn't see the command-line. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14755) Mail address resolution can take a significant amount of time
jfigler commented on JENKINS-14755 Mail address resolution can take a significant amount of time Just to follow up on bbonn's comment, we were finally able to figure this out in our environment. We began experiencing this problem when we upgraded our Jenkins core from 1.424.6 to 1.447.2. We were using Email Ext version 1.8 at the time. We updated to the latest Email Ext (2.24.1) with no luck. Then we updated our Active Directory plug-in from version 1.6 to 2.9, again with no luck. Finally, in the main configuration for the AD plug-in we removed our domain name from the advanced configuration. For us, that's what got our configuration of Jenkins resolving email addresses normally again. I doubt the email-ext plug-in is even related in our case. I have NOT proven that out, but I'm assuming that if we had kept our email ext plug-in version on 1.8 but made all the other changes, we would have had success there as well. Just in case anyone has a similar setup, this is what worked for us. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14995) Abuse of getDescriptor(ShortName)
dogfood commented on JENKINS-14995 Abuse of getDescriptor(ShortName) Integrated in jenkins_main_trunk #1878 JENKINS-14995 Noting, retroactively. (Revision 4b64f13d3c2c754f988ebe472cd4e8d7839069eb) Result = UNSTABLE Jesse Glick : 4b64f13d3c2c754f988ebe472cd4e8d7839069eb Files : changelog.html This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14995) Abuse of getDescriptor(ShortName)
SCM/JIRA link daemon commented on JENKINS-14995 Abuse of getDescriptor(ShortName) Code changed in jenkins User: Jesse Glick Path: changelog.html core/src/main/java/jenkins/model/Jenkins.java http://jenkins-ci.org/commit/jenkins/680649f6b5ee8d565645c0e3727fe731a40c5a92 Log: FIXED JENKINS-14995 Fail consistently when getDescriptor is called with an ambiguous short name. Compare: https://github.com/jenkinsci/jenkins/compare/aa164da18aed...680649f6b5ee This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14995) Abuse of getDescriptor(ShortName)
SCM/JIRA link daemon resolved JENKINS-14995 as Fixed Abuse of getDescriptor(ShortName) Change By: SCM/JIRA link daemon (30/Aug/12 4:56 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-10823) Add more config values (and plugin configs)
Jacob Robertson resolved JENKINS-10823 as Fixed Add more config values (and plugin configs) Resolving - if anyone wants any of these specific features, please open a specific ticket. We're not using JIRA the way it's intended. Change By: Jacob Robertson (30/Aug/12 5: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-10823) Add more config values (and plugin configs)
Jacob Robertson closed JENKINS-10823 as Fixed Add more config values (and plugin configs) Change By: Jacob Robertson (30/Aug/12 5:48 PM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14755) Mail address resolution can take a significant amount of time
Slide-O-Mix commented on JENKINS-14755 Mail address resolution can take a significant amount of time @bbonn, this would have nothing to do with going back a version, the email address resolution has been around for a long time. What version were you using previously that did not show the 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-14995) Abuse of getDescriptor(ShortName)
dogfood commented on JENKINS-14995 Abuse of getDescriptor(ShortName) Integrated in jenkins_main_trunk #1879 FIXED JENKINS-14995 Fail consistently when getDescriptor is called with an ambiguous short name. (Revision 680649f6b5ee8d565645c0e3727fe731a40c5a92) Result = SUCCESS Jesse Glick : 680649f6b5ee8d565645c0e3727fe731a40c5a92 Files : changelog.html core/src/main/java/jenkins/model/Jenkins.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-14966) Jobs takes forever on subversion plugin calculating culprits
SCM/JIRA link daemon commented on JENKINS-14966 Jobs takes forever on subversion plugin calculating culprits Code changed in jenkins User: takeuchi Path: src/main/java/hudson/scm/SubversionMailAddressResolverImpl.java http://jenkins-ci.org/commit/subversion-plugin/b3646e48d571945465bdb33fc8163b168d892a65 Log: Revert "JENKINS-14966 Aplying the same fix as in https://github.com/jenkinsci/perforce-plugin/commit/414cd9f0a6409b46eef58d1229953e5093daa940" Reverting due to Jesse's observation that this is done in a wrong manner. This reverts commit 1fe9344144d3c95ed473a274ab40ab347c09bffa. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14966) Jobs takes forever on subversion plugin calculating culprits
taksan commented on JENKINS-14966 Jobs takes forever on subversion plugin calculating culprits Well, I reverted the change and Jesse suggested a way to do that. Anyway, the current MailResolver implemented by the subversion plugin performance is unacceptable in environments where you have hundreds of jobs and users and more than 100,000 builds. We found a workaround for this problem, which is fill all users mails manually, to avoid letting jenkins use subversion's mail resolver. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14997) People page takes forever and times out because of subversion plugin scanning all projects
taksan updated JENKINS-14997 People page takes forever and times out because of subversion plugin scanning all projects Change By: taksan (30/Aug/12 6:21 PM) Description: Wehavearound400jobsandliterally hundrends hundreds ofthousandsofbuilds.Whenwetrytoopenthepeoplepageittakesforeverandtimesout.Wefoundthatthepeoplepagewastryingtogetsomesubversioninformation(probablythelastprojectonwhicheachusercommited)andbecausewehavetoomanyjobsittakesforevertocomputethisinformation.Heresthestacktracewhileattemptingtoloadthepage:HandlingGET/hudson/view/All-Simple/people/:RequestHandlerThread[#386]Id=3680Group=mainRUNNABLE atjava.io.UnixFileSystem.getBooleanAttributes0(NativeMethod) atjava.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228) atjava.io.File.exists(File.java:733) athudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:828) athudson.model.AbstractBuild.getChangeSet(AbstractBuild.java:806) athudson.model.View$People.getUserInfo(View.java:667) athudson.model.View$People.init(View.java:657) athudson.model.View.getPeople(View.java:632) atsun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethod) atsun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) atsun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) atjava.lang.reflect.Method.invoke(Method.java:597) atorg.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) atorg.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203) atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659) atorg.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) atorg.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) atorg.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:659) atorg.kohsuke.stapler.Stapler.invoke(Stapler.java:488) atorg.kohsuke.stapler.Stapler.service(Stapler.java:162) atjavax.servlet.http.HttpServlet.service(HttpServlet.java:45) atwinstone.ServletConfiguration.execute(ServletConfiguration.java:248) atwinstone.RequestDispatcher.forward(RequestDispatcher.java:333) atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) athudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) athudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194) atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) athudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) atwinstone.FilterConfiguration.execute(FilterConfiguration.java:194) atwinstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) athudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atjenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) athudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) atorg.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
[JIRA] (JENKINS-14997) People page takes forever and times out because of subversion plugin scanning all projects
taksan created JENKINS-14997 People page takes forever and times out because of subversion plugin scanning all projects Issue Type: Bug Assignee: Unassigned Components: subversion Created: 30/Aug/12 6:20 PM Description: We have around 400 jobs and literally hundrends of thousands of builds. When we try to open the "people page" it takes forever and times out. We found that the people page was trying to get some subversion information (probably the last project on which each user commited) and because we have too many jobs it takes forever to compute this information. Here's the stacktrace while attempting to load the page: "Handling GET /hudson/view/All-Simple/people/ : RequestHandlerThread386" Id=3680 Group=main RUNNABLE at java.io.UnixFileSystem.getBooleanAttributes0(Native Method) at java.io.UnixFileSystem.getBooleanAttributes(UnixFileSystem.java:228) at java.io.File.exists(File.java:733) at hudson.model.AbstractBuild.calcChangeSet(AbstractBuild.java:828) at hudson.model.AbstractBuild.getChangeSet(AbstractBuild.java:806) at hudson.model.View$People.getUserInfo(View.java:667) at hudson.model.View$People.init(View.java:657) at hudson.model.View.getPeople(View.java:632) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$6.doDispatch(MetaClass.java:241) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at
[JIRA] (JENKINS-14998) Cannot do si comands from shell or batch file (MKS Integrity CLI)
Abimael Pena created JENKINS-14998 Cannot do si comands from shell or batch file (MKS Integrity CLI) Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: adaptiveplugin Created: 30/Aug/12 6:22 PM Description: In plugin, I do the following command either from a shell or batch: si about I get the following error: si: Attempt to launch MKS Integrity Client Timed out. To solve this please try the following: Verify that the user you are logged in as has read and write permissions to the Integrity Client install directory. Make sure the Integrity Client install directory is the very first entry in the path. I am not using the Local System Account. This was changed to the user account used to log on to MKS Integrity. This was verified by checking the Jenkins Service from services.msc. I also went to my Integrity Client install directory. I can read and write here. I also added the Integrity Client install directory to my PATH environment variable. Environment: Windows 7, 64-bit (Both Jenkins 1.477 and 1.478) Project: Jenkins Labels: plugin Priority: Major Reporter: Abimael Pena This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14999) Copy Artifact plugin: Unable to find project for artifact copy when using a build parameter
Martin dAnjou created JENKINS-14999 Copy Artifact plugin: Unable to find project for artifact copy when using a build parameter Issue Type: Bug Affects Versions: current Assignee: Alan Harder Attachments: copy-artifact-shot1.png, copy-artifact-shot2.png Components: copyartifact Created: 30/Aug/12 6:59 PM Description: Error message: ... project_name=daily _=/bin/env Unable to find project for artifact copy: daily This may be due to incorrect project name or permission settings; see help for project name in job configuration. Build step 'Copy artifacts from another project' marked build as failure ... When I set the project name by hand, there is no error. When I use a build parameter, and set its value to the same value as the hand typed value, it fails. The above message show what variable I use: $project_name Please see the screenshots for the configuration details. Project: Jenkins Priority: Critical Reporter: Martin dAnjou This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14999) Copy Artifact plugin: Unable to find project for artifact copy when using a build parameter
Martin dAnjou edited a comment on JENKINS-14999 Copy Artifact plugin: Unable to find project for artifact copy when using a build parameter After reading more closely the help, I decided to upload another image, this time showing global project permissions. There is no per-project permissions. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14999) Copy Artifact plugin: Unable to find project for artifact copy when using a build parameter
Martin dAnjou updated JENKINS-14999 Copy Artifact plugin: Unable to find project for artifact copy when using a build parameter Project permissions Change By: Martin dAnjou (30/Aug/12 7:14 PM) Attachment: copy-artifact-shot3.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-15000) Java auto-installer corrupts PATH environment variable
cowwoc created JENKINS-15000 Java auto-installer corrupts PATH environment variable Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: core Created: 30/Aug/12 8:46 PM Description: Enable the JDK auto-installer in the master node. Add an OSX slave node. Execute a task in the slave node that executes "echo $PATH" The output log reads: JDK installation skipped: Unknown CPU name: mac os x ...snip... echo 'C:\Program' 'Files\Java\jdk1.7.0_06/bin:/usr/bin:/bin:/usr/sbin:/sbin' C:\Program Files\Java\jdk1.7.0_06/bin:/usr/bin:/bin:/usr/sbin:/sbin Expected behavior: Check if the operating system is supported before modifying PATH. If the auto-installer fails, revert PATH to its original value. Workaround: Define a new JDK type with auto-install disabled and use this for all OSX tasks. Environment: MacOS X 10.7 slave Project: Jenkins Priority: Major Reporter: cowwoc This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15001) Repository cache is wrong on slave nodes
cowwoc created JENKINS-15001 Repository cache is wrong on slave nodes Issue Type: Bug Affects Versions: current Assignee: Kohsuke Kawaguchi Components: mercurial Created: 30/Aug/12 8:54 PM Description: Install a Windows master node and OSX slave node. Invoke a task on the slave with Mercurial "repository caching" enabled. I get this output: $ /usr/local/bin/hg clone --noupdate repository C:\Users\Gili\.jenkins\hgcache\37CF2BD3BA29C01DED84F6376395B553ABB57E93-vtlr ERROR: Failed to use repository cache for repository java.io.IOException: Cannot run program "/usr/local/bin/hg": CreateProcess error=2, The system cannot find the file specified at java.lang.ProcessBuilder.start(Unknown Source) at hudson.Proc$LocalProc.init(Proc.java:244) at hudson.Proc$LocalProc.init(Proc.java:216) at hudson.Launcher$LocalLauncher.launch(Launcher.java:709) at hudson.Launcher$ProcStarter.start(Launcher.java:338) at hudson.Launcher$ProcStarter.join(Launcher.java:345) at hudson.plugins.mercurial.MercurialSCM.joinWithPossibleTimeout(MercurialSCM.java:309) at hudson.plugins.mercurial.Cache.repositoryCache(Cache.java:103) at hudson.plugins.mercurial.MercurialSCM.cachedSource(MercurialSCM.java:687) at hudson.plugins.mercurial.MercurialSCM.clone(MercurialSCM.java:558) at hudson.plugins.mercurial.MercurialSCM.checkout(MercurialSCM.java:390) at hudson.model.AbstractProject.checkout(AbstractProject.java:1256) 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:1502) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: java.io.IOException: CreateProcess error=2, The system cannot find the file specified at java.lang.ProcessImpl.create(Native Method) at java.lang.ProcessImpl.init(Unknown Source) at java.lang.ProcessImpl.start(Unknown Source) ... 19 more $ /usr/local/bin/hg clone --rev default --noupdate repository workspace adding changesets adding manifests adding file changes added 5 changesets with 154 changes to 103 files ...snip... I see two problems with this output: The "hgcache" path being defined relative to the master node's root directory instead of the root directory of the slave. There is no way this will work. ProcessBuilder complains it can't run "/usr/local/bin/hg" because "The system cannot find the file specified". I believe it finds "hg" because I've confirmed the path exists and the log clearly shows "hg clone" working. Please modify the code to output more verbose information (what is the working directory and full path associated with ProcessBuilder?) Environment: MacOS X 10.7 Project: Jenkins Priority: Major Reporter: cowwoc This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15002) Parameterized trigger passes no parameters from Ivy Prioject
Darren Rowley updated JENKINS-15002 Parameterized trigger passes no parameters from Ivy Prioject Change By: Darren Rowley (30/Aug/12 9:05 PM) Description: Ifyou use theparameterizedtriggerpluginwithanIvyProjectalthoughthedownstreamprojecttriggersparamtersarenotpassed.Iconvertedmyprojecttoaregularfreestyle softwarae software projectanditworks.Imtryingtopassthebuildnumbertoadownstreamproject. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15002) Parameterized trigger passes no parameters from Ivy Prioject
Darren Rowley created JENKINS-15002 Parameterized trigger passes no parameters from Ivy Prioject Issue Type: Bug Affects Versions: current Assignee: Timothy Bingaman Components: ivy, parameterized-trigger Created: 30/Aug/12 9:04 PM Description: If you the parameterized trigger plugin with an Ivy Project although the downstream project triggers paramters are not passed. I converted my project to a regular free style softwarae project and it works. I'm trying to pass the build number to a downstream project. Environment: Scientic linux Project: Jenkins Priority: Major Reporter: Darren Rowley This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15002) Parameterized trigger passes no parameters from Ivy Prioject
Darren Rowley updated JENKINS-15002 Parameterized trigger passes no parameters from Ivy Prioject Change By: Darren Rowley (30/Aug/12 9:12 PM) Environment: Scienticlinux (RHELbinarycompatible) Description: IfyouusetheparameterizedtriggerpluginwithanIvyProjectalthoughthedownstreamprojecttriggersparamtersarenotpassed.Iconvertedmyprojecttoaregularfreestylesoftwareprojectanditworks.Imtryingtopassthebuildnumbertoadownstreamproject. note:Iamusedthepredefinedparamtersoption(2params)intheparameterizedtriggerifthismakesadifference. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15003) Track and verify plugins mentioned in configuration XML
jglick created JENKINS-15003 Track and verify plugins mentioned in configuration XML Issue Type: New Feature Assignee: jglick Components: core Created: 30/Aug/12 9:50 PM Description: Many jobs or other model objects require certain plugins. This should be represented in the actual config.xml, e.g. builders org.jenkinsci.plugins.hello.HelloWorldBuilder plugin="hello 1.5" idiosyncraticConfig/ /org.jenkinsci.plugins.hello.HelloWorldBuilder /builders (XML namespaces would in some ways be natural for this, but XStream probably is more comfortable with a simple attribute on the outermost element “owned” by a plugin.) Need to make XmlFile.write insert these attributes as it serializes configuration, perhaps by making it take some interface implemented by PluginManager mapping Class to String shortName × String version. JRubyXStreamConverter might be used for inspiration. onLoad can either ignore these attributes, or use them as hints—for example, silently ignoring deserialization failures from a section owned by a plugin which is not currently loaded. Web methods like doCreateItem and doConfigDotXml, and their corresponding Java methods like createProjectFromXML and updateByXml, can be left alone, but a caller needs some way of first checking whether all required plugins are present, and attempting to install them if not. So there needs to be a web method on Jenkins and a corresponding Java method which can be given an arbitrary XML file and will return: OK, if all plugins mentioned therein are present. (Perhaps also check versions.) A security error, if caller is missing ADMINISTER permission. Or a list of jobs given as UpdateCenterJob.id (introduced in a3e57da) indicating ongoing progress of installing (or updating?) plugins, and perhaps even restarting Jenkins (trackable as of a3e57da) for those plugins which require it. May also want some higher-level convenience interface, e.g. in CLI, to validate XML and wait for all update center jobs to complete. Project: Jenkins Labels: plugin xml api Priority: Major Reporter: jglick This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14930) Can't overload/update PYTHONPATH
SCM/JIRA link daemon commented on JENKINS-14930 Cant overload/update PYTHONPATH Code changed in jenkins User: Gregory Boissinot Path: src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectEnvVars.java http://jenkins-ci.org/commit/envinject-plugin/9abab6b3d9a7c6c8850dc1ac33d7976aab5ac718 Log: Fix JENKINS-14930 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15002) Parameterized trigger passes no parameters from Ivy Prioject
Timothy Bingaman commented on JENKINS-15002 Parameterized trigger passes no parameters from Ivy Prioject Not sure if it is related, but someone else added something to the Ivy Plugin related to parameters a while back. In the Ivy Project configuration, go to the Ivy Module Configuration section, expand the bottom-most Advanced section, and check the Use parameters from upstream builds. See if that does anything for you and let me know how it goes. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14930) Can't overload/update PYTHONPATH
Gregory Boissinot started work on JENKINS-14930 Cant overload/update PYTHONPATH Change By: Gregory Boissinot (30/Aug/12 10:53 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-14930) Can't overload/update PYTHONPATH
Gregory Boissinot commented on JENKINS-14930 Cant overload/update PYTHONPATH Please could you check if this new SNAPSHOT Jenkins plugin fix the issue: https://buildhive.cloudbees.com/job/jenkinsci/job/envinject-plugin/49/org.jenkins-ci.plugins$envinject/ This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14934) JENKINS-11366 (takes up too much space in /var/run) still not fixed in version 1.447
Antony Lees commented on JENKINS-14934 JENKINS-11366 (takes up too much space in /var/run) still not fixed in version 1.447 Hmm strange as this was a new install, not an upgrade, so there is definitely something wrong with that version of 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-14934) JENKINS-11366 (takes up too much space in /var/run) still not fixed in version 1.447
Antony Lees edited a comment on JENKINS-14934 JENKINS-11366 (takes up too much space in /var/run) still not fixed in version 1.447 Hmm strange as this was a new install, not an upgrade, so there is definitely something wrong with that version of Jenkins Basically all I did was: sudo apt-get install jenkins on a totally clean install of raspbian. It failed to start up for the reason I highlighted above This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14934) JENKINS-11366 (takes up too much space in /var/run) still not fixed in version 1.447
Antony Lees edited a comment on JENKINS-14934 JENKINS-11366 (takes up too much space in /var/run) still not fixed in version 1.447 Hmm strange as this was a new install, not an upgrade, so there is definitely something wrong with that version of Jenkins Basically all I did was: sudo apt-get install jenkins It failed to start up for the reason I highlighted above This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14569) PATH is not being injected correctly
Gregory Boissinot commented on JENKINS-14569 PATH is not being injected correctly I'm sorry for not getting back to you sooner. >From an Unix environment, I can't reproduce the problem. Could you attach your job configuration file, maybe I missed something. More information 1) EnvInject plugin distinguishes PATH from Path from Windows because it is written in Java and I don't take in consideration of that at the moment. 2) If you don't use EnvInject, nothing is modified. It is not intrusive. Therefore, I don't understand your remark This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14144) Build config history getting spammed
Gregory Boissinot commented on JENKINS-14144 Build config history getting spammed I'm sorry for not getting back to you sooner. EnvInject plugin changes the job configuration file during the build: add a build wrapper at startup and remove it at the end. It is a way to the envinject to achieve specific features (no other way to do it at the moment). However, Jenkins saves its changes to the filesystem though the config.xml. I'm looking for how to remove notifications. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12513) git plugin should automatically remove .git/index.lock if the job is killed
Benny Chew commented on JENKINS-12513 git plugin should automatically remove .git/index.lock if the job is killed Was wondering on the progress of this issue.. we get this issue when the job is aborted when git is executing. The workaround works, but I guess isn't ideal as it would've to be added to every job separately (and would require separate delete commands for linux/windows). Cheers! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15004) Collecting findbugs analysis files
King Hpd created JENKINS-15004 Collecting findbugs analysis files Issue Type: Bug Affects Versions: current Assignee: Ulli Hafner Components: findbugs Created: 31/Aug/12 2:07 AM Description: FINDBUGS Collecting findbugs analysis files... hudson.util.IOException2: remote file operation failed: /mnt/disk/jenkins/ci at hudson.remoting.Channel@6254a79a:10.95.54.115 at hudson.FilePath.act(FilePath.java:828) at hudson.FilePath.act(FilePath.java:814) at com.huawei.jenkins.plugins.FindBugsPublisher.perform(FindBugsPublisher.java:286) at hudson.plugins.analysis.core.HealthAwarePublisher.perform(HealthAwarePublisher.java:357) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:749) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:682) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627) at hudson.model.Run.run(Run.java:1445) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) Caused by: java.io.IOException: Remote call on 10.95.54.115 failed at hudson.remoting.Channel.call(Channel.java:655) at hudson.FilePath.act(FilePath.java:821) ... 13 more Caused by: java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133) at hudson.remoting.UserRequest._serialize(UserRequest.java:156) at hudson.remoting.UserRequest.serialize(UserRequest.java:164) at hudson.remoting.UserRequest.perform(UserRequest.java:126) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Due Date: 31/Aug/12 12:00 AM Environment: jenkins 1.458 findbugs 4.43 Fix Versions: current Project: Jenkins Priority: Major Reporter: King Hpd This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15002) Parameterized trigger passes no parameters from Ivy Prioject
Darren Rowley commented on JENKINS-15002 Parameterized trigger passes no parameters from Ivy Prioject Thanks for the quick response Timothy we tried this still doesn't work, even the hard coded predefined parameters don't get sent through... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15002) Parameterized trigger passes no parameters from Ivy Prioject
Timothy Bingaman commented on JENKINS-15002 Parameterized trigger passes no parameters from Ivy Prioject So what is the exact setup that is failing? You have one Ivy Project that is triggering another Ivy Project? Or an Ivy Project that is triggering a Freestyle Project? And what exactly do you have in the predefined parameters box? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira