[JIRA] (JENKINS-7813) Archiving artifacts very slow
[ https://issues.jenkins-ci.org/browse/JENKINS-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160354#comment-160354 ] Mike Pontillo edited comment on JENKINS-7813 at 3/17/12 5:46 AM: - My workaround: I added a conditional SFTP to the Jenkins server inside my build script (depending on the status of the Jenkins environment variables). It's a hack.. I wish this worked normally. was (Author: mpontillo): My workaround: I added a conditional SFTP to the Jenkins server, depending on the status of the Jenkins environment variables. > Archiving artifacts very slow > - > > Key: JENKINS-7813 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7813 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Fedora 10 x86_64 Master, Win7 32bit Slave >Reporter: gtuhl > > We are running 1.380. I can watch a 300MB tarball get transferred to the > Hudson master slowly over 30+ minutes. An scp between the same machines and > same files/directories takes less than 3 minutes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7813) Archiving artifacts very slow
[ https://issues.jenkins-ci.org/browse/JENKINS-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160354#comment-160354 ] Mike Pontillo commented on JENKINS-7813: My workaround: I added a conditional SFTP to the Jenkins server, depending on the status of the Jenkins environment variables. > Archiving artifacts very slow > - > > Key: JENKINS-7813 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7813 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Fedora 10 x86_64 Master, Win7 32bit Slave >Reporter: gtuhl > > We are running 1.380. I can watch a 300MB tarball get transferred to the > Hudson master slowly over 30+ minutes. An scp between the same machines and > same files/directories takes less than 3 minutes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13108) Removing P4CONFIG file on cleaning workspace
[ https://issues.jenkins-ci.org/browse/JENKINS-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160353#comment-160353 ] dogfood commented on JENKINS-13108: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_perforce #201|http://ci.jenkins-ci.org/job/plugins_perforce/201/] [FIXED JENKINS-13108] exclude p4config file from wipe on checkout (Revision 7c0c24c8a2f4c65a2ac8046533c2adf093a1cb27) Result = SUCCESS Rob Petti : Files : * src/main/java/hudson/plugins/perforce/PerforceSCM.java > Removing P4CONFIG file on cleaning workspace > > > Key: JENKINS-13108 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13108 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current >Reporter: Alexey Larsky >Assignee: Rob Petti > > Cleaning workspace causing to remove local workspace config file. > http://www.perforce.com/perforce/doc.current/manuals/cmdref/env.P4CONFIG.html > http://www.jetbrains.com/idea/webhelp/using-multiple-perforce-depots-with-p4config.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13109) Huge changelogs eat all the Java memory
[
https://issues.jenkins-ci.org/browse/JENKINS-13109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160352#comment-160352
]
Rob Petti commented on JENKINS-13109:
-
Limiting the number of files is probably the easiest option here. Though
another option is to somehow stream the information from disk on-demand, rather
than deserializing the entire thing into the heap.
For now, what would a good limit be?
> Huge changelogs eat all the Java memory
> ---
>
> Key: JENKINS-13109
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13109
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
> Environment: Windows Server 2008 HPC Edition
> 64-bit JVM 1.6.0_29
> Running Jenkins service with "-Xrs -Xmx2048m
> -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar
> "%BASE%\jenkins.war" --httpPort=8080"
>Reporter: Mikko Tapaninen
>
> With really huge changelists the p4 plugin can run out of java heap space. At
> least it looks like the reason for memory problems would be huge
> changelog.xml files. An example case:
> - a changelist with > 40 files
> - results in a changelog.xml size > 110MB
> - Jenkins runs out of memory: {{java.lang.OutOfMemoryError: Java heap space}}
> Maybe there should be an option to limit the amount of files that p4 plugin
> reads to from changelists?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13108) Removing P4CONFIG file on cleaning workspace
[ https://issues.jenkins-ci.org/browse/JENKINS-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13108. Resolution: Fixed > Removing P4CONFIG file on cleaning workspace > > > Key: JENKINS-13108 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13108 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current >Reporter: Alexey Larsky >Assignee: Rob Petti > > Cleaning workspace causing to remove local workspace config file. > http://www.perforce.com/perforce/doc.current/manuals/cmdref/env.P4CONFIG.html > http://www.jetbrains.com/idea/webhelp/using-multiple-perforce-depots-with-p4config.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13108) Removing P4CONFIG file on cleaning workspace
[ https://issues.jenkins-ci.org/browse/JENKINS-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160351#comment-160351 ] SCM/JIRA link daemon commented on JENKINS-13108: Code changed in jenkins User: Rob Petti Path: src/main/java/hudson/plugins/perforce/PerforceSCM.java http://jenkins-ci.org/commit/perforce-plugin/7c0c24c8a2f4c65a2ac8046533c2adf093a1cb27 Log: [FIXED JENKINS-13108] exclude p4config file from wipe on checkout note: Jenkins' built-in wipe out workspace functionality is not affected, and will still wipe the entire workspace (outside the scope of the p4 plugin) > Removing P4CONFIG file on cleaning workspace > > > Key: JENKINS-13108 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13108 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current >Reporter: Alexey Larsky >Assignee: Rob Petti > > Cleaning workspace causing to remove local workspace config file. > http://www.perforce.com/perforce/doc.current/manuals/cmdref/env.P4CONFIG.html > http://www.jetbrains.com/idea/webhelp/using-multiple-perforce-depots-with-p4config.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13120) Extend criteria for current regression/improvement triggers
Steve A. created JENKINS-13120: -- Summary: Extend criteria for current regression/improvement triggers Key: JENKINS-13120 URL: https://issues.jenkins-ci.org/browse/JENKINS-13120 Project: Jenkins Issue Type: Improvement Components: email-ext Reporter: Steve A. The current criteria for the regression/improvement triggers is based on failure stats only (e.g., regression triggers if number of failures has increased since last build). However, would like to extend this set of criteria to optionally include successes and total tests run. For example: regression = # of failures has increased OR # of successes has decreased OR # of total tests run has decreased improvement = # of failures has decreased OR # of successes has increased OR # of total tests run has increased The background behind this request is a unit test "timeout" (mstest) which was not reported as a failure. Looking at the normal Jenkins test result stats, there was no indication that anything was wrong: there were no failures and the total number of tests was the same. If the test result stats reported number of successes, then I might have noticed this number had dropped, but it's a moot point since this is not displayed. The regression trigger would not have kicked in since the number of failures did not increase. For this specific scenario, the "# of successes has decreased" regression trigger applies. The "total tests run" trigger would come in handy in the situation where developers inadvertently (or intentionally) enable/disable tests. Thanks, Steve -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13108) Removing P4CONFIG file on cleaning workspace
[ https://issues.jenkins-ci.org/browse/JENKINS-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Petti reassigned JENKINS-13108: --- Assignee: Rob Petti > Removing P4CONFIG file on cleaning workspace > > > Key: JENKINS-13108 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13108 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current >Reporter: Alexey Larsky >Assignee: Rob Petti > > Cleaning workspace causing to remove local workspace config file. > http://www.perforce.com/perforce/doc.current/manuals/cmdref/env.P4CONFIG.html > http://www.jetbrains.com/idea/webhelp/using-multiple-perforce-depots-with-p4config.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13108) Removing P4CONFIG file on cleaning workspace
[ https://issues.jenkins-ci.org/browse/JENKINS-13108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160350#comment-160350 ] Rob Petti commented on JENKINS-13108: - I'll add it to the list of excluded paths, but it should be noted that the perforce plugin doesn't even use this file, so it's generally not needed anyways (though I can see how it would be convenient). > Removing P4CONFIG file on cleaning workspace > > > Key: JENKINS-13108 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13108 > Project: Jenkins > Issue Type: Bug > Components: perforce >Affects Versions: current >Reporter: Alexey Larsky >Assignee: Rob Petti > > Cleaning workspace causing to remove local workspace config file. > http://www.perforce.com/perforce/doc.current/manuals/cmdref/env.P4CONFIG.html > http://www.jetbrains.com/idea/webhelp/using-multiple-perforce-depots-with-p4config.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7813) Archiving artifacts very slow
[ https://issues.jenkins-ci.org/browse/JENKINS-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160349#comment-160349 ] Mike Pontillo edited comment on JENKINS-7813 at 3/16/12 11:49 PM: -- Anyone have a workaround? I was thinking of just doing a direct 'scp' to the master. FYI, I get the following stack trace if I abort the build while archiving artifacts is taking a long time: Archiving artifacts ERROR: Failed to archive artifacts: **/*.tar.gz java.io.IOException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) at java.io.FilterInputStream.read(FilterInputStream.java:107) at hudson.util.HeadBufferingStream.fillSide(HeadBufferingStream.java:83) at hudson.FilePath$TarCompression$2.extract(FilePath.java:568) at hudson.FilePath.copyRecursiveTo(FilePath.java:1685) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) was (Author: mpontillo): Anyone have a workaround? I was thinking of just doing a direct 'scp' to the master. FYI, I get the following stack trace: Archiving artifacts ERROR: Failed to archive artifacts: **/*.tar.gz java.io.IOException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) at java.io.FilterInputStream.read(FilterInputStream.java:107) at hudson.util.HeadBufferingStream.fillSide(HeadBufferingStream.java:83) at hudson.FilePath$TarCompression$2.extract(FilePath.java:568) at hudson.FilePath.copyRecursiveTo(FilePath.java:1685) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) > Archiving artifacts very slow > - > > Key: JENKINS-7813 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7813 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Fedora 10 x86_64 Master, Win7 32bit Slave >Reporter: gtuhl > > We are running 1.380. I can watch a 300MB tarball get transferred to the > Hudson master slowly over 30+ minutes. An scp between the same machines and > same files/directories takes less than 3 minutes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7813) Archiving artifacts very slow
[ https://issues.jenkins-ci.org/browse/JENKINS-7813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160349#comment-160349 ] Mike Pontillo commented on JENKINS-7813: Anyone have a workaround? I was thinking of just doing a direct 'scp' to the master. FYI, I get the following stack trace: Archiving artifacts ERROR: Failed to archive artifacts: **/*.tar.gz java.io.IOException at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) at java.io.FilterInputStream.read(FilterInputStream.java:107) at hudson.util.HeadBufferingStream.fillSide(HeadBufferingStream.java:83) at hudson.FilePath$TarCompression$2.extract(FilePath.java:568) at hudson.FilePath.copyRecursiveTo(FilePath.java:1685) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) > Archiving artifacts very slow > - > > Key: JENKINS-7813 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7813 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Fedora 10 x86_64 Master, Win7 32bit Slave >Reporter: gtuhl > > We are running 1.380. I can watch a 300MB tarball get transferred to the > Hudson master slowly over 30+ minutes. An scp between the same machines and > same files/directories takes less than 3 minutes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13119) How can I set an environment variable based on value of user passed parameter?
suresh kukalakuntla created JENKINS-13119: - Summary: How can I set an environment variable based on value of user passed parameter? Key: JENKINS-13119 URL: https://issues.jenkins-ci.org/browse/JENKINS-13119 Project: Jenkins Issue Type: Improvement Components: envinject Affects Versions: current Environment: Redhat Linux 5.5 Reporter: suresh kukalakuntla Assignee: gbois I want to set value for an environment variable based on user provided input during the build and use this env variable to set workspace in a jenkins project. Ex: User has to select MODULE_NAME when performing a build. MODULE_NAME is a choice parameter. Based on the value selected by the user I want to set MODULE_FOLDER environment variable and use it for setting the WORKSPACE. Below is the functionality I am expecting. if MODULE_NAME is 'A' then set MODULE_FOLDER = FOLDER1 else if MODULE_NAME is 'B' then set MODULE_FOLDER = FOLDER2 else if MODULE_NAME is 'C' then set MODULE_FOLDER = FOLDER3 Now set WORKSPACE=/usr/modules/$MODULE_FOLDER Please help me achieve this functionality. I want to have only one job for all modules. Based on the module user selects I want to build it and deploy it. your guidance is much appreciated -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13118) Support "ordinal" setting from Ruby plugins
R. Tyler Croy created JENKINS-13118: --- Summary: Support "ordinal" setting from Ruby plugins Key: JENKINS-13118 URL: https://issues.jenkins-ci.org/browse/JENKINS-13118 Project: Jenkins Issue Type: Improvement Components: ruby-runtime Reporter: R. Tyler Croy Assignee: Charles Lowell The @Extension annotation exposes "ordinal" which you can use to set the ordering, effectively, of a BuildWrapper or a Publisher. I could really use this support in the Ruby plugin space so I can order my publishers properly :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13114) dropdown views taskbar: error when saving jenkins config page
[
https://issues.jenkins-ci.org/browse/JENKINS-13114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160348#comment-160348
]
Steve Roth commented on JENKINS-13114:
--
With DD views taskbar installed (but not selected), I am able to save the
system config page.
With other navigation views selected, I am able to save the system config page.
Once I select the DD views taskbar and save the config page, any further
attempts to save the config page fail with an error like the above.
The main symptom is a ClassNotFoundException listing a set of classes such as
java.lang.ClassNotFoundException:
["hudson.views.DefaultViewsTabBar","hudson.views.tabbar.DropDownViewsTabBar"]
> dropdown views taskbar: error when saving jenkins config page
> -
>
> Key: JENKINS-13114
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13114
> Project: Jenkins
> Issue Type: Bug
> Components: dropdown-viewstabbar
>Affects Versions: current
>Reporter: Steve Roth
>Assignee: jieryn
>
> I have the dropdown views tabbar enabled, and am usign Jenkins 1.455 When I
> go to save the main Jenkins config page, I see this CNF exception in the
> browser:
> exception
> javax.servlet.ServletException: java.lang.IllegalArgumentException: Failed to
> instantiate class hudson.views.ViewsTabBar from
> {"showJobCount":false,"stapler-class":["hudson.views.DefaultViewsTabBar","hudson.views.tabbar.DropDownViewsTabBar"]}
> org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:605)
> org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
> org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
> org.kohsuke.stapler.Stapler.service(Stapler.java:159)
> javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:185)
> net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:159)
>
> net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
>
> org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
>
> hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66)
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
>
> oracle.boulderlabs.jenkins.validatorkiller.ValidatorKiller.doFilter(ValidatorKiller.java:63)
> hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
> hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
> hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
>
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
>
> hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
>
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>
> org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
>
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>
> org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
>
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>
> org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
>
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>
> org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
>
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>
> org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
>
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
> jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:61)
>
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>
> org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
>
> hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
>
> hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
>
> hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
> hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
>
> hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodi
[JIRA] (JENKINS-13117) Allow triggering on the change-merged event too
[
https://issues.jenkins-ci.org/browse/JENKINS-13117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160347#comment-160347
]
R. Tyler Croy commented on JENKINS-13117:
-
[Event
documentation|http://gerrit-documentation.googlecode.com/svn/Documentation/2.2.2/cmd-stream-events.html#_events]
> Allow triggering on the change-merged event too
> ---
>
> Key: JENKINS-13117
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13117
> Project: Jenkins
> Issue Type: Improvement
> Components: gerrit-trigger
>Reporter: R. Tyler Croy
>Assignee: rsandell
>
> Gerrit will fire a {{change-merged}} event when a change is "Submitted" (i.e.
> merged) into the destination branch.
> It would be most useful to be able to allow a job to be triggered off of the
> usual {{patchset-created}} event (existing behavior), as well as the
> {{change-merged}} event.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13117) Allow triggering on the change-merged event too
R. Tyler Croy created JENKINS-13117:
---
Summary: Allow triggering on the change-merged event too
Key: JENKINS-13117
URL: https://issues.jenkins-ci.org/browse/JENKINS-13117
Project: Jenkins
Issue Type: Improvement
Components: gerrit-trigger
Reporter: R. Tyler Croy
Assignee: rsandell
Gerrit will fire a {{change-merged}} event when a change is "Submitted" (i.e.
merged) into the destination branch.
It would be most useful to be able to allow a job to be triggered off of the
usual {{patchset-created}} event (existing behavior), as well as the
{{change-merged}} event.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13085) Environment Variable Injection doesn't work when project run on slave node that sets the same variable
[ https://issues.jenkins-ci.org/browse/JENKINS-13085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Davidson updated JENKINS-13085: Attachment: aaa.job.config.xml config.xml > Environment Variable Injection doesn't work when project run on slave node > that sets the same variable > -- > > Key: JENKINS-13085 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13085 > Project: Jenkins > Issue Type: Bug > Components: envinject >Affects Versions: current >Reporter: Josh Davidson >Assignee: gbois > Attachments: aaa.job.config.xml, config.xml > > > When a slave node is configured to append/prepend to a variable (Node > Properties->Environment Variables) that is used by EnvInject within a job, > the injection fails. If the slave node simply sets the variable (i.e. > doesn't reference the same variable in the act of setting) it works fine. > Consider the following job, which has a single build step: echo $PATH > In Build Environment->Inject, there is a single line in the properties > content box: PATH=/opt/bin:$PATH > That's the job. Now, the slave node, also sets the PATH variable. Let's > first look at a working example, where the slave node sets PATH to: > /data/goesrsw/goesr/bin Here is the output: > [EnvInject] - Executing scripts and injecting environment variables after the > SCM step. > [EnvInject] - Injecting as environment variables the properties content > PATH=/opt/bin:$PATH > [EnvInject] - Variables injected successfully. > [aaa] $ bash -xe /tmp/hudson5838824311735104563.sh > + echo /opt/bin:/data/goesrsw/goesr/bin > /opt/bin:/data/goesrsw/goesr/bin > Notifying upstream projects of job completion > Finished: SUCCESS > Ok, so to demonstrate the problem, change the PATH in the slave node to: > /data/goesrsw/goesr/bin:$PATH > Now, here's the output: > [EnvInject] - Executing scripts and injecting environment variables after the > SCM step. > [EnvInject] - Injecting as environment variables the properties content > PATH=/opt/bin:$PATH > [EnvInject] - Variables injected successfully. > [EnvInject] - Unset unresolved 'PATH' variable. > [aaa] $ bash -xe /tmp/hudson3276485997068093627.sh > + echo > /data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/home/goesrjen/bin:/usr/local/bin:/usr/local/sbin:/app/share/bin:/app/share/sbin:/usr/bin/X11:/bin:/usr/bin:/sbin:/usr/sbin:.:/app/rc52_test1_perl:/data/goesrsw/WindRiver/gnu/4.1.2-vxworks-6.6/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/foundation/4.1.1/x86-linux2/lib/tcl8.4/Wind > /data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/home/goesrjen/bin:/usr/local/bin:/usr/local/sbin:/app/share/bin:/app/share/sbin:/usr/bin/X11:/bin:/usr/bin:/sbin:/usr/sbin:.:/app/rc52_test1_perl:/data/goesrsw/WindRiver/gnu/4.1.2-vxworks-6.6/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/foundation/4.1.1/x86-linux2/lib/tcl8.4/Wind > Notifying upstream projects of job completion > Finished: SUCCESS > As you can see, the injection didn't work. /opt/bin is nowhere to be found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13085) Environment Variable Injection doesn't work when project run on slave node that sets the same variable
[ https://issues.jenkins-ci.org/browse/JENKINS-13085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160346#comment-160346 ] Josh Davidson commented on JENKINS-13085: - Config files posted. > Environment Variable Injection doesn't work when project run on slave node > that sets the same variable > -- > > Key: JENKINS-13085 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13085 > Project: Jenkins > Issue Type: Bug > Components: envinject >Affects Versions: current >Reporter: Josh Davidson >Assignee: gbois > Attachments: aaa.job.config.xml, config.xml > > > When a slave node is configured to append/prepend to a variable (Node > Properties->Environment Variables) that is used by EnvInject within a job, > the injection fails. If the slave node simply sets the variable (i.e. > doesn't reference the same variable in the act of setting) it works fine. > Consider the following job, which has a single build step: echo $PATH > In Build Environment->Inject, there is a single line in the properties > content box: PATH=/opt/bin:$PATH > That's the job. Now, the slave node, also sets the PATH variable. Let's > first look at a working example, where the slave node sets PATH to: > /data/goesrsw/goesr/bin Here is the output: > [EnvInject] - Executing scripts and injecting environment variables after the > SCM step. > [EnvInject] - Injecting as environment variables the properties content > PATH=/opt/bin:$PATH > [EnvInject] - Variables injected successfully. > [aaa] $ bash -xe /tmp/hudson5838824311735104563.sh > + echo /opt/bin:/data/goesrsw/goesr/bin > /opt/bin:/data/goesrsw/goesr/bin > Notifying upstream projects of job completion > Finished: SUCCESS > Ok, so to demonstrate the problem, change the PATH in the slave node to: > /data/goesrsw/goesr/bin:$PATH > Now, here's the output: > [EnvInject] - Executing scripts and injecting environment variables after the > SCM step. > [EnvInject] - Injecting as environment variables the properties content > PATH=/opt/bin:$PATH > [EnvInject] - Variables injected successfully. > [EnvInject] - Unset unresolved 'PATH' variable. > [aaa] $ bash -xe /tmp/hudson3276485997068093627.sh > + echo > /data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/home/goesrjen/bin:/usr/local/bin:/usr/local/sbin:/app/share/bin:/app/share/sbin:/usr/bin/X11:/bin:/usr/bin:/sbin:/usr/sbin:.:/app/rc52_test1_perl:/data/goesrsw/WindRiver/gnu/4.1.2-vxworks-6.6/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/foundation/4.1.1/x86-linux2/lib/tcl8.4/Wind > /data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/home/goesrjen/bin:/usr/local/bin:/usr/local/sbin:/app/share/bin:/app/share/sbin:/usr/bin/X11:/bin:/usr/bin:/sbin:/usr/sbin:.:/app/rc52_test1_perl:/data/goesrsw/WindRiver/gnu/4.1.2-vxworks-6.6/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/foundation/4.1.1/x86-linux2/lib/tcl8.4/Wind > Notifying upstream projects of job completion > Finished: SUCCESS > As you can see, the injection didn't work. /opt/bin is nowhere to be found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12094) ruby-runtime plugin fails to initialize
[ https://issues.jenkins-ci.org/browse/JENKINS-12094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160345#comment-160345 ] Sebastien Tardif commented on JENKINS-12094: My understanding is that ruby is not even supported in Jenkins, see https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+plugin+development+in+Ruby I think the best move is to rewrite it in Groovy. Jenkins is written in Java, that's kind of shooting it's own foot to use a scripting language too far from Java. > ruby-runtime plugin fails to initialize > --- > > Key: JENKINS-12094 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12094 > Project: Jenkins > Issue Type: Bug > Components: pathignore, plugin, ruby-runtime >Affects Versions: current > Environment: Windows 7 64-bit, Running Jenkins as a Windows Service >Reporter: Adam Westhusing >Priority: Critical > > I'm actually trying to install another plugin (pathignore) that is dependent > on the ruby-runtime plugin, and I keep receiving an exception when trying to > install ruby-runtime (0.6). > This happens on Windows 7 64-bit, running Jenkins as a service. This is > reproducible on Jenkins version 1.443 and 1.442. The issue does not happen > on my Jenkins instance that is running on Ubuntu Server 10.4, so it appears > to be something related to Windows. > The exception that occurs is the following: > jenkins.InitReactorRunner$1 onTaskFailed > SEVERE: Failed Loading plugin ruby-runtime > hudson.util.IOException2: Failed to initialize > at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:335) > at hudson.PluginManager$2$1$1.run(PluginManager.java:294) > at > org.jvnet.hudson.reactor.TaskGraphBuilder$TaskImpl.run(TaskGraphBuilder.java:146) > at org.jvnet.hudson.reactor.Reactor.runTask(Reactor.java:259) > at jenkins.model.Jenkins$5.runTask(Jenkins.java:804) > at org.jvnet.hudson.reactor.Reactor$2.run(Reactor.java:187) > at org.jvnet.hudson.reactor.Reactor$Node.run(Reactor.java:94) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > Caused by: org.jruby.embed.EvalFailedException: (LoadError) no such file to > load -- haml > at > org.jruby.embed.internal.EmbedEvalUnitImpl.run(EmbedEvalUnitImpl.java:127) > at > org.jruby.embed.ScriptingContainer.runUnit(ScriptingContainer.java:1231) > at > org.jruby.embed.ScriptingContainer.runScriptlet(ScriptingContainer.java:1224) > at > org.kohsuke.stapler.jelly.jruby.haml.HamlLanguage.createContainer(HamlLanguage.java:28) > at > org.kohsuke.stapler.jelly.jruby.JRubyFacet.(JRubyFacet.java:69) > at ruby.RubyRuntimePlugin.registerJRubyFacet(RubyRuntimePlugin.java:38) > at ruby.RubyRuntimePlugin.start(RubyRuntimePlugin.java:29) > at > hudson.ClassicPluginStrategy.startPlugin(ClassicPluginStrategy.java:343) > at hudson.ClassicPluginStrategy.load(ClassicPluginStrategy.java:332) > ... 9 more > Caused by: org.jruby.exceptions.RaiseException: (LoadError) no such file to > load -- haml > If there's any additional debug information I can add, I'll be glad to attach > that information. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13116) Should be able to filter out natively changeset so that not all SCMs need to re-code the same logic, and also needed filtered changeset even outside SCM trigger code
[ https://issues.jenkins-ci.org/browse/JENKINS-13116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sebastien Tardif updated JENKINS-13116: --- Summary: Should be able to filter out natively changeset so that not all SCMs need to re-code the same logic, and also needed filtered changeset even outside SCM trigger code (was: Should be able to filter out changeset so that not all SCMs need to re-code the same logic, and also needed filtered changeset even outside SCM trigger code) Description: Running jobs has a list of changes, represented by http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html#getChangeSet%28%29 We should have a way to filter out from the UI the result that getChangeSet will return. Then the many SCM plug-ins could leverage that to exclude changed path when using SCM trigger. In many SCM like git, there is no easy way to checkout only a subset of the repository. In other cases, the flexibility of excludes/includes expressions could be lot more flexible than flexible SCM like SVN. We have only a small project and we have already encounter two different use cases where this would have helped a lot: - Git SCM includes/excludes supported pattern was deficient - There is no working plug-ins that can bypass a subordinate job if no relevant changes occur (from the subset the subordinate job care about) following a periodic execution of the master job. So I would like to have a 1 line script calling getChangeSet instead of copy/pasting the same includes/excludes logic. was: Running jobs has a list of change, represented by http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html#getChangeSet%28%29 We should have a way to filter out from the UI the result that getChangeSet will return. Then the many SCM plug-ins could leverage that to exclude changed path when using SCM trigger. In many SCM like git, there is no easy way to checkout only a subset of the repository. In other cases, the flexibility of excludes/includes expressions could be lot more flexible than flexible SCM like SVN. We have only a small project and we have already encounter two different use cases where this would have helped a lot: - Git SCM includes/excludes supported pattern was deficient - There is no working plug-ins that can bypass a subordinate job if no relevant changes occur (from the subset the subordinate job care about) following a periodic execution of the master job. > Should be able to filter out natively changeset so that not all SCMs need to > re-code the same logic, and also needed filtered changeset even outside SCM > trigger code > - > > Key: JENKINS-13116 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13116 > Project: Jenkins > Issue Type: Improvement > Components: core >Affects Versions: current > Environment: All >Reporter: Sebastien Tardif > > Running jobs has a list of changes, represented by > http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html#getChangeSet%28%29 > We should have a way to filter out from the UI the result that getChangeSet > will return. Then the many SCM plug-ins could leverage that to exclude > changed path when using SCM trigger. > In many SCM like git, there is no easy way to checkout only a subset of the > repository. In other cases, the flexibility of excludes/includes expressions > could be lot more flexible than flexible SCM like SVN. > We have only a small project and we have already encounter two different use > cases where this would have helped a lot: > - Git SCM includes/excludes supported pattern was deficient > - There is no working plug-ins that can bypass a subordinate job if no > relevant changes occur (from the subset the subordinate job care about) > following a periodic execution of the master job. So I would like to have a 1 > line script calling getChangeSet instead of copy/pasting the same > includes/excludes logic. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13116) Should be able to filter out changeset so that not all SCMs need to re-code the same logic, and also needed filtered changeset even outside SCM trigger code
Sebastien Tardif created JENKINS-13116: -- Summary: Should be able to filter out changeset so that not all SCMs need to re-code the same logic, and also needed filtered changeset even outside SCM trigger code Key: JENKINS-13116 URL: https://issues.jenkins-ci.org/browse/JENKINS-13116 Project: Jenkins Issue Type: Improvement Components: core Affects Versions: current Environment: All Reporter: Sebastien Tardif Running jobs has a list of change, represented by http://javadoc.jenkins-ci.org/hudson/model/AbstractBuild.html#getChangeSet%28%29 We should have a way to filter out from the UI the result that getChangeSet will return. Then the many SCM plug-ins could leverage that to exclude changed path when using SCM trigger. In many SCM like git, there is no easy way to checkout only a subset of the repository. In other cases, the flexibility of excludes/includes expressions could be lot more flexible than flexible SCM like SVN. We have only a small project and we have already encounter two different use cases where this would have helped a lot: - Git SCM includes/excludes supported pattern was deficient - There is no working plug-ins that can bypass a subordinate job if no relevant changes occur (from the subset the subordinate job care about) following a periodic execution of the master job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13115) Same attachment can appear multiple times on "Test Result" page
Todd Mazierski created JENKINS-13115: Summary: Same attachment can appear multiple times on "Test Result" page Key: JENKINS-13115 URL: https://issues.jenkins-ci.org/browse/JENKINS-13115 Project: Jenkins Issue Type: Bug Components: junit-attachments Reporter: Todd Mazierski Assignee: huybrechts Priority: Minor In the JUnit XML report, if the [[ATTACHMENT|/path/to/file]] appears in the in the node (instead of ), the same attachment can appear multiple times on the "Test Result" page. For example, this XML report: Would yield this result on the "Test Result" page: Attachments Files foo_bar_baz.mov foo_bar_baz.mov foo_bar_baz.mov -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13103) Build hangs trying to send email if an email address isn't defined in Active Directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160344#comment-160344 ] Rob Petti commented on JENKINS-13103: - I've made some changes, can you test our the snapshot below? http://ci.jenkins-ci.org/job/plugins_perforce/200/artifact/target/perforce.hpi > Build hangs trying to send email if an email address isn't defined in Active > Directory > -- > > Key: JENKINS-13103 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13103 > Project: Jenkins > Issue Type: Bug > Components: perforce > Environment: Jenkins - 1.455 > email-ext 2.18 > perforce plugin - 1.3.9 > AD plugin - 1.26 > Windows 2003 master > Linux x64 slave >Reporter: aflat > > I think the hang is due to the email-ext plugin, but there may be a perforce > plugin issue as well. > https://issues.jenkins-ci.org/browse/JENKINS-13102 > What I don't understand is why is the perforce plugin asking for the email > from Active directory? The email is defined in perforce, shouldn't it just > use that when creating the email list? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13103) Build hangs trying to send email if an email address isn't defined in Active Directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160343#comment-160343 ] dogfood commented on JENKINS-13103: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_perforce #200|http://ci.jenkins-ci.org/job/plugins_perforce/200/] [JENKINS-13103] fixing a few issues with the mailresolver (Revision f37dd67bc3fe7abb6f1617a4d1c4d5e268a210c0) Result = SUCCESS Rob Petti : Files : * src/main/java/hudson/plugins/perforce/PerforceMailResolver.java * src/main/java/com/tek42/perforce/parse/Users.java > Build hangs trying to send email if an email address isn't defined in Active > Directory > -- > > Key: JENKINS-13103 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13103 > Project: Jenkins > Issue Type: Bug > Components: perforce > Environment: Jenkins - 1.455 > email-ext 2.18 > perforce plugin - 1.3.9 > AD plugin - 1.26 > Windows 2003 master > Linux x64 slave >Reporter: aflat > > I think the hang is due to the email-ext plugin, but there may be a perforce > plugin issue as well. > https://issues.jenkins-ci.org/browse/JENKINS-13102 > What I don't understand is why is the perforce plugin asking for the email > from Active directory? The email is defined in perforce, shouldn't it just > use that when creating the email list? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13101) Analysis Collector Plugin prevents other plugins from loading when the Dashboard View Plugin is not installed
[ https://issues.jenkins-ci.org/browse/JENKINS-13101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160342#comment-160342 ] Ulli Hafner commented on JENKINS-13101: --- I don't see any references to the analysis collector plug-in in the log. It seems that the dashboard view just could not be loaded. (The dependency is optional in my plug-in) > Analysis Collector Plugin prevents other plugins from loading when the > Dashboard View Plugin is not installed > - > > Key: JENKINS-13101 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13101 > Project: Jenkins > Issue Type: Bug > Components: analysis-collector >Affects Versions: current > Environment: Jenkins ver. 1.455 > Analysis Collector 1.20 > Tomcat 6 >Reporter: Martin Ziel >Assignee: Ulli Hafner > Labels: exception, plugin > Attachments: jenkins.log > > > The Analysis Collector Plugin prevents other plugins from loading when the > Dashboard View Plugin is not installed and activated. In my case, this > effectively disables the SCM Plugins and thus prevents Jenkins from fetching > SCM changes. Log attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13103) Build hangs trying to send email if an email address isn't defined in Active Directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160341#comment-160341 ] SCM/JIRA link daemon commented on JENKINS-13103: Code changed in jenkins User: Rob Petti Path: src/main/java/com/tek42/perforce/parse/Users.java src/main/java/hudson/plugins/perforce/PerforceMailResolver.java http://jenkins-ci.org/commit/perforce-plugin/f37dd67bc3fe7abb6f1617a4d1c4d5e268a210c0 Log: [JENKINS-13103] fixing a few issues with the mailresolver > Build hangs trying to send email if an email address isn't defined in Active > Directory > -- > > Key: JENKINS-13103 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13103 > Project: Jenkins > Issue Type: Bug > Components: perforce > Environment: Jenkins - 1.455 > email-ext 2.18 > perforce plugin - 1.3.9 > AD plugin - 1.26 > Windows 2003 master > Linux x64 slave >Reporter: aflat > > I think the hang is due to the email-ext plugin, but there may be a perforce > plugin issue as well. > https://issues.jenkins-ci.org/browse/JENKINS-13102 > What I don't understand is why is the perforce plugin asking for the email > from Active directory? The email is defined in perforce, shouldn't it just > use that when creating the email list? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11811) Update unity-asset-server-plugin parent from 1.318 to 1.392
[ https://issues.jenkins-ci.org/browse/JENKINS-11811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jieryn closed JENKINS-11811. Resolution: Won't Fix This plugin regained activation development status before I could complete the update. > Update unity-asset-server-plugin parent from 1.318 to 1.392 > --- > > Key: JENKINS-11811 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11811 > Project: Jenkins > Issue Type: Task > Components: unity-asset-server >Reporter: jieryn >Assignee: jieryn > > Main discussion: > http://jenkins.361315.n4.nabble.com/standardize-plugin-requiredCore-td3918782.html > Plugin Report Card: > https://wiki.jenkins-ci.org/display/JENKINS/Plugin+Report+Card > Governance Resolution: > http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-10-26-18.04.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13003) HTTP 500 on import causes NullPointerException
[ https://issues.jenkins-ci.org/browse/JENKINS-13003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jieryn updated JENKINS-13003: - Summary: HTTP 500 on import causes NullPointerException (was: pp) Priority: Major (was: Blocker) Component/s: (was: plugin) > HTTP 500 on import causes NullPointerException > -- > > Key: JENKINS-13003 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13003 > Project: Jenkins > Issue Type: Bug > Components: job-import >Affects Versions: current >Reporter: Arvind Ramalingam >Assignee: jieryn > > FAILED - Server returned HTTP response code: 403 when trying to use import > plugin to import jobs from one Jenkins to another. > It redirects me to the below stack trace. > HTTP Status 500 - > type Exception report > message > description The server encountered an internal error () that prevented it > from fulfilling this request. > exception > javax.servlet.ServletException: java.lang.NullPointerException > org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:603) > org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) > org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:374) > org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) > org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) > org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) > org.kohsuke.stapler.Stapler.service(Stapler.java:159) > javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94) > > hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74) > hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:97) > hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86) > hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) > > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) > > hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) > hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) > > hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) > root cause > java.lang.NullPointerException > > org.jenkins.ci.plugins.jobimport.JobImportAction.doImport(JobImportAction.java:126) > sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > java.lang.reflect.Method.invoke(Method.java:616) > org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:282) > org.kohsuke.stapler.Function.bindAndInvoke(Function.java:149) > > org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:88) > org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:104) > > org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) > org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) > org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) > org.kohsuke.stapler.MetaClass$12.dispatch(MetaClass.java:374) > org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:561) > org.kohsuke.stapler.Stapler.invoke(Stapler.java:646) > org.kohsuke.stapler.Stapler.invoke(Stapler.java:477) > org.kohsuke.stapler.Stapler.service(Stapler.java:159) > javax.servlet.http.HttpServlet.service(HttpServlet.java:717) > hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:94) > > hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:74) > hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:97) > hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:86) > hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) > > hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) > > hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) > hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) > > hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81) > note The full stack trace of the root cause is available in the Apache > Tomcat/6.0.33 logs. > Apache Tomcat/6.0.33 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9343) Add LOADING overlay when triggering a build with parameters
[
https://issues.jenkins-ci.org/browse/JENKINS-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Petisme reopened JENKINS-9343:
-
Similar to the following issue
[Jenkins-8789|https://issues.jenkins-ci.org/browse/JENKINS-8789]
When you use the {{Validating string parameter}}, if you type an apostrophe in
the {{Regular expression field}} or {{Failed Validation Message}} then you try
to build your build but the overlay never goes away.
> Add LOADING overlay when triggering a build with parameters
> ---
>
> Key: JENKINS-9343
> URL: https://issues.jenkins-ci.org/browse/JENKINS-9343
> Project: Jenkins
> Issue Type: Improvement
> Components: core
>Reporter: Romain Seguy
>Assignee: Romain Seguy
>Priority: Trivial
> Attachments: Regular_Expression_With_Apostrophe.PNG,
> Regular_Expression_With_Apostrophe_Overlay_Blocked.PNG,
> Validation_Message_With_Apostrophe.PNG,
> Validation_Message_With_Apostrophe_Overlay_Blocked.PNG
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9343) Add LOADING overlay when triggering a build with parameters
[ https://issues.jenkins-ci.org/browse/JENKINS-9343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Petisme updated JENKINS-9343: Attachment: Validation_Message_With_Apostrophe_Overlay_Blocked.PNG Regular_Expression_With_Apostrophe.PNG Regular_Expression_With_Apostrophe_Overlay_Blocked.PNG Validation_Message_With_Apostrophe.PNG > Add LOADING overlay when triggering a build with parameters > --- > > Key: JENKINS-9343 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9343 > Project: Jenkins > Issue Type: Improvement > Components: core >Reporter: Romain Seguy >Assignee: Romain Seguy >Priority: Trivial > Attachments: Regular_Expression_With_Apostrophe.PNG, > Regular_Expression_With_Apostrophe_Overlay_Blocked.PNG, > Validation_Message_With_Apostrophe.PNG, > Validation_Message_With_Apostrophe_Overlay_Blocked.PNG > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13096) should be able to use Jenkins Environment Variables (JENKINS_HOME, WORKSPACE) in the properties file path
[ https://issues.jenkins-ci.org/browse/JENKINS-13096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160338#comment-160338 ] Maddy Goss commented on JENKINS-13096: -- actually, in this one instance, I am injecting environment variables prior to the scm checkout. (I use it to determine the specific scm revision to check out). ie: * parent project/job - checks out the configuration containing the desired scm revision number * child projects/jobs - load the configuration pre-scm and use it to specify the revision being checked out Hope that helps :) > should be able to use Jenkins Environment Variables (JENKINS_HOME, WORKSPACE) > in the properties file path > - > > Key: JENKINS-13096 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13096 > Project: Jenkins > Issue Type: Improvement > Components: envinject >Affects Versions: current >Reporter: Maddy Goss >Assignee: gbois >Priority: Minor > Labels: plugin > > I keep my generic project configuration in a properties file which is in a > project that is checked into SCM. I would like to be able to update that file > in a parent job, and then consume it (via > $WORKSPACE/projectname/global.properties). Currently, you have to use the > full path to the properties file, which makes my configuration brittle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13103) Build hangs trying to send email if an email address isn't defined in Active Directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160337#comment-160337 ] aflat commented on JENKINS-13103: - ThreadDump Thread Dump Aunt Zelma's VP Listener 1 "Aunt Zelma's VP Listener 1" Id=56 Group=main RUNNABLE (in native) at java.net.SocketInputStream.socketRead0(Native Method) at java.net.SocketInputStream.read(Unknown Source) at java.io.DataInputStream.readFully(Unknown Source) at java.io.DataInputStream.readFully(Unknown Source) at com.lotus.sametime.core.util.connection.e.a(Unknown Source) at com.lotus.sametime.core.util.connection.e.a(Unknown Source) at com.lotus.sametime.core.util.connection.i.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Aunt Zelma's VP Listener 2 "Aunt Zelma's VP Listener 2" Id=58 Group=main TIMED_WAITING on java.io.PipedInputStream@a3f805 at java.lang.Object.wait(Native Method) - waiting on java.io.PipedInputStream@a3f805 at java.io.PipedInputStream.read(Unknown Source) at java.io.PipedInputStream.read(Unknown Source) at java.io.DataInputStream.readFully(Unknown Source) at java.io.DataInputStream.readFully(Unknown Source) at com.lotus.sametime.core.util.connection.k.a(RC2Receiver.java) at com.lotus.sametime.core.util.connection.i.run(Unknown Source) at java.lang.Thread.run(Unknown Source) AWT-Windows "AWT-Windows" Id=1129 Group=main RUNNABLE (in native) at sun.awt.windows.WToolkit.eventLoop(Native Method) at sun.awt.windows.WToolkit.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Channel reader thread: 192.168.200.200 "Channel reader thread: 192.168.200.200" Id=296 Group=main WAITING on java.lang.Object@e3c02d at java.lang.Object.wait(Native Method) - waiting on java.lang.Object@e3c02d at java.lang.Object.wait(Object.java:485) at com.trilead.ssh2.StreamGobbler.read(StreamGobbler.java:144) at java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1127) Channel reader thread: HudsonSlave7 CentOS 5.4 x64 "Channel reader thread: HudsonSlave7 CentOS 5.4 x64" Id=566 Group=main WAITING on java.lang.Object@6ace6b at java.lang.Object.wait(Native Method) - waiting on java.lang.Object@6ace6b at java.lang.Object.wait(Object.java:485) at com.trilead.ssh2.StreamGobbler.read(StreamGobbler.java:144) at java.io.ObjectInputStream$PeekInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peek(Unknown Source) at java.io.ObjectInputStream$BlockDataInputStream.peekByte(Unknown Source) at java.io.ObjectInputStream.readObject0(Unknown Source) at java.io.ObjectInputStream.readObject(Unknown Source) at hudson.remoting.Channel$ReaderThread.run(Channel.java:1127) Chuck the postman's dispatching thread.1 "Chuck the postman's dispatching thread.1" Id=43 Group=main TIMED_WAITING on com.lotus.sametime.core.comparch.DispatchingThreadPool@ceb795 at java.lang.Object.wait(Native Method) - waiting on com.lotus.sametime.core.comparch.DispatchingThreadPool@ceb795 at com.lotus.sametime.core.comparch.DispatchingThreadPool.a(DispatchingThreadPool.java) at com.lotus.sametime.core.comparch.c.run(MessageDispatchingThread.java) at java.lang.Thread.run(Unknown Source) ComThread for Finalizing set up "ComThread for Finalizing set up" Id=73 Group=main RUNNABLE (in native) at com4j.Win32Lock.suspend0(Native Method) at com4j.Win32Lock.suspend(Win32Lock.java:33) at com4j.ComThread.run0(ComThread.java:135) at com4j.ComThread.run(ComThread.java:125) ConnectorThread:[ajp13-8009] "ConnectorThread:[ajp13-8009]" Id=18 Group=main RUNNABLE (in native) at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(Unknown Source) - locked java.net.SocksSocketImpl@15f1299 at java.net.ServerSocket.implAccept(Unknown Source) at java.net.ServerSocket.accept(Unknown Source) at winstone.ajp13.Ajp13Listener.run(Ajp13Listener.java:116) at java.lang.Thread.run(Unknown Source) ConnectorThread:[http-8080] "ConnectorThread:[http-8080]" Id=17 Group=main RUNNABLE (in native) at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(Unknown Source) - locked java.net.SocksSocketImpl@be02b1
[JIRA] (JENKINS-13103) Build hangs trying to send email if an email address isn't defined in Active Directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160336#comment-160336 ] aflat commented on JENKINS-13103: - A bit more info, I'm getting a bunch of this in the jenkins.out.log (thread dump coming up next) Creating ST Session. Loading ST Components. Starting ST Session. Attempting login. Loggedin successfully. Registering for IM Service. [hudson] $ "c:\program files\perforce\p4.exe" users build [hudson] $ "c:\program files\perforce\p4.exe" user -o build [hudson] $ "c:\program files\perforce\p4.exe" login -p [hudson] $ "c:\program files\perforce\p4.exe" -P D6651DECFD1784D6DEA93ECEB674 user -o build Problem: Could not run perforce command. Problem: Could not run perforce command. com.tek42.perforce.PerforceException: No output for: c:\program files\perforce\p4.exe users null at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:384) at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292) at com.tek42.perforce.parse.Users.exists(Users.java:61) at com.tek42.perforce.parse.Users.getUser(Users.java:54) at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:64) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:335) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:255) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:247) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:207) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171) at hudson.model.Run.run(Run.java:1454) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) com.tek42.perforce.PerforceException: No output for: c:\program files\perforce\p4.exe users null at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:384) at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292) at com.tek42.perforce.parse.Users.exists(Users.java:61) at com.tek42.perforce.parse.Users.getUser(Users.java:54) at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:64) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:335) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:255) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:247) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:207) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171) at hudson.model.Run.run(Run.java:1454) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) com.tek42.perforce.PerforceException: No output for: c:\program files\perforce\p4.exe users null at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:384) at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:292) at com.tek42.perforce.parse.Users.exists(Users.java:61) at com.tek42.perforce.parse.Users.getUser(Users.java:54) at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:64
[JIRA] (JENKINS-13114) dropdown views taskbar: error when saving jenkins config page
Steve Roth created JENKINS-13114:
Summary: dropdown views taskbar: error when saving jenkins config
page
Key: JENKINS-13114
URL: https://issues.jenkins-ci.org/browse/JENKINS-13114
Project: Jenkins
Issue Type: Bug
Components: dropdown-viewstabbar
Affects Versions: current
Reporter: Steve Roth
Assignee: jieryn
I have the dropdown views tabbar enabled, and am usign Jenkins 1.455 When I
go to save the main Jenkins config page, I see this CNF exception in the
browser:
exception
javax.servlet.ServletException: java.lang.IllegalArgumentException: Failed to
instantiate class hudson.views.ViewsTabBar from
{"showJobCount":false,"stapler-class":["hudson.views.DefaultViewsTabBar","hudson.views.tabbar.DropDownViewsTabBar"]}
org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:605)
org.kohsuke.stapler.Stapler.invoke(Stapler.java:648)
org.kohsuke.stapler.Stapler.invoke(Stapler.java:477)
org.kohsuke.stapler.Stapler.service(Stapler.java:159)
javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95)
net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:185)
net.bull.javamelody.MonitoringFilter.doFilter(MonitoringFilter.java:159)
net.bull.javamelody.PluginMonitoringFilter.doFilter(PluginMonitoringFilter.java:86)
org.jvnet.hudson.plugins.monitoring.HudsonMonitoringFilter.doFilter(HudsonMonitoringFilter.java:84)
hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
hudson.plugins.audit_trail.AuditTrailFilter.doFilter(AuditTrailFilter.java:66)
hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
oracle.boulderlabs.jenkins.validatorkiller.ValidatorKiller.doFilter(ValidatorKiller.java:63)
hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:98)
hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87)
hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:61)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66)
hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164)
hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:81)
root cause
java.lang.IllegalArgumentException: Failed to instantiate class
hudson.views.ViewsTabBar from
{"showJobCount":false,"stapler-class":["hudson.views.DefaultViewsTabBar","hudson.views.tabbar.DropDownViewsTabBar"]}
org.kohsuke.stapler.RequestImpl$TypePair.convertJSON(RequestImpl.java:633)
org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:377)
org.kohsuke.stapler.RequestImpl.bindJSON(RequestImpl.java:373)
hudson.views.ViewsTabBar$GlobalConfigurationImpl.configure(ViewsTabBar.java:84)
jenkins.model.Jenkins.configureDescriptor(Jenkins.java:2620)
jenkins.model.Jenkins.doConfigSubmit(Jenkins.java:2583)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(Native
[JIRA] (JENKINS-13035) Duplicate Views Tab Bar option
[
https://issues.jenkins-ci.org/browse/JENKINS-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160335#comment-160335
]
Steve Roth commented on JENKINS-13035:
--
me too
> Duplicate Views Tab Bar option
> --
>
> Key: JENKINS-13035
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13035
> Project: Jenkins
> Issue Type: Bug
> Components: core
> Environment: Jenkins 1.454
>Reporter: mdp
>Priority: Minor
>
> On the "Configure System" screen there are two identically named ("Views Tab
> Bar") options.
> The first one has help and lets me choose between "CountJobs Views TabBar"
> (an installed plugin) and "Default Views TabBar".
> The second one does not have help and its dropbox is empty.
> In config.xml there are two settings present:
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13113) Xunit Plugin detects MSTEST "NotExecuted" as "Passed" instead of "Skipped"
Dirk Kuypers created JENKINS-13113: -- Summary: Xunit Plugin detects MSTEST "NotExecuted" as "Passed" instead of "Skipped" Key: JENKINS-13113 URL: https://issues.jenkins-ci.org/browse/JENKINS-13113 Project: Jenkins Issue Type: Bug Components: xunit Affects Versions: current Environment: Jenkins 1.455 xunit 1.40 Reporter: Dirk Kuypers Assignee: gbois We had an out of memory exception while running our MSTEST unit tests which caused all subsequent tests to be NotExecuted. Unfortunately those "NotExecuted" tests were counted as passed, so the test job succeeded instead of failing. One example from the TRX file: The transformation in the junitResult.xml file: NaN ConformanceWcdmaCompleteTest.BandSpecificTests TestcaseWcdmaTxIntermod_5_12__FDD9 false 0 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10436) Jenkins Environment Variables are not set when using a freestyle "Invoke top-level Maven Targets" that is restricted to execute on a slave
[
https://issues.jenkins-ci.org/browse/JENKINS-10436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160334#comment-160334
]
Marco Vermeulen commented on JENKINS-10436:
---
Has anyone taken a further look into this?
This is a major issue and has been untouched for going on a year.
> Jenkins Environment Variables are not set when using a freestyle "Invoke
> top-level Maven Targets" that is restricted to execute on a slave
>
>
> Key: JENKINS-10436
> URL: https://issues.jenkins-ci.org/browse/JENKINS-10436
> Project: Jenkins
> Issue Type: Bug
> Components: maven2
> Environment: jenkins 1.421
>Reporter: Scott MacDonald
>
> When creating a free style build and selecting "invoke top-level Maven
> targets", Jenkins exposes functionality to utilize jenkins environment
> varibale references.
> "The same variables can be used in command-line arguments (as if you are
> invoking this from shell). For example, you can specify
> -DresultsFile=${WORKSPACE}/${BUILD_TAG}.results.txt"
> When the job is restricted to run on a slave, the values of those environment
> variables should be based on the slaves environment variables name-value
> pairs. The salve name value pairs are not being substituted as they do in a
> regular maven based job.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13103) Build hangs trying to send email if an email address isn't defined in Active Directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160333#comment-160333 ] Rob Petti commented on JENKINS-13103: - It's just converting usernames to email addresses, not necessarily perforce usernames. The Mail resolver API is not given any hint as to where the username's information should be retrieved from, so it has to iterate through all registered mail resolvers. Can you get me a threadDump for 1.3.10 during a hang? You can get it by simply hitting JENKINS_URL/threadDump once one of your jobs hangs. > Build hangs trying to send email if an email address isn't defined in Active > Directory > -- > > Key: JENKINS-13103 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13103 > Project: Jenkins > Issue Type: Bug > Components: perforce > Environment: Jenkins - 1.455 > email-ext 2.18 > perforce plugin - 1.3.9 > AD plugin - 1.26 > Windows 2003 master > Linux x64 slave >Reporter: aflat > > I think the hang is due to the email-ext plugin, but there may be a perforce > plugin issue as well. > https://issues.jenkins-ci.org/browse/JENKINS-13102 > What I don't understand is why is the perforce plugin asking for the email > from Active directory? The email is defined in perforce, shouldn't it just > use that when creating the email list? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13112) Adding any post-build step as a build step causes exception
Anthony Hartwig created JENKINS-13112: - Summary: Adding any post-build step as a build step causes exception Key: JENKINS-13112 URL: https://issues.jenkins-ci.org/browse/JENKINS-13112 Project: Jenkins Issue Type: Bug Components: any-buildstep Environment: Windows Server 2008 Reporter: Anthony Hartwig Assignee: bap Attachments: stacktrace.txt When attempting to add a post build step as a build step, then click save, an exception is thrown. Stack trace attached. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13111) Plugin activation cause a NullPointerException
Sébastien Heurtematte created JENKINS-13111: --- Summary: Plugin activation cause a NullPointerException Key: JENKINS-13111 URL: https://issues.jenkins-ci.org/browse/JENKINS-13111 Project: Jenkins Issue Type: Bug Components: pegdown-formatter-plugin Affects Versions: current Environment: Debian x64 Reporter: Sébastien Heurtematte Assignee: bap Attachments: stacktrace-monitoring.log, stacktrace-without-monitoring.log NullPointerException in the jenkins 1.455 I have different stacktrace depends on monitoring plugin or not -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13027) Perforce plugin will sometimes set an incorrect workspace view
[
https://issues.jenkins-ci.org/browse/JENKINS-13027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160330#comment-160330
]
Richard Taylor commented on JENKINS-13027:
--
Amazing found the problem immediately, as you can see form the output there is
a trailing space on the ${BRANCH} variable. Depending on the use case this has
the potential to cause a problem as below but in other places go through fine.
I've had the same issue with Ant as the java property serialisation seems very
sensitive to trailing spaces. The trailing space is the result of an auto
generated file and the short comings of DOS file redirection :-(
I think it would be good to leave these changes in the next version of your
perforce plugin incause it happen again or for anyone else :-)
Thanks again
Rich
13:13:10 Warning: Client Spec line invalid, ignoring.
(//depot/evolution/evo11/branches/evo11dx11 /... //workspace-name/...
)
13:13:10 Warning: Client Spec line invalid, ignoring.
(-//depot/evolution/evo11/branches/evo11dx11 /MS3/mb
//workspace-name/MS3/mb
)
13:13:10 Warning: Client Spec line invalid, ignoring.
(-//depot/evolution/evo11/branches/evo11dx11 /MS3/pds
//workspace-name/MS3/pds
)
13:13:10 Warning: Client Spec line invalid, ignoring.
(-//depot/evolution/evo11/branches/evo11dx11 /MS3/ma
//workspace-name/MS3/ma
)
13:13:10 Warning: Client Spec line invalid, ignoring.
(-//depot/evolution/evo11/branches/evo11dx11 /MS3/ZTL
//workspace-name/MS3/ZTL
)
13:13:10 Changing P4 Client View from:
13:13:10 //depot/evolution/evo11/releases/release-1.12/...
//jenkins_gbwwsrunbld09_evo11main/...
13:13:10-//depot/evolution/evo11/releases/release-1.12/MS3/mb
//jenkins_gbwwsrunbld09_evo11main/MS3/mb
13:13:10-//depot/evolution/evo11/releases/release-1.12/MS3/pds
//jenkins_gbwwsrunbld09_evo11main/MS3/pds
13:13:10-//depot/evolution/evo11/releases/release-1.12/MS3/ma
//jenkins_gbwwsrunbld09_evo11main/MS3/ma
13:13:10-//depot/evolution/evo11/releases/release-1.12/MS3/ZTL
//jenkins_gbwwsrunbld09_evo11main/MS3/ZTL
13:13:10//depot/evolution/evo11/external/3rdParty/...
//jenkins_gbwwsrunbld09_evo11main/3rdParty/...
13:13:10//depot/evolution/evo11/external/Platform/...
//jenkins_gbwwsrunbld09_evo11main/Platform/...
13:13:10//depot/evolution/evo11/external/WWS/...
//jenkins_gbwwsrunbld09_evo11main/WWS/...
13:13:10
-//depot/evolution/evo11/external/WWS/ATG/1.33.0/ATGTools/UnitTests/...
//jenkins_gbwwsrunbld09_evo11main/WWS/ATG/1.33.0/ATGTools/UnitTests/...
13:13:10
13:13:10 Changing P4 Client View to:
13:13:10//depot/evolution/evo11/external/3rdParty/...
//jenkins_gbwwsrunbld09_evo11main/3rdParty/...
13:13:10//depot/evolution/evo11/external/Platform/...
//jenkins_gbwwsrunbld09_evo11main/Platform/...
13:13:10//depot/evolution/evo11/external/WWS/...
//jenkins_gbwwsrunbld09_evo11main/WWS/...
13:13:10
-//depot/evolution/evo11/external/WWS/ATG/1.33.0/ATGTools/UnitTests/...
//jenkins_gbwwsrunbld09_evo11main/WWS/ATG/1.33.0/ATGTools/UnitTests/...
13:13:10 Saving modified client jenkins_gbwwsrunbld09_evo11main
> Perforce plugin will sometimes set an incorrect workspace view
> --
>
> Key: JENKINS-13027
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13027
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
>Affects Versions: current
> Environment: Jenkins Master 1.454 OS Windows Server 2008 SP2
> Jenkins Slave 2.12 OS Windows Server 2008 R2
>Reporter: Richard Taylor
>Assignee: Rob Petti
> Fix For: current
>
> Attachments: config.zip
>
>
> Perforce plugin will sometimes set an incorrect workspace view.
> The job has perforce Client View Type set to View Map with the following
> details
> //depot/evolution/evo11/${BRANCH}/... //workspace-name/...
> -//depot/evolution/evo11/${BRANCH}/MS3/mb //workspace-name/MS3/mb
> -//depot/evolution/evo11/${BRANCH}/MS3/pds //workspace-name/MS3/pds
> -//depot/evolution/evo11/${BRANCH}/MS3/ma //workspace-name/MS3/ma
> -//depot/evolution/evo11/${BRANCH}/MS3/ZTL //workspace-name/MS3/ZTL
> //depot/evolution/evo11/external/3rdParty/... //workspace-name/3rdParty/...
> //depot/evolution/evo11/external/Platform/... //workspace-name/Platform/...
> //depot/evolution/evo11/external/WWS/... //workspace-name/WWS/...
> -//depot/evolution/evo11/external/WWS/ATG/1.33.0/ATGTools/UnitTests/...
> //workspace-name/WWS/ATG/1.33.0/ATGTools/UnitTests/...
> The ${BRANCH} is set as a job parameter but the purposes of our current use
> case it is always the same default value.
> The job is set to run on a small pool of slaves with label. This pool of
> sl
[JIRA] (JENKINS-13027) Perforce plugin will sometimes set an incorrect workspace view
[
https://issues.jenkins-ci.org/browse/JENKINS-13027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Richard Taylor resolved JENKINS-13027.
--
Resolution: Fixed
Fixed with addition debug info
> Perforce plugin will sometimes set an incorrect workspace view
> --
>
> Key: JENKINS-13027
> URL: https://issues.jenkins-ci.org/browse/JENKINS-13027
> Project: Jenkins
> Issue Type: Bug
> Components: perforce
>Affects Versions: current
> Environment: Jenkins Master 1.454 OS Windows Server 2008 SP2
> Jenkins Slave 2.12 OS Windows Server 2008 R2
>Reporter: Richard Taylor
>Assignee: Rob Petti
> Fix For: current
>
> Attachments: config.zip
>
>
> Perforce plugin will sometimes set an incorrect workspace view.
> The job has perforce Client View Type set to View Map with the following
> details
> //depot/evolution/evo11/${BRANCH}/... //workspace-name/...
> -//depot/evolution/evo11/${BRANCH}/MS3/mb //workspace-name/MS3/mb
> -//depot/evolution/evo11/${BRANCH}/MS3/pds //workspace-name/MS3/pds
> -//depot/evolution/evo11/${BRANCH}/MS3/ma //workspace-name/MS3/ma
> -//depot/evolution/evo11/${BRANCH}/MS3/ZTL //workspace-name/MS3/ZTL
> //depot/evolution/evo11/external/3rdParty/... //workspace-name/3rdParty/...
> //depot/evolution/evo11/external/Platform/... //workspace-name/Platform/...
> //depot/evolution/evo11/external/WWS/... //workspace-name/WWS/...
> -//depot/evolution/evo11/external/WWS/ATG/1.33.0/ATGTools/UnitTests/...
> //workspace-name/WWS/ATG/1.33.0/ATGTools/UnitTests/...
> The ${BRANCH} is set as a job parameter but the purposes of our current use
> case it is always the same default value.
> The job is set to run on a small pool of slaves with label. This pool of
> slaved is used for building packages from diferent branches.
> We get occasional build failures due to perforce incorrectly setting the
> workspace view. These errors can only be fixed by a clean and sync. As a full
> clean and sync takes 2 hours this is a significant issue.
> - Jenkins build log --
> 21:02:27 Started by timer
> 21:02:27 Building remotely on gbwwsrunbld08 in workspace
> c:\jenkins\workspace\evo11main
> 21:02:27 Using remote perforce client: jenkins_gbwwsrunbld08_evo11main
> 21:02:27 [evo11main] $ "c:\\program files\\perforce\\p4.exe" workspace -o
> jenkins_gbwwsrunbld08_evo11main
> 21:02:27 [evo11main] $ "c:\\program files\\perforce\\p4.exe" login -p
> 21:02:27 [evo11main] $ "c:\\program files\\perforce\\p4.exe" -P
> 831EC39454600F1AF16985DE3AD2AFCD workspace -o jenkins_gbwwsrunbld08_evo11main
> 21:02:27 Changing P4 Client View from:
> 21:02:27 //depot/evolution/evo11/branches/evo11dx11/...
> //jenkins_gbwwsrunbld08_evo11main/...
> 21:02:27 -//depot/evolution/evo11/branches/evo11dx11/MS3/mb
> //jenkins_gbwwsrunbld08_evo11main/MS3/mb
> 21:02:27 -//depot/evolution/evo11/branches/evo11dx11/MS3/pds
> //jenkins_gbwwsrunbld08_evo11main/MS3/pds
> 21:02:27 -//depot/evolution/evo11/branches/evo11dx11/MS3/ma
> //jenkins_gbwwsrunbld08_evo11main/MS3/ma
> 21:02:27 -//depot/evolution/evo11/branches/evo11dx11/MS3/ZTL
> //jenkins_gbwwsrunbld08_evo11main/MS3/ZTL
> 21:02:27 //depot/evolution/evo11/external/3rdParty/...
> //jenkins_gbwwsrunbld08_evo11main/3rdParty/...
> 21:02:27 //depot/evolution/evo11/external/Platform/...
> //jenkins_gbwwsrunbld08_evo11main/Platform/...
> 21:02:27 //depot/evolution/evo11/external/WWS/...
> //jenkins_gbwwsrunbld08_evo11main/WWS/...
> 21:02:27
> -//depot/evolution/evo11/external/WWS/ATG/1.33.0/ATGTools/UnitTests/...
> //jenkins_gbwwsrunbld08_evo11main/WWS/ATG/1.33.0/ATGTools/UnitTests/...
> 21:02:27
> 21:02:27 Changing P4 Client View to:
> 21:02:27//depot/evolution/evo11/external/3rdParty/...
> //jenkins_gbwwsrunbld08_evo11main/3rdParty/...
> 21:02:27//depot/evolution/evo11/external/Platform/...
> //jenkins_gbwwsrunbld08_evo11main/Platform/...
> 21:02:27//depot/evolution/evo11/external/WWS/...
> //jenkins_gbwwsrunbld08_evo11main/WWS/...
> 21:02:27 Saving modified client jenkins_gbwwsrunbld08_evo11main
> As you can see perforce has removed the part view which was using the
> ${BRANCH} parameter and has also remove the final -// line which was not
> parameterised.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13103) Build hangs trying to send email if an email address isn't defined in Active Directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160329#comment-160329 ] aflat commented on JENKINS-13103: - I originally used 1.3.10, same issue. I rolled back to 1.3.9 because I didn't think I saw it in that build, but I see it now. I would have thought the perforce mail resolver was first, since it is converting perforce usernames to email addresses. > Build hangs trying to send email if an email address isn't defined in Active > Directory > -- > > Key: JENKINS-13103 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13103 > Project: Jenkins > Issue Type: Bug > Components: perforce > Environment: Jenkins - 1.455 > email-ext 2.18 > perforce plugin - 1.3.9 > AD plugin - 1.26 > Windows 2003 master > Linux x64 slave >Reporter: aflat > > I think the hang is due to the email-ext plugin, but there may be a perforce > plugin issue as well. > https://issues.jenkins-ci.org/browse/JENKINS-13102 > What I don't understand is why is the perforce plugin asking for the email > from Active directory? The email is defined in perforce, shouldn't it just > use that when creating the email list? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13110) Automatic tool installer: Install from mongodb.org option doesn't include a label field
[ https://issues.jenkins-ci.org/browse/JENKINS-13110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sean Reilly updated JENKINS-13110: -- Description: I first noticed this with the MongoDB plugin (v 1.1), but then realised that this occurs with all automatic tool installers that I can find. When choosing an automatic tool installer of type "Extract \*.zip/\*.tar.gz", or "Run Command", the UI provides a "label" field, which can be used to configure which kinds of nodes use a specific installer. When I have slaves on many platforms, this allows me to install (for example) the mongodb-linux-x86_64 build on a linux slave, and a mongo osx build on an osx slave. The "Install from mongodb.org" option doesn't include a label field, even though I can configure multiple installers for different platforms. The first installer is always used no matter what. Update: while writing this bug report, I realised that this behaviour seems to be present for all "Install from " options, across many plugins. This behaviour is fine for a platform independent tool like ant, but doesn't work well for native code (such as mongodb). *Workaround* Create "Extract \*.zip/\*.tar.gz" installers with appropriate labels and download locations such as "http://downloads.mongodb.org/linux/mongodb-linux-x86_64-2.0.3.tgz"; to accomplish the same thing. Note that this won't work for more complicated automated tool installers like the one that installs java from java.sun.com. was: I first noticed this with the MongoDB plugin (v 1.1), but then realised that this occurs with all automatic tool installers that I can find. When choosing an automatic tool installer of type "Extract *.zip/*.tar.gz", or "Run Command", the UI provides a "label" field, which can be used to configure which kinds of nodes use a specific installer. When I have slaves on many platforms, this allows me to install (for example) the mongodb-linux-x86_64 build on a linux slave, and a mongo osx build on an osx slave. The "Install from mongodb.org" option doesn't include a label field, even though I can configure multiple installers for different platforms. The first installer is always used no matter what. Update: while writing this bug report, I realised that this behaviour seems to be present for all "Install from " options, across many plugins. This behaviour is fine for a platform independent tool like ant, but doesn't work well for native code (such as mongodb). *Workaround* Create two "Extract *.zip/*.tar.gz" installers with appropriate labels and download locations such as "http://downloads.mongodb.org/linux/mongodb-linux-x86_64-2.0.3.tgz"; to accomplish the same thing. Note that this won't work for more complicated automated tool installers like the one that installs java from java.sun.com. > Automatic tool installer: Install from mongodb.org option doesn't include a > label field > --- > > Key: JENKINS-13110 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13110 > Project: Jenkins > Issue Type: Bug > Components: plugin > Environment: Jenkins version 1.455 >Reporter: Sean Reilly >Priority: Minor > > I first noticed this with the MongoDB plugin (v 1.1), but then realised that > this occurs with all automatic tool installers that I can find. > When choosing an automatic tool installer of type "Extract \*.zip/\*.tar.gz", > or "Run Command", the UI provides a "label" field, which can be used to > configure which kinds of nodes use a specific installer. When I have slaves > on many platforms, this allows me to install (for example) the > mongodb-linux-x86_64 build on a linux slave, and a mongo osx build on an osx > slave. > The "Install from mongodb.org" option doesn't include a label field, even > though I can configure multiple installers for different platforms. The first > installer is always used no matter what. > Update: while writing this bug report, I realised that this behaviour seems > to be present for all "Install from " options, across many plugins. > This behaviour is fine for a platform independent tool like ant, but doesn't > work well for native code (such as mongodb). > *Workaround* > Create "Extract \*.zip/\*.tar.gz" installers with appropriate labels and > download locations such as > "http://downloads.mongodb.org/linux/mongodb-linux-x86_64-2.0.3.tgz"; to > accomplish the same thing. Note that this won't work for more complicated > automated tool installers like the one that installs java from java.sun.com. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see:
[JIRA] (JENKINS-13110) Automatic tool installer: Install from mongodb.org option doesn't include a label field
Sean Reilly created JENKINS-13110: - Summary: Automatic tool installer: Install from mongodb.org option doesn't include a label field Key: JENKINS-13110 URL: https://issues.jenkins-ci.org/browse/JENKINS-13110 Project: Jenkins Issue Type: Bug Components: plugin Environment: Jenkins version 1.455 Reporter: Sean Reilly Priority: Minor I first noticed this with the MongoDB plugin (v 1.1), but then realised that this occurs with all automatic tool installers that I can find. When choosing an automatic tool installer of type "Extract *.zip/*.tar.gz", or "Run Command", the UI provides a "label" field, which can be used to configure which kinds of nodes use a specific installer. When I have slaves on many platforms, this allows me to install (for example) the mongodb-linux-x86_64 build on a linux slave, and a mongo osx build on an osx slave. The "Install from mongodb.org" option doesn't include a label field, even though I can configure multiple installers for different platforms. The first installer is always used no matter what. Update: while writing this bug report, I realised that this behaviour seems to be present for all "Install from " options, across many plugins. This behaviour is fine for a platform independent tool like ant, but doesn't work well for native code (such as mongodb). *Workaround* Create two "Extract *.zip/*.tar.gz" installers with appropriate labels and download locations such as "http://downloads.mongodb.org/linux/mongodb-linux-x86_64-2.0.3.tgz"; to accomplish the same thing. Note that this won't work for more complicated automated tool installers like the one that installs java from java.sun.com. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13085) Environment Variable Injection doesn't work when project run on slave node that sets the same variable
[ https://issues.jenkins-ci.org/browse/JENKINS-13085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160328#comment-160328 ] gbois commented on JENKINS-13085: - To make sure to reproduce the issue, could you attach your job configuration file and your global infrastructure configuration file ($JENKINS_HOME/config.xml and $JENKINS_HOME/jobs//config.xml)? > Environment Variable Injection doesn't work when project run on slave node > that sets the same variable > -- > > Key: JENKINS-13085 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13085 > Project: Jenkins > Issue Type: Bug > Components: envinject >Affects Versions: current >Reporter: Josh Davidson >Assignee: gbois > > When a slave node is configured to append/prepend to a variable (Node > Properties->Environment Variables) that is used by EnvInject within a job, > the injection fails. If the slave node simply sets the variable (i.e. > doesn't reference the same variable in the act of setting) it works fine. > Consider the following job, which has a single build step: echo $PATH > In Build Environment->Inject, there is a single line in the properties > content box: PATH=/opt/bin:$PATH > That's the job. Now, the slave node, also sets the PATH variable. Let's > first look at a working example, where the slave node sets PATH to: > /data/goesrsw/goesr/bin Here is the output: > [EnvInject] - Executing scripts and injecting environment variables after the > SCM step. > [EnvInject] - Injecting as environment variables the properties content > PATH=/opt/bin:$PATH > [EnvInject] - Variables injected successfully. > [aaa] $ bash -xe /tmp/hudson5838824311735104563.sh > + echo /opt/bin:/data/goesrsw/goesr/bin > /opt/bin:/data/goesrsw/goesr/bin > Notifying upstream projects of job completion > Finished: SUCCESS > Ok, so to demonstrate the problem, change the PATH in the slave node to: > /data/goesrsw/goesr/bin:$PATH > Now, here's the output: > [EnvInject] - Executing scripts and injecting environment variables after the > SCM step. > [EnvInject] - Injecting as environment variables the properties content > PATH=/opt/bin:$PATH > [EnvInject] - Variables injected successfully. > [EnvInject] - Unset unresolved 'PATH' variable. > [aaa] $ bash -xe /tmp/hudson3276485997068093627.sh > + echo > /data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/home/goesrjen/bin:/usr/local/bin:/usr/local/sbin:/app/share/bin:/app/share/sbin:/usr/bin/X11:/bin:/usr/bin:/sbin:/usr/sbin:.:/app/rc52_test1_perl:/data/goesrsw/WindRiver/gnu/4.1.2-vxworks-6.6/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/foundation/4.1.1/x86-linux2/lib/tcl8.4/Wind > /data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/data/goesrsw/goesr/bin:/home/goesrjen/bin:/usr/local/bin:/usr/local/sbin:/app/share/bin:/app/share/sbin:/usr/bin/X11:/bin:/usr/bin:/sbin:/usr/sbin:.:/app/rc52_test1_perl:/data/goesrsw/WindRiver/gnu/4.1.2-vxworks-6.6/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/x86-linux2/bin:/data/goesrsw/WindRiver/workbench-3.0/foundation/4.1.1/x86-linux2/lib/tcl8.4/Wind > Notifying upstream projects of job completion > Finished: SUCCESS > As you can see, the injection didn't work. /opt/bin is nowhere to be found. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11853) Duplicate build numbers in the Build History
[ https://issues.jenkins-ci.org/browse/JENKINS-11853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160327#comment-160327 ] Maximilian Kernbach commented on JENKINS-11853: --- Still happens in Jenkins 1.455. Can someone please look into it? What information is needed to get this issue fixed? > Duplicate build numbers in the Build History > - > > Key: JENKINS-11853 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11853 > Project: Jenkins > Issue Type: Bug > Components: build-pipeline > Environment: Operating System: Linux-CentOS > gcc version: 4.4.4 >Reporter: nanda kishore > Labels: build > Attachments: duplicate_build_numbers.png > > > I have recently upgraded hudson to latest jenkins(1.437 and later to 1.439). > Ofcourse the migration went pretty smooth, but recently I started facing a > problem related the existing build numbers of one particular job. In the > Build history(left sidebar of any job page) I am > seeing duplicate build numbers. Check the first attachment named > "duplicate_build_numbers". When you reload the same job page, it displays > only one unique build and no duplicate builds. But after a few seconds(may be > 3 or 4 secs) the duplicate build is coming up. > I checked the "builds" directory related to that job and found only one > directory related to the build. For the build mentioned in the > figure I saw only one directory named: "2011-10-16_01-06-08" > So is there any issue in the way Build History is shown to the users or Am I > missing anything ? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13096) should be able to use Jenkins Environment Variables (JENKINS_HOME, WORKSPACE) in the properties file path
[ https://issues.jenkins-ci.org/browse/JENKINS-13096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160326#comment-160326 ] gbois commented on JENKINS-13096: - Did you try to inject variables after a SCM checkout? Check 'Inject environment variables to the build process' in the 'Build environment' section. In the properties file path field, you can specify a relative file path to your workspace (and at this step, the workspace is provisioned by your SCM checkout). > should be able to use Jenkins Environment Variables (JENKINS_HOME, WORKSPACE) > in the properties file path > - > > Key: JENKINS-13096 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13096 > Project: Jenkins > Issue Type: Improvement > Components: envinject >Affects Versions: current >Reporter: Maddy Goss >Assignee: gbois >Priority: Minor > Labels: plugin > > I keep my generic project configuration in a properties file which is in a > project that is checked into SCM. I would like to be able to update that file > in a parent job, and then consume it (via > $WORKSPACE/projectname/global.properties). Currently, you have to use the > full path to the properties file, which makes my configuration brittle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13096) should be able to use Jenkins Environment Variables (JENKINS_HOME, WORKSPACE) in the properties file path
[ https://issues.jenkins-ci.org/browse/JENKINS-13096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13096 started by gbois. > should be able to use Jenkins Environment Variables (JENKINS_HOME, WORKSPACE) > in the properties file path > - > > Key: JENKINS-13096 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13096 > Project: Jenkins > Issue Type: Improvement > Components: envinject >Affects Versions: current >Reporter: Maddy Goss >Assignee: gbois >Priority: Minor > Labels: plugin > > I keep my generic project configuration in a properties file which is in a > project that is checked into SCM. I would like to be able to update that file > in a parent job, and then consume it (via > $WORKSPACE/projectname/global.properties). Currently, you have to use the > full path to the properties file, which makes my configuration brittle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13025) Active Directory Plugin version 1.26 results in "org.acegisecurity.BadCredentialsException: Failed to retrieve user information" when 1.24 does not
[ https://issues.jenkins-ci.org/browse/JENKINS-13025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160325#comment-160325 ] Troels Madsen commented on JENKINS-13025: - I'm also observing this issue using Jenkins 1.454 and active directory plugin 1.26 > Active Directory Plugin version 1.26 results in > "org.acegisecurity.BadCredentialsException: Failed to retrieve user > information" when 1.24 does not > --- > > Key: JENKINS-13025 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13025 > Project: Jenkins > Issue Type: Bug > Components: active-directory > Environment: jenkins-1.424.6-1.1.noarch RPM on x86_64 CentOS 6.2, > active directory plugin 1.24 versus 1.26 >Reporter: Don Lindsay > > All of our login IDs are LDAP/Active Directory names. We can log in. When we > upgraded the Active Directory plugin to 1.26, we noticed that the "Configure > System" contained error indications. Specifically, under "Authorization", > there is a "user/group" list, and each username had been replaced by an error > indication. Examination showed the same error for each username. For example: > org.acegisecurity.BadCredentialsException: Failed to retrieve user > information for d_lindsay; nested exception is > javax.naming.NamingException: [LDAP: error code 1 - : > LdapErr: DSID-0C090627, comment: In order to perform this > operation a successful bind must be completed on the > connection., data 0, vece\ufffd]; remaining name > 'DC=ocarina,DC=local' at > hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProv\ > ider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:231) > Reverting to the 1.24 plugin fixed this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13025) Active Directory Plugin version 1.26 results in "org.acegisecurity.BadCredentialsException: Failed to retrieve user information" when 1.24 does not
[ https://issues.jenkins-ci.org/browse/JENKINS-13025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=160324#comment-160324 ] Rishi Darandale commented on JENKINS-13025: --- I am also observing this issue with Jenkins 1.450 and active directory plugin 1.26. > Active Directory Plugin version 1.26 results in > "org.acegisecurity.BadCredentialsException: Failed to retrieve user > information" when 1.24 does not > --- > > Key: JENKINS-13025 > URL: https://issues.jenkins-ci.org/browse/JENKINS-13025 > Project: Jenkins > Issue Type: Bug > Components: active-directory > Environment: jenkins-1.424.6-1.1.noarch RPM on x86_64 CentOS 6.2, > active directory plugin 1.24 versus 1.26 >Reporter: Don Lindsay > > All of our login IDs are LDAP/Active Directory names. We can log in. When we > upgraded the Active Directory plugin to 1.26, we noticed that the "Configure > System" contained error indications. Specifically, under "Authorization", > there is a "user/group" list, and each username had been replaced by an error > indication. Examination showed the same error for each username. For example: > org.acegisecurity.BadCredentialsException: Failed to retrieve user > information for d_lindsay; nested exception is > javax.naming.NamingException: [LDAP: error code 1 - : > LdapErr: DSID-0C090627, comment: In order to perform this > operation a successful bind must be completed on the > connection., data 0, vece\ufffd]; remaining name > 'DC=ocarina,DC=local' at > hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProv\ > ider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:231) > Reverting to the 1.24 plugin fixed this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12761) tfs plugin :failed to record scm polling
[ https://issues.jenkins-ci.org/browse/JENKINS-12761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-12761 stopped by jlin sai. > tfs plugin :failed to record scm polling > - > > Key: JENKINS-12761 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12761 > Project: Jenkins > Issue Type: Bug > Components: tfs >Affects Versions: current > Environment: Computer : windows xp/7 ,x86 Architecture > Tomcat :Version 7.0.11 > Jenkins:Version 1.450 > tfs plugin:Version 1.20 >Reporter: jlin sai >Assignee: drewrm > Labels: plugin > Fix For: current > > Attachments: ErrorInfo.jpg > > > I get a failure when I use the tfs plugin of Jenkins. > The Source Code management tool what I use is Team Foundation Server > 2010,when I manage the poll SCM in Jenkins,and want to trigger a build > automatic when it detected a change between TFS server and Personal workspace > , a failure hanppened ,which information is "failed to record scm polling". > Three months ago ,the version of tfs plugin is 1.17,I encount the failure > ,and now the problem isn't resolved. I have been searched a method for a long > time ,but not get it . > I don't know what the reason is ,so please to help me to fixed the > problem.Thank you very much! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12761) tfs plugin :failed to record scm polling
[ https://issues.jenkins-ci.org/browse/JENKINS-12761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-12761 started by drewrm. > tfs plugin :failed to record scm polling > - > > Key: JENKINS-12761 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12761 > Project: Jenkins > Issue Type: Bug > Components: tfs >Affects Versions: current > Environment: Computer : windows xp/7 ,x86 Architecture > Tomcat :Version 7.0.11 > Jenkins:Version 1.450 > tfs plugin:Version 1.20 >Reporter: jlin sai >Assignee: drewrm > Labels: plugin > Fix For: current > > Attachments: ErrorInfo.jpg > > > I get a failure when I use the tfs plugin of Jenkins. > The Source Code management tool what I use is Team Foundation Server > 2010,when I manage the poll SCM in Jenkins,and want to trigger a build > automatic when it detected a change between TFS server and Personal workspace > , a failure hanppened ,which information is "failed to record scm polling". > Three months ago ,the version of tfs plugin is 1.17,I encount the failure > ,and now the problem isn't resolved. I have been searched a method for a long > time ,but not get it . > I don't know what the reason is ,so please to help me to fixed the > problem.Thank you very much! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13109) Huge changelogs eat all the Java memory
Mikko Tapaninen created JENKINS-13109:
-
Summary: Huge changelogs eat all the Java memory
Key: JENKINS-13109
URL: https://issues.jenkins-ci.org/browse/JENKINS-13109
Project: Jenkins
Issue Type: Bug
Components: perforce
Environment: Windows Server 2008 HPC Edition
64-bit JVM 1.6.0_29
Running Jenkins service with "-Xrs -Xmx2048m
-Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar
"%BASE%\jenkins.war" --httpPort=8080"
Reporter: Mikko Tapaninen
With really huge changelists the p4 plugin can run out of java heap space. At
least it looks like the reason for memory problems would be huge changelog.xml
files. An example case:
- a changelist with > 40 files
- results in a changelog.xml size > 110MB
- Jenkins runs out of memory: {{java.lang.OutOfMemoryError: Java heap space}}
Maybe there should be an option to limit the amount of files that p4 plugin
reads to from changelists?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
