[JIRA] (JENKINS-12830) Java Heap exception for the post build task
stibbons created JENKINS-12830: -- Summary: Java Heap exception for the post build task Key: JENKINS-12830 URL: https://issues.jenkins-ci.org/browse/JENKINS-12830 Project: Jenkins Issue Type: Bug Components: postbuild-task Reporter: stibbons Post build task recently started to generate exception, while it was working great before (upgrade to jenkins 1.449 or 1.450). Here is the exception trace. It occurs right after "Archiving artifacts" FATAL: Java heap space 09:36:53 java.lang.OutOfMemoryError: Java heap space 09:36:53at java.lang.AbstractStringBuilder.(AbstractStringBuilder.java:62) 09:36:53at java.lang.StringBuilder.(StringBuilder.java:97) 09:36:53at hudson.Util.loadFile(Util.java:171) 09:36:53at hudson.model.Run.getLog(Run.java:1562) 09:36:53at hudson.plugins.postbuildtask.PostbuildTask.perform(PostbuildTask.java:99) 09:36:53at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) 09:36:53at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:700) 09:36:53at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:675) 09:36:53at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:653) 09:36:53at hudson.model.Build$RunnerImpl.post2(Build.java:162) 09:36:53at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:622) 09:36:53at hudson.model.Run.run(Run.java:1434) 09:36:53at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) 09:36:53at hudson.model.ResourceController.execute(ResourceController.java:88) 09:36:53at hudson.model.Executor.run(Executor.java:238) -- 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-10771) hudson.util.IOException2: remote file operation failed
[
https://issues.jenkins-ci.org/browse/JENKINS-10771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159272#comment-159272
]
Markus Hjerto commented on JENKINS-10771:
-
Usually it helps to disconnect and reconnect the slave here, but it did not
work this time. I had to restart the entire service. Running Jenkins 1.451 on
CentOS 5.7.
{code}
hudson.util.IOException2: remote file operation failed:
/tmp/jenkins-workspace/Checkout at hudson.remoting.Channel@377e66a9:svnworker
at hudson.FilePath.act(FilePath.java:784)
at hudson.FilePath.act(FilePath.java:770)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:742)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:684)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1195)
at
hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:576)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:465)
at hudson.model.Run.run(Run.java:1409)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:238)
Caused by: java.io.InterruptedIOException
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:775)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:752)
at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2099)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.InterruptedException
at
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:87)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:120)
at
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:787)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:768)
... 11 more
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: OPTIONS
/seesaw/projects/nrf4368/digital/nRF31512/atpg/trunk failed
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:294)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:271)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:533)
at
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1011)
at
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLatestRevision(DAVRepository.java:180)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.getRevisionNumber(SVNBasicClient.java:482)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:876)
at
org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534)
at
org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:901)
at
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:84)
... 17 more
Caused by: org.tmatesoft.svn.core.SVNCancelException: svn: No credential to
try. Authentication failed
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:37)
at
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.cancel(SVNErrorManager.java:32)
at
org.tmatesoft.svn.core.internal.wc.DefaultSVNAuthenticationManager.getNextAuthentication(DefaultSVNAuthenticationManager.java:219)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:584)
at
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:292)
... 28 more
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: No credential to try.
Authentic
[JIRA] (JENKINS-11369) Use ToolInstallation as replacement to p4 path specified in Jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159271#comment-159271 ] Mikko Tapaninen commented on JENKINS-11369: --- I'm working on this one and I'll create a pull request once ready. I would remove p4 executable path setting from the job level and have it as a tool installation. As a migration path I was thinking to add a tool installation for each different p4 executable path that are being used (case insensitive for Windows). No matter whether the job is enabled or not and whether it's tied on master or slave. Correct tool installation would then be picked for each job. There could be some extra unneeded tool installations but I think it's fair enough. Comments? > Use ToolInstallation as replacement to p4 path specified in Jobs > > > Key: JENKINS-11369 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11369 > Project: Jenkins > Issue Type: Improvement > Components: perforce >Reporter: Nicolas De Loof >Assignee: Rob Petti >Priority: Minor > > Got this issue : > job is configured with p4 path on build slave /usr/bin/p4. When tagging a > build, an error occurred because executing on master that don't have p4 > installed on same path. > perforce plugin should use the Jenkins concept of ToolInstallation + > NodeSpecific, so that it gets simpler to manage differences between nodes. -- 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-12831) Fresh install jenkins (1.451) broken
Lars Vonk created JENKINS-12831: --- Summary: Fresh install jenkins (1.451) broken Key: JENKINS-12831 URL: https://issues.jenkins-ci.org/browse/JENKINS-12831 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: tomcat6@toyota:/var/lib/tomcat6/shared/lib$ java -version java version "1.6.0_24" Java(TM) SE Runtime Environment (build 1.6.0_24-b07) Java HotSpot(TM) 64-Bit Server VM (build 19.1-b02, mixed mode) Ubuntu 10.04 LTS Tomcat 6 Reporter: Lars Vonk Priority: Blocker INFO: Prepared all plugins Feb 20, 2012 9:57:52 AM jenkins.InitReactorRunner$1 onAttained INFO: Started all plugins Feb 20, 2012 9:57:52 AM jenkins.InitReactorRunner$1 onAttained INFO: Augmented all extensions Feb 20, 2012 9:57:52 AM jenkins.InitReactorRunner$1 onAttained INFO: Loaded all jobs Failed to instantiate SLF4J LoggerFactory Reported exception: java.lang.NoClassDefFoundError: org/slf4j/spi/LoggerFactoryBinder at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632) at java.lang.ClassLoader.defineClass(ClassLoader.java:616) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141) at java.net.URLClassLoader.defineClass(URLClassLoader.java:283) at java.net.URLClassLoader.access$000(URLClassLoader.java:58) at java.net.URLClassLoader$1.run(URLClassLoader.java:197) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at java.lang.ClassLoader.loadClass(ClassLoader.java:296) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1471) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1329) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254) at org.apache.sshd.common.AbstractFactoryManager.(AbstractFactoryManager.java:37) at org.apache.sshd.SshServer.(SshServer.java:140) at org.apache.sshd.SshServer.setUpDefaultServer(SshServer.java:428) at org.jenkinsci.main.modules.sshd.SSHD.(SSHD.java:33) at org.jenkinsci.main.modules.sshd.SSHD$$FastClassByGuice$$c0b3a86e.newInstance() at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40) at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61) at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:108) at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87) at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:259) at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018) at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) at com.google.inject.Scopes$1$1.get(Scopes.java:59) at hudson.ExtensionFinder$AbstractGuiceFinder$2$1.get(ExtensionFinder.java:365) at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41) at com.google.inject.internal.SingleFieldInjector.inject(SingleFieldInjector.java:54) at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:118) at com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:117) at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:87) at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:259) at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46) at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018) at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40) at com.google.inject.Scopes$1$1.get(Scopes.java:59) at hudson.ExtensionFinder$AbstractGuiceFinder$2$1.get(ExtensionFinder.java:365) at com.google.inject.internal.Int
[JIRA] (JENKINS-12832) check XSLT is not good enough
Michael van der Westhuizen created JENKINS-12832: Summary: check XSLT is not good enough Key: JENKINS-12832 URL: https://issues.jenkins-ci.org/browse/JENKINS-12832 Project: Jenkins Issue Type: Improvement Components: xunit Affects Versions: current Reporter: Michael van der Westhuizen Assignee: gbois Attachments: check-to-junit-4.xsl The recently added check transform is really insufficient and misses a lot of cases. I've rewritten the XSLT and integrated it into our build using the custom tool support (which works extremely well!). I've attached the revised XSLT for possible integration into the tree. -- 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-12017) Seriously slow rendering/loading times for the job/foo/configure page
[ https://issues.jenkins-ci.org/browse/JENKINS-12017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159273#comment-159273 ] Fredrik Jonsson commented on JENKINS-12017: --- I don't know much about the internals of Jenkins but, can I do anything to help with this issue? Are there any logs to submit etc? > Seriously slow rendering/loading times for the job/foo/configure page > - > > Key: JENKINS-12017 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12017 > Project: Jenkins > Issue Type: Bug > Components: core >Reporter: R. Tyler Croy > > Opening a placeholder ticket for everybody from IRC to add numbers from their > own installations loading the configure page. > I think useful information to include would be: > * Wall clock time from when we start to load the page until when it completes > loading > * Number of installed plugins > * Anything else you think is useful -- 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
New build brakes already existing green build
Almost every weekend we get the same error in Jenkins (1.414) as follows: 1. Friday, a build as made, every test is ok and the build is green. You can download the artifacts and everything works fine 2. When returning on monday, we find that our last build that was green on friday has now turned red. A new build has been triggered during the weekend (by who knows what, no additional checkins were made). Instead of logging this as a new build Jenkins append it to the existing green build and in the end failing them both to red. See the screen shots, build #354 was green when it was finished this friday. Why doesn't build 355 has its own row in the build history? How can a build first finnish as green and then switch status some days later? In screen shot 2 you can see that both 354 and 355 are connected to the same upstream project build #79. The project build #79 was completly finished on friday, how can this new build 355 (that was started on sunday) be connected to a already finnished build? http://jenkins.361315.n4.nabble.com/file/n4403629/jenkins1.jpg http://jenkins.361315.n4.nabble.com/file/n4403629/jenkins2.jpg -- View this message in context: http://jenkins.361315.n4.nabble.com/New-build-brakes-already-existing-green-build-tp4403629p4403629.html Sent from the Jenkins issues mailing list archive at Nabble.com.
[JIRA] (JENKINS-12124) random NoClassDefFoundError: hudson/plugins/analysis/core/AbstractProjectAction - Not all jobs loaded
[
https://issues.jenkins-ci.org/browse/JENKINS-12124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159274#comment-159274
]
Richard Murray commented on JENKINS-12124:
--
I get the same issue on a fresh restart of Jetty. In addition to the
java.lang.NoClassDefFoundError:
hudson/plugins/analysis/core/AbstractProjectAction I also get a
NoClassDefFoundError on TaskProjectAction (see below)
We are running 1.451 and have just upgraded from Hudson (I'm using the same
jobs as setup on our old Hudson system, but running against the jenkins.war).
Reloading configuration from disk does NOT resolve the problem - I get the
error each time on the same 2 jobs.
java.lang.NoClassDefFoundError: hudson/plugins/tasks/TasksProjectAction
at
hudson.plugins.tasks.TasksPublisher.getProjectAction(TasksPublisher.java:163)
at
hudson.tasks.BuildStepCompatibilityLayer.getProjectActions(BuildStepCompatibilityLayer.java:73)
at hudson.model.Project.createTransientActions(Project.java:208)
at
hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:602)
at hudson.model.AbstractProject.onLoad(AbstractProject.java:272)
at hudson.model.Project.onLoad(Project.java:88)
at hudson.model.Items.load(Items.java:115)
at jenkins.model.Jenkins$14.run(Jenkins.java:2372)
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:812)
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(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
> random NoClassDefFoundError:
> hudson/plugins/analysis/core/AbstractProjectAction - Not all jobs loaded
> -
>
> Key: JENKINS-12124
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12124
> Project: Jenkins
> Issue Type: Bug
> Components: core
>Affects Versions: current
> Environment: Tomcat 6, JDK6, maven 3.0.3, SunOS, latest analysis*
> plugins, latest jenkins
>Reporter: Myron n/a
>Priority: Minor
>
> It sometimes happens, that upon fresh start of tomcat, not all Jobs/Projects
> are loaded.
> Once logging in and clicking on "reload configuration from disk" this works
> w/o any error and all the missing jobs are there.
> It seems to be random... and on another restart some other jobs are missing...
> Any clue?
> {quote}
> INFO: Started all plugins
> Dec 16, 2011 9:14:36 AM jenkins.InitReactorRunner$1 onAttained
> INFO: Augmented all extensions
> Dec 16, 2011 9:14:59 AM jenkins.InitReactorRunner$1 onTaskFailed
> SEVERE: Failed Loading job XX
> java.lang.NoClassDefFoundError:
> hudson/plugins/analysis/core/AbstractProjectAction
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClassCond(ClassLoader.java:632)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:616)
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
> at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
> at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
> at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at
> hudson.plugins.checkstyle.CheckStylePublisher.getProjectAction(CheckStylePublisher.java:128)
> at
> hudson.tasks.BuildStepCompatibilityLayer.getProjectActions(BuildStepCompatibilityLayer.java:73)
> at hudson.model.Project.createTransientActions(Project.java:208)
> at
> hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:602)
> at hudson.model.AbstractProject.onLoad(AbstractProject.java:272)
> at hudson.model.Project.onLoad(Project.java:88)
> at hudson.model.Items.load(Items.java:115)
> at jenkins.model.Jenkins$14.run(Jenkins.java:2364)
> 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.
[JIRA] (JENKINS-12833) Mantis plugin does not add change details.
Jan Goyvaerts created JENKINS-12833: --- Summary: Mantis plugin does not add change details. Key: JENKINS-12833 URL: https://issues.jenkins-ci.org/browse/JENKINS-12833 Project: Jenkins Issue Type: Bug Components: mantis Affects Versions: current Environment: Jenkins 1.446 Debian 6 (64) JDK 1.7.0 u2 (64) Reporter: Jan Goyvaerts Assignee: sogabe The plugin detects the matching SCM comments and updates the related tickets. Unfortunately the only thing it add is: Integrated in Project_11:103 ( See http://jenkins:8080/job/Project_11/103/ [^] ). For extensive, long running tickets, I've got tens of those notes added to the ticket. Unfortunately it doesn't say who has made the changes or what they implied. -- 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-12397) Avoid post-build depoy to Maven repository in release build
[ https://issues.jenkins-ci.org/browse/JENKINS-12397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159275#comment-159275 ] Jakub Štiller commented on JENKINS-12397: - We would like also have this issue solved. The m2release plugin has now support to export envrionment variable, that may be used. > Avoid post-build depoy to Maven repository in release build > --- > > Key: JENKINS-12397 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12397 > Project: Jenkins > Issue Type: Bug > Components: m2release >Reporter: Kai Dyrssen >Assignee: teilo > > The Jenkins post-build feature "deploy to Maven repository" in conjunction > with a release build with m2release plugin leads to corrupt snapshot version > in Maven snapshot repository: > After the release build succeeds the post-build deploy deploys the new > development version pom-file as old development version to our maven snapshot > repository. > If possible the m2release plugin should disable the post-build deploy feature > in its release build. -- 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
Need to checkout from Branch and build the project
Hi Team, I've a project which is having 10 modules. Till yesterday I was checking out from head of cvs repository. Now I'm informed to configure like, I need to checkout all the modules from a branch. How do I configure it in Jenkins? Please help me. Thanks in advance team :) -- View this message in context: http://jenkins.361315.n4.nabble.com/Need-to-checkout-from-Branch-and-build-the-project-tp4403934p4403934.html Sent from the Jenkins issues mailing list archive at Nabble.com.
[JIRA] (JENKINS-12815) Add an option to select Build status when no Test is found
[ https://issues.jenkins-ci.org/browse/JENKINS-12815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159276#comment-159276 ] Kohsuke Kawaguchi commented on JENKINS-12815: - What I'm really trying to avoid in Jenkins is to have two dozen checkboxes and text fields to cover every imaginable use case. Because Jenkins is a GUI tool primarily, every such added switch has a real cost. In my humble opinion, this feature falls on the wrong side of this trade-off. I suppose what we can do is to define an extension point that abstracts away the mapping from the test result into the result code. The config UI can be smart enough not to show this option when no implementation is provided (and we will not ship any in the junit plugin), and in this mode it can retain the current behavior. You can then develop an implementation of this extension point and achieve the semantics you prefer. > Add an option to select Build status when no Test is found > -- > > Key: JENKINS-12815 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12815 > Project: Jenkins > Issue Type: New Feature > Components: junit >Affects Versions: current > Environment: any >Reporter: Mickael Istria > > Currently, when no test report is found by JUnit report plugin (ie fileset is > empty), build fails. > In some cases, this behaviour is too constraining and implies stopping a > cascade of builds for example, and this is not always the mist convenient > behavior for a build stack. > This plugin should provide an option to select build status when fileset is > empty: > * FAILED (Red): current default behaviour > * UNSTABLE (Orange) > * STABLE (Blue/Green) > This is an issue we have to build JBoss Tools, which we had to workaround by > adding build steps, or adding dummy files to the fileset to avoid locking all > builds in case of test failing. -- 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-12457) 'Age' column on 'Test Result' tab may show incorrect value when a test suite divided into multiple junit files
[
https://issues.jenkins-ci.org/browse/JENKINS-12457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159277#comment-159277
]
dogfood commented on JENKINS-12457:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[jenkins_main_trunk #1534|http://ci.jenkins-ci.org/job/jenkins_main_trunk/1534/]
[FIXED JENKINS-12457] 'Age' column on 'Test Result' tab may show incorrect
value when a test suite divided into multiple junit files (Revision
05937f5343f844593ebd23ced2f62c4ca7308793)
Changelog for JENKINS-12457 / pull request #367 (Revision
fd0d1cbe085daac0c734d446c3009d6b58845ab3)
Result = SUCCESS
Christoph Kutzinski :
[05937f5343f844593ebd23ced2f62c4ca7308793|https://github.com/jenkinsci/jenkins/commit/05937f5343f844593ebd23ced2f62c4ca7308793]
Files :
* core/src/test/java/hudson/tasks/junit/TestResultTest.java
* core/src/test/resources/hudson/tasks/junit/eclipse-plugin-test-report.xml
* core/src/main/java/hudson/tasks/junit/SuiteResult.java
* core/src/main/java/hudson/tasks/junit/TestResult.java
* core/src/main/java/hudson/tasks/junit/CaseResult.java
Christoph Kutzinski :
[fd0d1cbe085daac0c734d446c3009d6b58845ab3|https://github.com/jenkinsci/jenkins/commit/fd0d1cbe085daac0c734d446c3009d6b58845ab3]
Files :
* changelog.html
> 'Age' column on 'Test Result' tab may show incorrect value when a test suite
> divided into multiple junit files
> --
>
> Key: JENKINS-12457
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12457
> Project: Jenkins
> Issue Type: Improvement
> Components: junit
>Affects Versions: current
>Reporter: Greg Temchenko
>Assignee: kutzi
>
> Somebody described the problem a year ago here:
> http://jenkins.361315.n4.nabble.com/Problem-with-Age-column-on-Test-Results-tab-td3172208.html
> {quote}
> I have a problem with 'Age' column on 'Test Results' tab. For couple of my
> tests, all the time this column has value equals '1', despite the fact that
> those tests start failing earlier than one build ago. When I switch to
> 'History' tab, in 'Test Result' column there is a 'Regression' value for all
> builds, and it should be 'Regression' value only for the first build and
> 'Failed' for next builds.
> {quote}
> For me this happens because I have many junit xmls that containing the same
> test suite name.
> In this case hudson.tasks.junit.CaseResult.getPreviousResult() gets the only
> last junit xml result and if it's not failed then the Age column won't be
> calculated 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-12832) check XSLT is not good enough
[ https://issues.jenkins-ci.org/browse/JENKINS-12832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159278#comment-159278 ] Michael van der Westhuizen commented on JENKINS-12832: -- Forgot to mention why we did this... The previous XSLT confuses failures and errors, counting failures as errors, and not counting errors at all. I noticed this quite quickly as 90% of my test cases were erroring due to segmentation violation and the plugin was reporting no problems. > check XSLT is not good enough > - > > Key: JENKINS-12832 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12832 > Project: Jenkins > Issue Type: Improvement > Components: xunit >Affects Versions: current >Reporter: Michael van der Westhuizen >Assignee: gbois > Labels: plugin > Attachments: check-to-junit-4.xsl > > > The recently added check transform is really insufficient and misses a lot of > cases. > I've rewritten the XSLT and integrated it into our build using the custom > tool support (which works extremely well!). > I've attached the revised XSLT for possible integration into the tree. -- 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-11938) Jenkins loses builds when restarted
[ https://issues.jenkins-ci.org/browse/JENKINS-11938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159279#comment-159279 ] edbras commented on JENKINS-11938: -- I am experiencing the same problem in Tomcat 7. My environment: Jenkins version 1.451 (had the same problems in 1.447) Tomcat 7. CentOS 6 64 bit. I am not using setEnv and EnvInject plugins. I notice that the build history is shown when performing a reload of the jenkins config manually (also in 1.451). I start getting these problems when changing from SVN to GIT, using the GIT plugin and using Maven projects instead of freestyle projects. The exception I encounter in the tomcat log (it's a bit different then the one above): --- Exception: --- hudson.util.IOException2: Unable to read /home/tomcat/.jenkins/jobs/Profile/modules/com.bv$bv-profile-common/builds/2012-02-13_19-16-19/build.xml at hudson.XmlFile.unmarshal(XmlFile.java:158) at hudson.model.Run.reload(Run.java:283) at hudson.model.Run.(Run.java:272) at hudson.model.AbstractBuild.(AbstractBuild.java:163) at hudson.maven.AbstractMavenBuild.(AbstractMavenBuild.java:54) at hudson.maven.MavenBuild.(MavenBuild.java:108) at sun.reflect.GeneratedConstructorAccessor74.newInstance(Unknown Source) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:513) at hudson.model.AbstractProject.loadBuild(AbstractProject.java:949) at hudson.model.AbstractProject$1.create(AbstractProject.java:256) at hudson.model.AbstractProject$1.create(AbstractProject.java:254) at hudson.model.RunMap.load(RunMap.java:221) at hudson.model.AbstractProject.onLoad(AbstractProject.java:254) at hudson.maven.MavenModule.onLoad(MavenModule.java:237) at hudson.model.Items.load(Items.java:115) at hudson.model.ItemGroupMixIn.loadChildren(ItemGroupMixIn.java:99) at hudson.maven.MavenModuleSet.onLoad(MavenModuleSet.java:673) at hudson.model.Items.load(Items.java:115) at jenkins.model.Jenkins$14.run(Jenkins.java:2372) 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:812) 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(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: com.thoughtworks.xstream.io.StreamException: : input contained no data at com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.java:80) at com.thoughtworks.xstream.io.xml.AbstractPullReader.readRealEvent(AbstractPullReader.java:154) at com.thoughtworks.xstream.io.xml.AbstractPullReader.readEvent(AbstractPullReader.java:147) at com.thoughtworks.xstream.io.xml.AbstractPullReader.move(AbstractPullReader.java:126) at com.thoughtworks.xstream.io.xml.AbstractPullReader.moveDown(AbstractPullReader.java:111) at com.thoughtworks.xstream.io.xml.XppReader.(XppReader.java:48) at com.thoughtworks.xstream.io.xml.XppDriver.createReader(XppDriver.java:44) at com.thoughtworks.xstream.io.xml.XppDriver.createReader(XppDriver.java:49) at hudson.XmlFile.unmarshal(XmlFile.java:156) ... 27 more Caused by: java.io.EOFException: input contained no data at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:3003) at org.xmlpull.mxp1.MXParser.more(MXParser.java:3046) at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) at com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.java:63) ... 35 more Feb 20, 2012 1:57:34 PM org.jvnet.hudson.plugins.DownStreamProjectActionFactory createFor INFO: org.jvnet.hudson.plugins.DownStreamProjectActionFactory@52ef152b adds DownStreamProjectAction for hudson.maven.MavenModule@633ddd88[Belastingvriendelijker/com.bv:bv-profile-common][Profile/com.bv:bv-profile-common][relativePath:bv-profile-common] > Jenkins loses builds when restarted > --- > > Key: JENKINS-11938 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11938 > Project: Jenkins > Issue Type: Bug > Components: other, versionnumber >Affects Versions: current > Environment: tomcat 7.0.22 > windows
[JIRA] (JENKINS-12834) multiple war from maven project
Nicolas De Loof created JENKINS-12834: - Summary: multiple war from maven project Key: JENKINS-12834 URL: https://issues.jenkins-ci.org/browse/JENKINS-12834 Project: Jenkins Issue Type: Bug Components: cloudbees-deployer Reporter: Nicolas De Loof Assignee: olamy When project generates multiple war artifacts, plugin takes the first one found in maven artifacts but don't even warn the user for ambiguous configuration. -- 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-12459) Does not trigger a build with a branch merge
[ https://issues.jenkins-ci.org/browse/JENKINS-12459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ringo De Smet resolved JENKINS-12459. - Resolution: Duplicate JENKINS-7594 > Does not trigger a build with a branch merge > > > Key: JENKINS-12459 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12459 > Project: Jenkins > Issue Type: Bug > Components: mercurial > Environment: Windows 7, Mercurial >Reporter: samaursa >Assignee: Kohsuke Kawaguchi > Labels: plugin > > This issue has been raised earlier, but the 'resolution' to that issue was > not good, or at least, should have been optional. > I am not sure how people are tackling this issue in general but if I have a > 'dev' and 'default' branches, the branches mostly accept merges as > programmers work in different branches then merge them into dev. When the dev > compiles and is tested, it is merged into default. We absolutely need the > dev/default to start building as soon as there is a merge. > This was disabled when someone raised the issue that there were un-necessary > builds. I'd rather have un-necessary builds telling me 'Successful!' than no > builds at all. > At the very least, there should be a compromise. The following command is > executed every-time the plugin polls the repository: > $ hg log --style \tmp4601530738732108532style --branch dev > --no-merges --prune > I would like the option to remove `--no-merges` from it. Please expose this > so that we can optionally change it. Currently, this is becoming a big issue > so much so that we may have to switch from Jenkins. > I would really appreciate resolution of this issue. Thank you. -- 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-12017) Seriously slow rendering/loading times for the job/foo/configure page
[ https://issues.jenkins-ci.org/browse/JENKINS-12017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159281#comment-159281 ] Fredrik Jonsson commented on JENKINS-12017: --- Solved this issue by disabling almost all plug-ins, especially removing the Artifactory plugin helped. See JENKINS-10069 > Seriously slow rendering/loading times for the job/foo/configure page > - > > Key: JENKINS-12017 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12017 > Project: Jenkins > Issue Type: Bug > Components: core >Reporter: R. Tyler Croy > > Opening a placeholder ticket for everybody from IRC to add numbers from their > own installations loading the configure page. > I think useful information to include would be: > * Wall clock time from when we start to load the page until when it completes > loading > * Number of installed plugins > * Anything else you think is useful -- 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-12810) JUnit test results are getting wrongly attached to all the test cases
[ https://issues.jenkins-ci.org/browse/JENKINS-12810?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159282#comment-159282 ] Vignesh Senapathy commented on JENKINS-12810: - Hi Bruno, Wanted to know do u want the Testlink project or the selenium project. Please let me know about this. > JUnit test results are getting wrongly attached to all the test cases > - > > Key: JENKINS-12810 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12810 > Project: Jenkins > Issue Type: Bug > Components: testlink >Affects Versions: current >Reporter: Vignesh Senapathy >Assignee: Bruno P. Kinoshita > Fix For: current > > Attachments: last_tc.png, tc1.png, tc2.png > > > Hi, > I am using the Testlink Jenkins plugin and when i run my jobs in Jenkins the > Junit Test results are getting generated. This in turn calls the Testlink xml > rpc and attaches the results to the test case, but the test results are > attached wrongly. The 1st test case has 6 results, the next has 5 and so on > and the last one has 1 test result attached to it. I dont know if it is bug > which is causing this. Please let me know what seems to be the problems. Also > the execution flags are correctly rendered in this. which ever test case > fails is marked as failed and which passed is marked as passed. > Also I have one custom field which maps to the test suite name and test > classname. -- 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-11665) email-ext: cannot save "Default Recipients"
[ https://issues.jenkins-ci.org/browse/JENKINS-11665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159283#comment-159283 ] Tym Pollack commented on JENKINS-11665: --- Any word on if this issue will be fixed in an upcoming release? > email-ext: cannot save "Default Recipients" > --- > > Key: JENKINS-11665 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11665 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: linux, jenkins 1.438, email-ext 2.16 >Reporter: Bruno Marti >Assignee: Slide-O-Mix > Labels: email-ext, jenkins > Attachments: after-saving.jpg, before-saving.jpg > > > "Default Recipients" input field remains empty after saving. > (Jenkins>Manage Jenkins>Configure System) -- 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-9540) Copy Artifacts Plugin Throws "IOException: Pipe is already closed"
[ https://issues.jenkins-ci.org/browse/JENKINS-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159284#comment-159284 ] Ringo De Smet commented on JENKINS-9540: I bump into this issue with Jenkins 1.445 and CopyArtifact 1.18. In my case, it is not related to a lack of diskspace on the slave. There are multiple gigabytes of free space. The workaround was to remove the work space (tnx Dirk) and trigger a clean build. > Copy Artifacts Plugin Throws "IOException: Pipe is already closed" > -- > > Key: JENKINS-9540 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9540 > Project: Jenkins > Issue Type: Bug > Components: copyartifact, core >Affects Versions: current > Environment: Windows XP SP3, Sun JRE 1.6.25 >Reporter: Dirk Weinhardt >Assignee: Kohsuke Kawaguchi > Fix For: current > > > Since updating to Jenkins 1.409 and Copy Artifacts Plugin 1.16, build jobs > fail with an IOException when copying build artifacts from the Master to the > current Slave. > ERROR: Failed to copy artifacts from ABC Build with filter: > _tests\UnitTests\bin\Debug\** > java.io.IOException: Pipe is already closed > at hudson.remoting.PipeWindow.checkDeath(PipeWindow.java:83) > at hudson.remoting.PipeWindow$Real.get(PipeWindow.java:165) > at hudson.remoting.ProxyOutputStream._write(ProxyOutputStream.java:118) > at hudson.remoting.ProxyOutputStream.write(ProxyOutputStream.java:103) > at java.io.BufferedOutputStream.flushBuffer(Unknown Source) > at java.io.BufferedOutputStream.write(Unknown Source) > at java.util.zip.DeflaterOutputStream.deflate(Unknown Source) > at java.util.zip.DeflaterOutputStream.write(Unknown Source) > at java.util.zip.GZIPOutputStream.write(Unknown Source) > at java.io.BufferedOutputStream.write(Unknown Source) > at org.apache.tools.tar.TarBuffer.writeBlock(TarBuffer.java:410) > at org.apache.tools.tar.TarBuffer.writeRecord(TarBuffer.java:351) > at > hudson.org.apache.tools.tar.TarOutputStream.writeEOFRecord(TarOutputStream.java:356) > at > hudson.org.apache.tools.tar.TarOutputStream.finish(TarOutputStream.java:137) > at > hudson.org.apache.tools.tar.TarOutputStream.close(TarOutputStream.java:149) > at hudson.util.io.TarArchiver.close(TarArchiver.java:119) > at hudson.FilePath.writeToTar(FilePath.java:1596) > at hudson.FilePath.copyRecursiveTo(FilePath.java:1521) > at hudson.FilePath.copyRecursiveTo(FilePath.java:1450) > at > hudson.plugins.copyartifact.FilePathCopyMethod.copyAll(FilePathCopyMethod.java:51) > at > hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:225) > at > hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:199) > at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) > at > hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:649) > at hudson.model.Build$RunnerImpl.build(Build.java:177) > at hudson.model.Build$RunnerImpl.doRun(Build.java:139) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:423) > at hudson.model.Run.run(Run.java:1362) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:145) > Caused by: java.io.IOException: Pipe is already closed > at > hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:147) > at > hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:131) > at > hudson.remoting.ProxyOutputStream$Chunk$1.run(ProxyOutputStream.java:185) > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown > Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > Caused by: hudson.remoting.FastPipedInputStream$ClosedBy: The pipe was closed > at... > at > hudson.remoting.FastPipedInputStream.close(FastPipedInputStream.java:112) > at hudson.FilePath$32.invoke(FilePath.java:1517) > at hudson.FilePath$32.invoke(FilePath.java:1511) > at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1956) > at hudson.remoting.UserRequest.perform(UserRequest.java:118) > at hudson.remoting.UserRequest.perform(UserRequest.java:48) > at hudson.remoting.Request$2.run(Request.java:270) > at java.util.concurrent.Exe
[JIRA] (JENKINS-12821) android.device
[
https://issues.jenkins-ci.org/browse/JENKINS-12821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159285#comment-159285
]
Richard Mortimer commented on JENKINS-12821:
So I decided to investigate this a bit more and took the radical step of
setting -Dandroid.device=emulator in my Jenkins maven commandline. The good(!)
news is I get the same error here plus I've got a build environment setup for
android-maven-plugin so I should be able to dig a little deeper over the next
couple of days.
For the record I get the following stack trace with plugin a-m-p 3.1.1 (get
similar with 3.0.0 too).
{code}
[INFO] Waiting for initial device list from the Android Debug Bridge
[INFO] Found 1 devices connected with the Android Debug Bridge
[INFO] android.device parameter set to emulator
...snip...
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 1:01.522s
[INFO] Finished at: Mon Feb 20 15:20:59 GMT 2012
[INFO] Final Memory: 15M/495M
[INFO]
mavenExecutionResult exceptions not empty
message : Failed to execute goal
com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.1.1:internal-pre-integration-test
(default-internal-pre-integration-test) on project mobilemax-it: No device
found for android.device=emulator
cause : No device found for android.device=emulator
Stack trace :
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal
com.jayway.maven.plugins.android.generation2:android-maven-plugin:3.1.1:internal-pre-integration-test
(default-internal-pre-integration-test) on project mobilemax-it: No device
found for android.device=emulator
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at
org.jvnet.hudson.maven3.launcher.Maven3Launcher.main(Maven3Launcher.java:79)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchStandard(Launcher.java:329)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:239)
at org.jvnet.hudson.maven3.agent.Maven3Main.launch(Maven3Main.java:158)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:104)
at hudson.maven.Maven3Builder.call(Maven3Builder.java:70)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.maven.plugin.MojoExecutionException: No device found for
android.device=emulator
at
com.jayway.maven.plugins.android.AbstractAndroidMojo.doWithDevices(AbstractAndroidMojo.java:602)
at
com.jayway.maven.plugins.android.AbstractAndroidMojo.undeployApk(AbstractAndroidMojo.java:644)
at
com.jayway.maven.plugins.android.AbstractAndroidMojo.undeployApk(AbstractAndroidMojo.java:628)
at
com.jayway.maven.plugins.android.AbstractAndroidMojo.deployDependencies(AbstractAndroidMojo.java:538)
at
com.jayway.maven.plugins.android.phase11preintegrationtest.InternalPreIntegrationTestMojo.execute(InternalPreIntegrationTestMojo.java:36)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecyc
[JIRA] (JENKINS-12821) android.device
[ https://issues.jenkins-ci.org/browse/JENKINS-12821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Richard Mortimer reassigned JENKINS-12821: -- Assignee: Richard Mortimer (was: Christopher Orr) > android.device > --- > > Key: JENKINS-12821 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12821 > Project: Jenkins > Issue Type: Bug > Components: android-emulator >Affects Versions: current >Reporter: Sebastian Schefczyk >Assignee: Richard Mortimer >Priority: Minor > > The following configuration of the android-maven-plugin will not find the > running emulator on Jenkins. > Commenting this line will find the emulator. > On my local machine this is working fine, but not in Jenkins. > Both machines use maven 3.0.4 on Linux/Ubuntu. > com.jayway.maven.plugins.android.generation2 > android-maven-plugin > >... > emulator >... > > > This configuration is useful on the local machine, if you are developing > while charging your phone via USB. > Best regards, that's a really nice plugin! > Sebl29 -- 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-11665) email-ext: cannot save "Default Recipients"
[ https://issues.jenkins-ci.org/browse/JENKINS-11665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159286#comment-159286 ] Slide-O-Mix commented on JENKINS-11665: --- That is the goal, I have a version I am testing currently. > email-ext: cannot save "Default Recipients" > --- > > Key: JENKINS-11665 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11665 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: linux, jenkins 1.438, email-ext 2.16 >Reporter: Bruno Marti >Assignee: Slide-O-Mix > Labels: email-ext, jenkins > Attachments: after-saving.jpg, before-saving.jpg > > > "Default Recipients" input field remains empty after saving. > (Jenkins>Manage Jenkins>Configure System) -- 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-11665) email-ext: cannot save "Default Recipients"
[ https://issues.jenkins-ci.org/browse/JENKINS-11665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159287#comment-159287 ] Tym Pollack commented on JENKINS-11665: --- Appreciate the update. Just took over someone else's installation and am new to jenkins administration. Reverted back to 2.15 for now since that seems to work (they were only on 2.16 anyway). > email-ext: cannot save "Default Recipients" > --- > > Key: JENKINS-11665 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11665 > Project: Jenkins > Issue Type: Bug > Components: email-ext >Affects Versions: current > Environment: linux, jenkins 1.438, email-ext 2.16 >Reporter: Bruno Marti >Assignee: Slide-O-Mix > Labels: email-ext, jenkins > Attachments: after-saving.jpg, before-saving.jpg > > > "Default Recipients" input field remains empty after saving. > (Jenkins>Manage Jenkins>Configure System) -- 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-12835) NullPointerException in CloneWorkspacePublisher.java:211 after upgrading to 0.4
Ed Randall created JENKINS-12835: Summary: NullPointerException in CloneWorkspacePublisher.java:211 after upgrading to 0.4 Key: JENKINS-12835 URL: https://issues.jenkins-ci.org/browse/JENKINS-12835 Project: Jenkins Issue Type: Bug Components: clone-workspace-scm Affects Versions: current Environment: Jenkins 1.424.2 Jenkins Clone Workspace SCM Plug-in 0.4 Reporter: Ed Randall After upgrading clone-workspace-plugin from 0.3 to 0.4 this happens at the end of the job when it is supposed to start archiving:- BUILD SUCCESSFUL Total time: 5 minutes 1 second Archiving workspace ERROR: Publisher hudson.plugins.cloneworkspace.CloneWorkspacePublisher aborted due to exception java.lang.NullPointerException at hudson.plugins.cloneworkspace.CloneWorkspacePublisher.snapshot(CloneWorkspacePublisher.java:211) at hudson.plugins.cloneworkspace.CloneWorkspacePublisher.perform(CloneWorkspacePublisher.java:170) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:682) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:657) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:635) at hudson.model.Build$RunnerImpl.post2(Build.java:161) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:604) at hudson.model.Run.run(Run.java:1400) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:175) Email was triggered for: Failure -- 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-12397) Avoid post-build depoy to Maven repository in release build
[ https://issues.jenkins-ci.org/browse/JENKINS-12397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159289#comment-159289 ] SCM/JIRA link daemon commented on JENKINS-12397: Code changed in jenkins User: Jakub Štiller Path: maven-plugin/src/main/java/hudson/maven/RedeployPublisher.java maven-plugin/src/main/resources/hudson/maven/RedeployPublisher/config.jelly maven-plugin/src/main/resources/hudson/maven/RedeployPublisher/help-releaseEnvVar.html http://jenkins-ci.org/commit/jenkins/51a53ab491bc4efe1309655f0ba7df2050246409 Log: JENKINS-12397: Skip deploying of artifacts when release build is running. Monitor environment variable defined by user. If the variable is set to "true" the deployment is skipped. The M2 Release plugin expose this kind of variables. > Avoid post-build depoy to Maven repository in release build > --- > > Key: JENKINS-12397 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12397 > Project: Jenkins > Issue Type: Bug > Components: m2release >Reporter: Kai Dyrssen >Assignee: teilo > > The Jenkins post-build feature "deploy to Maven repository" in conjunction > with a release build with m2release plugin leads to corrupt snapshot version > in Maven snapshot repository: > After the release build succeeds the post-build deploy deploys the new > development version pom-file as old development version to our maven snapshot > repository. > If possible the m2release plugin should disable the post-build deploy feature > in its release build. -- 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-12397) Avoid post-build depoy to Maven repository in release build
[ https://issues.jenkins-ci.org/browse/JENKINS-12397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159288#comment-159288 ] Jakub Štiller commented on JENKINS-12397: - Pull request: https://github.com/jenkinsci/jenkins/pull/380 > Avoid post-build depoy to Maven repository in release build > --- > > Key: JENKINS-12397 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12397 > Project: Jenkins > Issue Type: Bug > Components: m2release >Reporter: Kai Dyrssen >Assignee: teilo > > The Jenkins post-build feature "deploy to Maven repository" in conjunction > with a release build with m2release plugin leads to corrupt snapshot version > in Maven snapshot repository: > After the release build succeeds the post-build deploy deploys the new > development version pom-file as old development version to our maven snapshot > repository. > If possible the m2release plugin should disable the post-build deploy feature > in its release build. -- 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-12397) Avoid post-build depoy to Maven repository in release build
[ https://issues.jenkins-ci.org/browse/JENKINS-12397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159290#comment-159290 ] SCM/JIRA link daemon commented on JENKINS-12397: Code changed in jenkins User: Olivier Lamy Path: maven-plugin/src/main/java/hudson/maven/RedeployPublisher.java maven-plugin/src/main/resources/hudson/maven/RedeployPublisher/config.jelly maven-plugin/src/main/resources/hudson/maven/RedeployPublisher/help-releaseEnvVar.html http://jenkins-ci.org/commit/jenkins/30c229f2245ff850909b318d0a18e348d32102ab Log: Merge pull request #380 from Delorien84/JENKINS-12397 JENKINS-12397: Skip deploying of artifacts when release build is running... good idea Thanks ! Compare: https://github.com/jenkinsci/jenkins/compare/4866198...30c229f > Avoid post-build depoy to Maven repository in release build > --- > > Key: JENKINS-12397 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12397 > Project: Jenkins > Issue Type: Bug > Components: m2release >Reporter: Kai Dyrssen >Assignee: teilo > > The Jenkins post-build feature "deploy to Maven repository" in conjunction > with a release build with m2release plugin leads to corrupt snapshot version > in Maven snapshot repository: > After the release build succeeds the post-build deploy deploys the new > development version pom-file as old development version to our maven snapshot > repository. > If possible the m2release plugin should disable the post-build deploy feature > in its release build. -- 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-12397) Avoid post-build depoy to Maven repository in release build
[ https://issues.jenkins-ci.org/browse/JENKINS-12397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159291#comment-159291 ] SCM/JIRA link daemon commented on JENKINS-12397: Code changed in jenkins User: Olivier Lamy Path: changelog.html http://jenkins-ci.org/commit/jenkins/8cce8dd0ba4be23e39f32d7267564275895d8a79 Log: changelog entry for JENKINS-12397 > Avoid post-build depoy to Maven repository in release build > --- > > Key: JENKINS-12397 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12397 > Project: Jenkins > Issue Type: Bug > Components: m2release >Reporter: Kai Dyrssen >Assignee: teilo > > The Jenkins post-build feature "deploy to Maven repository" in conjunction > with a release build with m2release plugin leads to corrupt snapshot version > in Maven snapshot repository: > After the release build succeeds the post-build deploy deploys the new > development version pom-file as old development version to our maven snapshot > repository. > If possible the m2release plugin should disable the post-build deploy feature > in its release build. -- 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-12836) Gerrit-Trigger spams log with "class ....Branch is missing its descriptor in ... ....GerritProject.getBranches()"
Thomas Broyer created JENKINS-12836:
---
Summary: Gerrit-Trigger spams log with "class Branch is
missing its descriptor in ... GerritProject.getBranches()"
Key: JENKINS-12836
URL: https://issues.jenkins-ci.org/browse/JENKINS-12836
Project: Jenkins
Issue Type: Bug
Components: gerrit-trigger
Environment: Jenkins 1.451 with Gerrit-Trigger 2.3.1, then upgraded to
Gerrit-Trigger 2.4.0.
Reporter: Thomas Broyer
Assignee: rsandell
Priority: Minor
Attachments: jenkins.log
Log is full of:
{noformat}
Caused by: java.lang.AssertionError: class
com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.data.Branch is
missing its descriptor in public java.util.List
com.sonyericsson.hudson.plugins.gerrit.trigger.hudsontrigger.data.GerritProject.getBranches().
See https://wiki.jenkins-ci.org/display/JENKINS/My+class+is+missing+descriptor
at
hudson.model.Descriptor$PropertyType.getItemTypeDescriptorOrDie(Descriptor.java:194)
... 198 more
{noformat}
See attachment for full log.
--
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-12822) Java import of deprecated type not recognized as warning
[ https://issues.jenkins-ci.org/browse/JENKINS-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ulli Hafner updated JENKINS-12822: -- Priority: Minor (was: Major) > Java import of deprecated type not recognized as warning > > > Key: JENKINS-12822 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12822 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: Alexander Weickmann >Assignee: Ulli Hafner >Priority: Minor > > # Mark a Java type to be deprecated > # Import that Java type into another Java type > # The import is not recognized as warning, even though the warning was > written to the console by the build -- 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-11369) Use ToolInstallation as replacement to p4 path specified in Jobs
[ https://issues.jenkins-ci.org/browse/JENKINS-11369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159292#comment-159292 ] Rob Petti commented on JENKINS-11369: - Sounds good to me! You may want to look into a function called "readResolve" for performing the upgrade between versions. The perforce plugin currently doesn't implement it, but the GitSCM plugin has a good example of how this can be used. > Use ToolInstallation as replacement to p4 path specified in Jobs > > > Key: JENKINS-11369 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11369 > Project: Jenkins > Issue Type: Improvement > Components: perforce >Reporter: Nicolas De Loof >Assignee: Rob Petti >Priority: Minor > > Got this issue : > job is configured with p4 path on build slave /usr/bin/p4. When tagging a > build, an error occurred because executing on master that don't have p4 > installed on same path. > perforce plugin should use the Jenkins concept of ToolInstallation + > NodeSpecific, so that it gets simpler to manage differences between nodes. -- 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-12801) When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
[
https://issues.jenkins-ci.org/browse/JENKINS-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159294#comment-159294
]
SCM/JIRA link daemon commented on JENKINS-12801:
Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/analysis/util/model/AbstractAnnotation.java
http://jenkins-ci.org/commit/analysis-core-plugin/5123f0efb7b7b2d9bb26c7970c4e2bd83791746a
Log:
[JENKINS-12822] [JENKINS-12801] Added support for columns in warnings.
> When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
> -
>
> Key: JENKINS-12801
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12801
> Project: Jenkins
> Issue Type: Bug
> Components: pmd
>Reporter: Cees Bos
>Assignee: Ulli Hafner
>Priority: Minor
>
> We have this line of code:
> {code:java}
> public boolean hasNext()
> {
> return cursor == EMPTY && entity != EMPTY;
> }
> {code}
> PMD xml report has these violations reported:
> {code:xml}
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> {code}
> Is reports 2 issues on the same line. Other begincolumn and other endcolumn.
> In the UI it is only reported once.
> And the total number of violations does not match with the actual number of
> violations.
--
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-12822) Java import of deprecated type not recognized as warning
[ https://issues.jenkins-ci.org/browse/JENKINS-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159293#comment-159293 ] SCM/JIRA link daemon commented on JENKINS-12822: Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/analysis/util/model/AbstractAnnotation.java http://jenkins-ci.org/commit/analysis-core-plugin/5123f0efb7b7b2d9bb26c7970c4e2bd83791746a Log: [JENKINS-12822] [JENKINS-12801] Added support for columns in warnings. > Java import of deprecated type not recognized as warning > > > Key: JENKINS-12822 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12822 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: Alexander Weickmann >Assignee: Ulli Hafner >Priority: Minor > > # Mark a Java type to be deprecated > # Import that Java type into another Java type > # The import is not recognized as warning, even though the warning was > written to the console by the build -- 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-12822) Java import of deprecated type not recognized as warning
[ https://issues.jenkins-ci.org/browse/JENKINS-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159296#comment-159296 ] SCM/JIRA link daemon commented on JENKINS-12822: Code changed in jenkins User: Ulli Hafner Path: pom.xml src/main/java/hudson/plugins/warnings/parser/EclipseParser.java src/test/java/hudson/plugins/warnings/parser/DynamicDocumentParserTest.java src/test/java/hudson/plugins/warnings/parser/EclipseParserTest.java src/test/resources/hudson/plugins/warnings/parser/issue12822.txt http://jenkins-ci.org/commit/warnings-plugin/82b0b4c9e25b07b159e9db58f410d6844e96e3ae Log: [FIXED JENKINS-12822] Added support for columns in Eclipse warnings. > Java import of deprecated type not recognized as warning > > > Key: JENKINS-12822 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12822 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: Alexander Weickmann >Assignee: Ulli Hafner >Priority: Minor > > # Mark a Java type to be deprecated > # Import that Java type into another Java type > # The import is not recognized as warning, even though the warning was > written to the console by the build -- 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-12801) When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
[
https://issues.jenkins-ci.org/browse/JENKINS-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
SCM/JIRA link daemon resolved JENKINS-12801.
Resolution: Fixed
> When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
> -
>
> Key: JENKINS-12801
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12801
> Project: Jenkins
> Issue Type: Bug
> Components: pmd
>Reporter: Cees Bos
>Assignee: Ulli Hafner
>Priority: Minor
>
> We have this line of code:
> {code:java}
> public boolean hasNext()
> {
> return cursor == EMPTY && entity != EMPTY;
> }
> {code}
> PMD xml report has these violations reported:
> {code:xml}
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> {code}
> Is reports 2 issues on the same line. Other begincolumn and other endcolumn.
> In the UI it is only reported once.
> And the total number of violations does not match with the actual number of
> violations.
--
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-12801) When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
[
https://issues.jenkins-ci.org/browse/JENKINS-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159295#comment-159295
]
SCM/JIRA link daemon commented on JENKINS-12801:
Code changed in jenkins
User: Ulli Hafner
Path:
.classpath
pom.xml
src/main/java/hudson/plugins/pmd/parser/PmdParser.java
src/main/java/hudson/plugins/pmd/parser/Violation.java
src/test/java/hudson/plugins/pmd/parser/PmdParserTest.java
src/test/resources/hudson/plugins/pmd/parser/issue12801.xml
http://jenkins-ci.org/commit/pmd-plugin/c311e09311092846081b0b37c6b175266059f660
Log:
[FIXED JENKINS-12801] Added column support for PMD warnings.
> When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
> -
>
> Key: JENKINS-12801
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12801
> Project: Jenkins
> Issue Type: Bug
> Components: pmd
>Reporter: Cees Bos
>Assignee: Ulli Hafner
>Priority: Minor
>
> We have this line of code:
> {code:java}
> public boolean hasNext()
> {
> return cursor == EMPTY && entity != EMPTY;
> }
> {code}
> PMD xml report has these violations reported:
> {code:xml}
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> {code}
> Is reports 2 issues on the same line. Other begincolumn and other endcolumn.
> In the UI it is only reported once.
> And the total number of violations does not match with the actual number of
> violations.
--
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-12822) Java import of deprecated type not recognized as warning
[ https://issues.jenkins-ci.org/browse/JENKINS-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12822. Resolution: Fixed > Java import of deprecated type not recognized as warning > > > Key: JENKINS-12822 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12822 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: Alexander Weickmann >Assignee: Ulli Hafner >Priority: Minor > > # Mark a Java type to be deprecated > # Import that Java type into another Java type > # The import is not recognized as warning, even though the warning was > written to the console by the build -- 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-12801) When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
[
https://issues.jenkins-ci.org/browse/JENKINS-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159300#comment-159300
]
dogfood commented on JENKINS-12801:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_pmd
#311|http://ci.jenkins-ci.org/job/plugins_pmd/311/]
Result = SUCCESS
> When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
> -
>
> Key: JENKINS-12801
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12801
> Project: Jenkins
> Issue Type: Bug
> Components: pmd
>Reporter: Cees Bos
>Assignee: Ulli Hafner
>Priority: Minor
>
> We have this line of code:
> {code:java}
> public boolean hasNext()
> {
> return cursor == EMPTY && entity != EMPTY;
> }
> {code}
> PMD xml report has these violations reported:
> {code:xml}
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> {code}
> Is reports 2 issues on the same line. Other begincolumn and other endcolumn.
> In the UI it is only reported once.
> And the total number of violations does not match with the actual number of
> violations.
--
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-12801) When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
[
https://issues.jenkins-ci.org/browse/JENKINS-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159298#comment-159298
]
dogfood commented on JENKINS-12801:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[plugins_analysis-core
#10411|http://ci.jenkins-ci.org/job/plugins_analysis-core/10411/]
[JENKINS-12822] [JENKINS-12801] Added support for columns in warnings.
(Revision 5123f0efb7b7b2d9bb26c7970c4e2bd83791746a)
Result = SUCCESS
Ulli Hafner :
Files :
* src/main/java/hudson/plugins/analysis/util/model/AbstractAnnotation.java
> When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
> -
>
> Key: JENKINS-12801
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12801
> Project: Jenkins
> Issue Type: Bug
> Components: pmd
>Reporter: Cees Bos
>Assignee: Ulli Hafner
>Priority: Minor
>
> We have this line of code:
> {code:java}
> public boolean hasNext()
> {
> return cursor == EMPTY && entity != EMPTY;
> }
> {code}
> PMD xml report has these violations reported:
> {code:xml}
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> {code}
> Is reports 2 issues on the same line. Other begincolumn and other endcolumn.
> In the UI it is only reported once.
> And the total number of violations does not match with the actual number of
> violations.
--
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-12822) Java import of deprecated type not recognized as warning
[ https://issues.jenkins-ci.org/browse/JENKINS-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159297#comment-159297 ] dogfood commented on JENKINS-12822: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_analysis-core #10411|http://ci.jenkins-ci.org/job/plugins_analysis-core/10411/] [JENKINS-12822] [JENKINS-12801] Added support for columns in warnings. (Revision 5123f0efb7b7b2d9bb26c7970c4e2bd83791746a) Result = SUCCESS Ulli Hafner : Files : * src/main/java/hudson/plugins/analysis/util/model/AbstractAnnotation.java > Java import of deprecated type not recognized as warning > > > Key: JENKINS-12822 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12822 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: Alexander Weickmann >Assignee: Ulli Hafner >Priority: Minor > > # Mark a Java type to be deprecated > # Import that Java type into another Java type > # The import is not recognized as warning, even though the warning was > written to the console by the build -- 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-12822) Java import of deprecated type not recognized as warning
[ https://issues.jenkins-ci.org/browse/JENKINS-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159299#comment-159299 ] dogfood commented on JENKINS-12822: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_warnings #354|http://ci.jenkins-ci.org/job/plugins_warnings/354/] Result = SUCCESS > Java import of deprecated type not recognized as warning > > > Key: JENKINS-12822 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12822 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: Alexander Weickmann >Assignee: Ulli Hafner >Priority: Minor > > # Mark a Java type to be deprecated > # Import that Java type into another Java type > # The import is not recognized as warning, even though the warning was > written to the console by the build -- 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-8740) Log file filling up disk with connection reset and broken pipe errors
[
https://issues.jenkins-ci.org/browse/JENKINS-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159301#comment-159301
]
Nick Sieger commented on JENKINS-8740:
--
We're running 1.449 at this time and haven't seen this issue for a while, so I
think it's safe to call it closed.
> Log file filling up disk with connection reset and broken pipe errors
> -
>
> Key: JENKINS-8740
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8740
> Project: Jenkins
> Issue Type: Bug
> Components: master-slave
>Affects Versions: current
> Environment: http://ci.jruby.org/
> Jenkins 1.396
> Linux ip-10-251-193-235 2.6.18-xenU-ec2-v1.0 #2 SMP Tue Feb 19 10:51:53 EST
> 2008 i686 Dual-Core AMD Opteron(tm) Processor 2218 HE AuthenticAMD GNU/Linux
> Java 1.6.0_11-b03
>Reporter: Nick Sieger
>Priority: Critical
> Attachments: ci.jruby.org-jenkins-node.log,
> ci.jruby.org-jenkins-node2.log
>
>
> I have ci.jruby.org running a recent Jenkins build with a master and 3 remote
> nodes started by JNLP. After a while the nodes get disconnected, and the
> master's log starts filling up with these stack traces:
> {noformat}
> Feb 7, 2011 12:22:00 PM hudson.remoting.ProxyOutputStream$Chunk$1 run
> WARNING: Failed to write to stream
> winstone.ClientSocketException: Failed to write to client
> at winstone.ClientOutputStream.write(ClientOutputStream.java:41)
> at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:181)
> at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:119)
> at winstone.WinstoneOutputStream.write(WinstoneOutputStream.java:112)
> at java.io.OutputStream.write(OutputStream.java:58)
> at
> hudson.remoting.ProxyOutputStream$Chunk$1.run(ProxyOutputStream.java:185)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.net.SocketException: Connection reset
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:96)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at winstone.ClientOutputStream.write(ClientOutputStream.java:39)
> ... 11 more
> Feb 7, 2011 12:22:00 PM hudson.remoting.ProxyOutputStream$Chunk$1 run
> WARNING: Failed to write to stream
> winstone.ClientSocketException: Failed to write to client
> at winstone.ClientOutputStream.write(ClientOutputStream.java:41)
> at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:181)
> at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:119)
> at winstone.WinstoneOutputStream.write(WinstoneOutputStream.java:112)
> at java.io.OutputStream.write(OutputStream.java:58)
> at
> hudson.remoting.ProxyOutputStream$Chunk$1.run(ProxyOutputStream.java:185)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.net.SocketException: Broken pipe
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at winstone.ClientOutputStream.write(ClientOutputStream.java:39)
> ... 11 more
> {noformat}
> I can provide a login to the Jenkins instance on ci.jruby.org if desired.
--
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-8740) Log file filling up disk with connection reset and broken pipe errors
[
https://issues.jenkins-ci.org/browse/JENKINS-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Sieger resolved JENKINS-8740.
--
Resolution: Cannot Reproduce
> Log file filling up disk with connection reset and broken pipe errors
> -
>
> Key: JENKINS-8740
> URL: https://issues.jenkins-ci.org/browse/JENKINS-8740
> Project: Jenkins
> Issue Type: Bug
> Components: master-slave
>Affects Versions: current
> Environment: http://ci.jruby.org/
> Jenkins 1.396
> Linux ip-10-251-193-235 2.6.18-xenU-ec2-v1.0 #2 SMP Tue Feb 19 10:51:53 EST
> 2008 i686 Dual-Core AMD Opteron(tm) Processor 2218 HE AuthenticAMD GNU/Linux
> Java 1.6.0_11-b03
>Reporter: Nick Sieger
>Priority: Critical
> Attachments: ci.jruby.org-jenkins-node.log,
> ci.jruby.org-jenkins-node2.log
>
>
> I have ci.jruby.org running a recent Jenkins build with a master and 3 remote
> nodes started by JNLP. After a while the nodes get disconnected, and the
> master's log starts filling up with these stack traces:
> {noformat}
> Feb 7, 2011 12:22:00 PM hudson.remoting.ProxyOutputStream$Chunk$1 run
> WARNING: Failed to write to stream
> winstone.ClientSocketException: Failed to write to client
> at winstone.ClientOutputStream.write(ClientOutputStream.java:41)
> at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:181)
> at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:119)
> at winstone.WinstoneOutputStream.write(WinstoneOutputStream.java:112)
> at java.io.OutputStream.write(OutputStream.java:58)
> at
> hudson.remoting.ProxyOutputStream$Chunk$1.run(ProxyOutputStream.java:185)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.net.SocketException: Connection reset
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:96)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at winstone.ClientOutputStream.write(ClientOutputStream.java:39)
> ... 11 more
> Feb 7, 2011 12:22:00 PM hudson.remoting.ProxyOutputStream$Chunk$1 run
> WARNING: Failed to write to stream
> winstone.ClientSocketException: Failed to write to client
> at winstone.ClientOutputStream.write(ClientOutputStream.java:41)
> at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:181)
> at winstone.WinstoneOutputStream.commit(WinstoneOutputStream.java:119)
> at winstone.WinstoneOutputStream.write(WinstoneOutputStream.java:112)
> at java.io.OutputStream.write(OutputStream.java:58)
> at
> hudson.remoting.ProxyOutputStream$Chunk$1.run(ProxyOutputStream.java:185)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
> at java.util.concurrent.FutureTask.run(FutureTask.java:138)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> Caused by: java.net.SocketException: Broken pipe
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at winstone.ClientOutputStream.write(ClientOutputStream.java:39)
> ... 11 more
> {noformat}
> I can provide a login to the Jenkins instance on ci.jruby.org if desired.
--
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-7984) notifyCommit holds changes for about an hour after Hudson restart
[ https://issues.jenkins-ci.org/browse/JENKINS-7984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159302#comment-159302 ] tpesce commented on JENKINS-7984: - We are currently on Jenkins 1.444, and this is no longer an issue. > notifyCommit holds changes for about an hour after Hudson restart > - > > Key: JENKINS-7984 > URL: https://issues.jenkins-ci.org/browse/JENKINS-7984 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current >Reporter: tpesce > > We are currently on 1.383, but this issue has been around for the past 4 or 5 > versions. > We have a Subversion post-commit hook configured as per > http://wiki.jenkins-ci.org/display/JENKINS/Subversion+Plugin. Under normal > operations this approach is rock solid. However, immediately after Hudson > restarts SVN changes do not trigger builds. > What appears to be happening is that Hudson receives the notifyCommit > information correctly, but holds onto it for around an hour. For us the > timing is very reproducible; all changes across different projects and svn > branches seem to be held for right around an hour after restart. Once the > hour is over, all of the related jobs appear in the queue and build as > normal, and subsequent SVN updates trigger immediate builds. > We've looked at logs but haven't seen anything indicating that the > post-commit hook is being delayed. We've also tried debugging from the SVN > side, re-running the post-commit hook and manually interacting with the > notifyCommit URL, but Hudson seems to be returning successful status in all > cases. -- 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-12616) Tests failes but the job is still OK
[ https://issues.jenkins-ci.org/browse/JENKINS-12616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159303#comment-159303 ] Vladimir Zak commented on JENKINS-12616: yes, the same setting and the same behavior ;) this is really problem > Tests failes but the job is still OK > > > Key: JENKINS-12616 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12616 > Project: Jenkins > Issue Type: Bug > Components: xunit > Environment: jenkins 1.445 > xunit 1.34 > Ubuntu server 11.11 >Reporter: Thomas Fürer >Assignee: gbois >Priority: Blocker > Attachments: boost-config.PNG, failedButOK.PNG, TEST-failed.xml > > > just use the attached result file with BOOST > the error is listed correct in the test report, but the job is still OK but > need to be at least UNSTABLE. > As you can see in the screenshot I do not have any thresholds set. > I do not have any example at the moment, but I think we have this problem > also with NUnit tests. -- 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-12616) Tests failes but the job is still OK
[ https://issues.jenkins-ci.org/browse/JENKINS-12616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159303#comment-159303 ] Vladimir Zak edited comment on JENKINS-12616 at 2/20/12 6:49 PM: - yes, the same setting and the same behavior - this is problem with cppunit too. was (Author: zakyn): yes, the same setting and the same behavior ;) this is really problem > Tests failes but the job is still OK > > > Key: JENKINS-12616 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12616 > Project: Jenkins > Issue Type: Bug > Components: xunit > Environment: jenkins 1.445 > xunit 1.34 > Ubuntu server 11.11 >Reporter: Thomas Fürer >Assignee: gbois >Priority: Blocker > Attachments: boost-config.PNG, failedButOK.PNG, TEST-failed.xml > > > just use the attached result file with BOOST > the error is listed correct in the test report, but the job is still OK but > need to be at least UNSTABLE. > As you can see in the screenshot I do not have any thresholds set. > I do not have any example at the moment, but I think we have this problem > also with NUnit tests. -- 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-12782) Scanning for ! in Task Scanner Plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159304#comment-159304 ] SCM/JIRA link daemon commented on JENKINS-12782: Code changed in jenkins User: Ulli Hafner Path: .classpath src/main/java/hudson/plugins/tasks/parser/Task.java src/main/java/hudson/plugins/tasks/parser/TaskScanner.java src/test/java/hudson/plugins/tasks/parser/TaskScannerTest.java src/test/resources/hudson/plugins/tasks/parser/issue12782.txt http://jenkins-ci.org/commit/tasks-plugin/0e484b07198f41851bda4c3bf5a02161d1077e8b Log: [FIXED JENKINS-12782] Don't match word boundary if first or last character is not alpha numeric. > Scanning for ! in Task Scanner Plugin > - > > Key: JENKINS-12782 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12782 > Project: Jenkins > Issue Type: Bug > Components: tasks-plugin >Affects Versions: current > Environment: Windows Server >Reporter: Florian Loikasek >Assignee: Ulli Hafner >Priority: Minor > Labels: plugin > > I want to use the Task Scanner Plugin to scan for "!" in files as this > was used in older code instead of "TODO" - but no matter how I try to add it > to the configuration (I even tried some RegEx) I don't get it to treat it > like normal text. -- 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-12782) Scanning for ! in Task Scanner Plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-12782. Resolution: Fixed > Scanning for ! in Task Scanner Plugin > - > > Key: JENKINS-12782 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12782 > Project: Jenkins > Issue Type: Bug > Components: tasks-plugin >Affects Versions: current > Environment: Windows Server >Reporter: Florian Loikasek >Assignee: Ulli Hafner >Priority: Minor > Labels: plugin > > I want to use the Task Scanner Plugin to scan for "!" in files as this > was used in older code instead of "TODO" - but no matter how I try to add it > to the configuration (I even tried some RegEx) I don't get it to treat it > like normal text. -- 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-12482) Warnings not detected when file path does not appear after [WARNING]
[
https://issues.jenkins-ci.org/browse/JENKINS-12482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159305#comment-159305
]
SCM/JIRA link daemon commented on JENKINS-12482:
Code changed in jenkins
User: Ulli Hafner
Path:
src/main/java/hudson/plugins/warnings/parser/JavacParser.java
src/test/java/hudson/plugins/warnings/parser/JavacParserTest.java
src/test/resources/hudson/plugins/warnings/parser/issue12482-java6.txt
src/test/resources/hudson/plugins/warnings/parser/issue12482-java7.txt
http://jenkins-ci.org/commit/warnings-plugin/bf57fb2ccd81975749a6ce821e1b08d114bd3ce8
Log:
[FIXED JENKINS-12482] Improved regular expression of JavaC parser to
support Java 7 compiler format.
> Warnings not detected when file path does not appear after [WARNING]
>
>
> Key: JENKINS-12482
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12482
> Project: Jenkins
> Issue Type: Bug
> Components: warnings
>Affects Versions: current
> Environment: ubuntu, java 1.7.0_02, tomcat7, jenkins 1.447, warnings
> plugin v3.26, maven-compiler-plugin v2.3.2
>Reporter: Stefan Thurnherr
>Assignee: Ulli Hafner
>
> When compiling a Java project using the javac compiler, most of the warnings
> in my console log appear as follows:
> {noformat}
> [WARNING] BasicTableInfo
> /absolute/path/to/source/File.java:[143,66] [unchecked] unchecked conversion
> {noformat}
> and are thus not picked up by the warnings plugin.
> When there is no additional token before the source file path, such as in the
> following warning:
> {noformat}
> [WARNING] /absolute/path/to/source/File.java:[181,69] [unchecked] unchecked
> cast
> {noformat}
> then the warning is correctly picked up by the warnings plugin.
> Btw: Coloring in the console log has the same "bug": when the path appears as
> the first token (after [WARNING]), then the path and the next token (warning
> category) are highlighted in dark-yellow. When there is an additional token
> before the path, only that additional token is highlighted in dark-yellow
> (not the path and subsequent tokens).
--
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-12482) Warnings not detected when file path does not appear after [WARNING]
[
https://issues.jenkins-ci.org/browse/JENKINS-12482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
SCM/JIRA link daemon resolved JENKINS-12482.
Resolution: Fixed
> Warnings not detected when file path does not appear after [WARNING]
>
>
> Key: JENKINS-12482
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12482
> Project: Jenkins
> Issue Type: Bug
> Components: warnings
>Affects Versions: current
> Environment: ubuntu, java 1.7.0_02, tomcat7, jenkins 1.447, warnings
> plugin v3.26, maven-compiler-plugin v2.3.2
>Reporter: Stefan Thurnherr
>Assignee: Ulli Hafner
>
> When compiling a Java project using the javac compiler, most of the warnings
> in my console log appear as follows:
> {noformat}
> [WARNING] BasicTableInfo
> /absolute/path/to/source/File.java:[143,66] [unchecked] unchecked conversion
> {noformat}
> and are thus not picked up by the warnings plugin.
> When there is no additional token before the source file path, such as in the
> following warning:
> {noformat}
> [WARNING] /absolute/path/to/source/File.java:[181,69] [unchecked] unchecked
> cast
> {noformat}
> then the warning is correctly picked up by the warnings plugin.
> Btw: Coloring in the console log has the same "bug": when the path appears as
> the first token (after [WARNING]), then the path and the next token (warning
> category) are highlighted in dark-yellow. When there is an additional token
> before the path, only that additional token is highlighted in dark-yellow
> (not the path and subsequent tokens).
--
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-12397) Avoid post-build depoy to Maven repository in release build
[ https://issues.jenkins-ci.org/browse/JENKINS-12397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] domi resolved JENKINS-12397. Resolution: Fixed will be in core 1.453 > Avoid post-build depoy to Maven repository in release build > --- > > Key: JENKINS-12397 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12397 > Project: Jenkins > Issue Type: Bug > Components: m2release >Reporter: Kai Dyrssen >Assignee: teilo > > The Jenkins post-build feature "deploy to Maven repository" in conjunction > with a release build with m2release plugin leads to corrupt snapshot version > in Maven snapshot repository: > After the release build succeeds the post-build deploy deploys the new > development version pom-file as old development version to our maven snapshot > repository. > If possible the m2release plugin should disable the post-build deploy feature > in its release build. -- 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-12482) Warnings not detected when file path does not appear after [WARNING]
[
https://issues.jenkins-ci.org/browse/JENKINS-12482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159307#comment-159307
]
dogfood commented on JENKINS-12482:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[plugins_warnings #355|http://ci.jenkins-ci.org/job/plugins_warnings/355/]
[FIXED JENKINS-12482] Improved regular expression of JavaC parser to
(Revision bf57fb2ccd81975749a6ce821e1b08d114bd3ce8)
Result = SUCCESS
Ulli Hafner :
Files :
* src/test/resources/hudson/plugins/warnings/parser/issue12482-java7.txt
* src/test/resources/hudson/plugins/warnings/parser/issue12482-java6.txt
* src/main/java/hudson/plugins/warnings/parser/JavacParser.java
* src/test/java/hudson/plugins/warnings/parser/JavacParserTest.java
> Warnings not detected when file path does not appear after [WARNING]
>
>
> Key: JENKINS-12482
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12482
> Project: Jenkins
> Issue Type: Bug
> Components: warnings
>Affects Versions: current
> Environment: ubuntu, java 1.7.0_02, tomcat7, jenkins 1.447, warnings
> plugin v3.26, maven-compiler-plugin v2.3.2
>Reporter: Stefan Thurnherr
>Assignee: Ulli Hafner
>
> When compiling a Java project using the javac compiler, most of the warnings
> in my console log appear as follows:
> {noformat}
> [WARNING] BasicTableInfo
> /absolute/path/to/source/File.java:[143,66] [unchecked] unchecked conversion
> {noformat}
> and are thus not picked up by the warnings plugin.
> When there is no additional token before the source file path, such as in the
> following warning:
> {noformat}
> [WARNING] /absolute/path/to/source/File.java:[181,69] [unchecked] unchecked
> cast
> {noformat}
> then the warning is correctly picked up by the warnings plugin.
> Btw: Coloring in the console log has the same "bug": when the path appears as
> the first token (after [WARNING]), then the path and the next token (warning
> category) are highlighted in dark-yellow. When there is an additional token
> before the path, only that additional token is highlighted in dark-yellow
> (not the path and subsequent tokens).
--
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-12782) Scanning for ! in Task Scanner Plugin
[ https://issues.jenkins-ci.org/browse/JENKINS-12782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159308#comment-159308 ] dogfood commented on JENKINS-12782: --- Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png! [plugins_tasks #320|http://ci.jenkins-ci.org/job/plugins_tasks/320/] [FIXED JENKINS-12782] Don't match word boundary if first or last (Revision 0e484b07198f41851bda4c3bf5a02161d1077e8b) Result = SUCCESS Ulli Hafner : Files : * src/main/java/hudson/plugins/tasks/parser/TaskScanner.java * src/test/java/hudson/plugins/tasks/parser/TaskScannerTest.java * .classpath * src/test/resources/hudson/plugins/tasks/parser/issue12782.txt * src/main/java/hudson/plugins/tasks/parser/Task.java > Scanning for ! in Task Scanner Plugin > - > > Key: JENKINS-12782 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12782 > Project: Jenkins > Issue Type: Bug > Components: tasks-plugin >Affects Versions: current > Environment: Windows Server >Reporter: Florian Loikasek >Assignee: Ulli Hafner >Priority: Minor > Labels: plugin > > I want to use the Task Scanner Plugin to scan for "!" in files as this > was used in older code instead of "TODO" - but no matter how I try to add it > to the configuration (I even tried some RegEx) I don't get it to treat it > like normal text. -- 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-9869) Jenkins Maven Release Plug-in fails because workspace directory does not exist
[ https://issues.jenkins-ci.org/browse/JENKINS-9869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159309#comment-159309 ] domi commented on JENKINS-9869: --- does this issue still exist or can we close it? > Jenkins Maven Release Plug-in fails because workspace directory does not exist > -- > > Key: JENKINS-9869 > URL: https://issues.jenkins-ci.org/browse/JENKINS-9869 > Project: Jenkins > Issue Type: Bug > Components: m2release >Affects Versions: current > Environment: Mac OS X 10.6.7 >Reporter: Derek Allwardt >Assignee: teilo > Fix For: current > > Attachments: consoleText.tar.gz, > SampleProjectsForMavenReleaseIssue.zip > > > I have a multi-module maven project. It successfully builds, and the > release:prepare successfully competes. However, after all of the steps > (looking at console output) have completed, the whole thing fails when it > tries to do something with an extra workspace directory that doesn't exist. > Here's the last part of the exception. > Caused by: org.codehaus.plexus.util.cli.CommandLineException: Working > directory > "/Users/dallwardt/.jenkins/jobs/Vault-test6/workspace/target/checkout/workspace" > does not exist! > at > org.codehaus.plexus.util.cli.Commandline.execute(Commandline.java:644) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:118) > at > org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:93) > at > org.apache.maven.shared.invoker.DefaultInvoker.executeCommandLine(DefaultInvoker.java:149) > at > org.apache.maven.shared.invoker.DefaultInvoker.execute(DefaultInvoker.java:102) > at > org.apache.maven.shared.release.exec.InvokerMavenExecutor.executeGoals(InvokerMavenExecutor.java:387) > ... 36 more > channel stopped > Finished: FAILURE > Here's what the file system looks like: > dallwardt$ pwd > /Users/dallwardt/.jenkins/jobs/Vault-test6/workspace > dallwardt$ ls > CommonWzlDocs pom.xml > pom.xml.releaseBackup release.propertiestarget > dallwardt$ pwd > /Users/dallwardt/.jenkins/jobs/Vault-test6/workspace/target/checkout > dallwardt$ ls > dev tags trunk > > Notice there is no workspace directory under target/checkout. Who is supposed > to create an extra workspace folder under target/checkout ? -- 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-12834) multiple war from maven project
[ https://issues.jenkins-ci.org/browse/JENKINS-12834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas De Loof resolved JENKINS-12834. --- Assignee: Nicolas De Loof (was: olamy) Resolution: Fixed > multiple war from maven project > --- > > Key: JENKINS-12834 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12834 > Project: Jenkins > Issue Type: Bug > Components: cloudbees-deployer >Reporter: Nicolas De Loof >Assignee: Nicolas De Loof > > When project generates multiple war artifacts, plugin takes the first one > found in maven artifacts but don't even warn the user for ambiguous > configuration. -- 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-12822) Java import of deprecated type not recognized as warning
[ https://issues.jenkins-ci.org/browse/JENKINS-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159310#comment-159310 ] Ulli Hafner commented on JENKINS-12822: --- Integrated in !http://faktorzehn.org:8081/images/16x16/blue.png! [Jenkins Analysis Plug-ins (Compile) #398|http://faktorzehn.org:8081/job/Jenkins%20Analysis%20Plug-ins%20(Compile)/398/] [JENKINS-12822] [JENKINS-12801] Added support for columns in warnings. (Revision 5123f0efb7b7b2d9bb26c7970c4e2bd83791746a) Result = SUCCESS > Java import of deprecated type not recognized as warning > > > Key: JENKINS-12822 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12822 > Project: Jenkins > Issue Type: Bug > Components: warnings >Reporter: Alexander Weickmann >Assignee: Ulli Hafner >Priority: Minor > > # Mark a Java type to be deprecated > # Import that Java type into another Java type > # The import is not recognized as warning, even though the warning was > written to the console by the build -- 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-12801) When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
[
https://issues.jenkins-ci.org/browse/JENKINS-12801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159311#comment-159311
]
Ulli Hafner commented on JENKINS-12801:
---
Integrated in !http://faktorzehn.org:8081/images/16x16/blue.png! [Jenkins
Analysis Plug-ins (Compile)
#398|http://faktorzehn.org:8081/job/Jenkins%20Analysis%20Plug-ins%20(Compile)/398/]
[JENKINS-12822] [JENKINS-12801] Added support for columns in warnings.
(Revision 5123f0efb7b7b2d9bb26c7970c4e2bd83791746a)
Result = SUCCESS
> When there are 2 PMD warnings on 1 line the Jenkins report does only report 1
> -
>
> Key: JENKINS-12801
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12801
> Project: Jenkins
> Issue Type: Bug
> Components: pmd
>Reporter: Cees Bos
>Assignee: Ulli Hafner
>Priority: Minor
>
> We have this line of code:
> {code:java}
> public boolean hasNext()
> {
> return cursor == EMPTY && entity != EMPTY;
> }
> {code}
> PMD xml report has these violations reported:
> {code:xml}
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> rule="CompareObjectsWithEquals" ruleset="Design Rules"
> package="com.myapplication.util.collections"
> class="SingleSet$SingleSetIterator" method="hasNext"
> externalInfoUrl="http://pmd.sourceforge.net/rules/design.html#CompareObjectsWithEquals";
> priority="3">
> Use equals() to compare object references.
>
> {code}
> Is reports 2 issues on the same line. Other begincolumn and other endcolumn.
> In the UI it is only reported once.
> And the total number of violations does not match with the actual number of
> violations.
--
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-12704) WORKSPACE variable for concurrent builds are not defined properly.
[
https://issues.jenkins-ci.org/browse/JENKINS-12704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159312#comment-159312
]
SCM/JIRA link daemon commented on JENKINS-12704:
Code changed in jenkins
User: Gregory Boissinot
Path:
src/main/java/org/jenkinsci/plugins/envinject/service/EnvInjectVariableGetter.java
http://jenkins-ci.org/commit/envinject-plugin/15363ba6de7e9593ff6bd9822da843ad335e8069
Log:
Fix JENKINS-12704
> WORKSPACE variable for concurrent builds are not defined properly.
> --
>
> Key: JENKINS-12704
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12704
> Project: Jenkins
> Issue Type: Bug
> Components: concurrent-build, envinject
> Environment: redhat (master/slave)
> jenkins ver=1.448
>Reporter: Natalia Naumova
>Assignee: Kohsuke Kawaguchi
>
> I have master/slave setup, and my project has the ability to execute builds
> in parallel, i.e. I have 'Execute concurrent builds if necessary' option
> turned on.
> But when I'm trying to inject any environment variables into my job ( 'Inject
> environment variables to the build process' option ), then the $WORKSPACE
> variable is NOT defined properly for parallel builds.
> They should be
>
> ${JENKINS_HOME/workspace/${JOB_NAME}
> ${JENKINS_HOME/workspace/${JOB_NAME}@2
> ${JENKINS_HOME/workspace/${JOB_NAME}@3
> ...
> But $WORKSPACE always points to
>
> ${JENKINS_HOME/workspace/${JOB_NAME}
> for all job runs.
--
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-12704) WORKSPACE variable for concurrent builds are not defined properly.
[
https://issues.jenkins-ci.org/browse/JENKINS-12704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
gbois resolved JENKINS-12704.
-
Assignee: gbois (was: Kohsuke Kawaguchi)
Resolution: Fixed
> WORKSPACE variable for concurrent builds are not defined properly.
> --
>
> Key: JENKINS-12704
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12704
> Project: Jenkins
> Issue Type: Bug
> Components: concurrent-build, envinject
> Environment: redhat (master/slave)
> jenkins ver=1.448
>Reporter: Natalia Naumova
>Assignee: gbois
>
> I have master/slave setup, and my project has the ability to execute builds
> in parallel, i.e. I have 'Execute concurrent builds if necessary' option
> turned on.
> But when I'm trying to inject any environment variables into my job ( 'Inject
> environment variables to the build process' option ), then the $WORKSPACE
> variable is NOT defined properly for parallel builds.
> They should be
>
> ${JENKINS_HOME/workspace/${JOB_NAME}
> ${JENKINS_HOME/workspace/${JOB_NAME}@2
> ${JENKINS_HOME/workspace/${JOB_NAME}@3
> ...
> But $WORKSPACE always points to
>
> ${JENKINS_HOME/workspace/${JOB_NAME}
> for all job runs.
--
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-8298) Reloading persona does not reloads existing persona quotes
[ https://issues.jenkins-ci.org/browse/JENKINS-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159313#comment-159313 ] evernat commented on JENKINS-8298: -- I suggest to submit a pull request in github: https://github.com/jenkinsci/persona-plugin Thanks > Reloading persona does not reloads existing persona quotes > -- > > Key: JENKINS-8298 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8298 > Project: Jenkins > Issue Type: Bug > Components: persona >Affects Versions: current >Reporter: whren > Attachments: persona.hpi, persona.jar, persona.zip > > > When using the reload persona url, it does not reload personas quotes. It > only loads potentialy new personas. > Looks like a Persona.reload() is missing in > hudson.plugins.persona.xml.XmlPersonaReloader.doIndex(StaplerResponse rsp). -- 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-8841) ProcessTreeKiller error loading winp.dll
[ https://issues.jenkins-ci.org/browse/JENKINS-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159314#comment-159314 ] evernat commented on JENKINS-8841: -- according to the following page, you need to use the system property: "-Dhudson.util.ProcessTree.disable=true" (or "-Dhudson.util.ProcessTreeKiller.disable=true"). See https://wiki.jenkins-ci.org/display/JENKINS/ProcessTreeKiller Is it still an issue for you? > ProcessTreeKiller error loading winp.dll > > > Key: JENKINS-8841 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8841 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: OS: Windows 7 Professional x86 or Windows 2003 Server SP2 > Java: jdk1.6.0 x86 >Reporter: Leonardo Zanivan > Fix For: current > > Attachments: stacktrace.txt > > > Simulation: > 1. Create a job called "TESTE" with the Windows command: notepad.exe > 2. Start your job "TESTE", check that Notepad is started (dont close). > 3. Cancel the build of the job "TESTE" and see that Notepad is still open. > 4. Check the stacktrace on the server console, as attached file. > Problem: > When you cancel a build, the process that started don't closes. > Workaround: > 1. Copy the file "WEB-INF\lib\winp.dll" to the directory > "C:\Windows\system32" and restart the server. > PS: ProcessTreeKiller is enabled. -- 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-9740) Access to static content is denied when jenkins works in private mode (anonymous access is disabled)
[
https://issues.jenkins-ci.org/browse/JENKINS-9740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159315#comment-159315
]
Lars Vonk commented on JENKINS-9740:
any updates or workaround? same goes for the openid which is unusable then
disabling anonymous access.
> Access to static content is denied when jenkins works in private mode
> (anonymous access is disabled)
>
>
> Key: JENKINS-9740
> URL: https://issues.jenkins-ci.org/browse/JENKINS-9740
> Project: Jenkins
> Issue Type: Bug
> Components: core, security
>Reporter: jsirex
>
> When jenkins works in private mode (anonymous access is disabled) I unable to
> access some static content. It affects to some things like:
> * Adding slaves via Web Start (Jnlp) -> install as service
> {quote}jenkins slave tries access thorugh url jenkins-slave.jnlp which is
> unaccessible with out authorization
> I have to manually download this file and update xml-config with new
> path{quote}
> * Email notification contains links to static images which also unavailable
> for anonymous
> * Jira-plugin leave comments with links to static images too
> * etc
> I think an permission "Allow access to static content
> (${JENKINS_URL}/static/*)" which I can assign to anonymous will fix many such
> problems
> PS. Not sure what component I have to specify
--
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-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
Brian Freed created JENKINS-12837:
-
Summary: Using a variable injected during "Prepare envrionment"
stage doesn't work for Perforce Label during SCM
Key: JENKINS-12837
URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
Project: Jenkins
Issue Type: Bug
Components: envinject, perforce
Affects Versions: current
Environment: Windows
Reporter: Brian Freed
Assignee: gbois
Priority: Minor
I am trying to inject a variable from a file which will tell a Jenkins test job
what perforce label it should use during SCM
My file is named change.properties and looks like this:
p4.changelist=386494
In the test job, I have clicked the 'Prepare an environment for the job'
section and then added the file location in the 'Properties File Path' box
In the Perforce section, I am setting the perforce Label to be
GPTCDTEST${p4.changelist}
However when I run the job, I get this error:
Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
which makes me think that it wasn't able to pick up the p4.changelist variable
I injected.
I have been able to do this by having an upstream job trigger the test job with
parameters from the file, and this works fine, but I want to be able to have
the job run on it own without requiring the upstream job.
I also tried just inserting this variable in the 'Properties Content' section,
but Perforce still can't find it:
[EnvInject] - Injecting as environment variables the properties content
p4.changelist=322332
[EnvInject] - Variables injected successfully.
...
com.tek42.perforce.PerforceException: Errors encountered while force syncing:
error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
Is there an issue with linking up a variable from the Prepare Environment
section to the perforce SCM section?
--
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-11920) All jobs (even a job with no steps) hang for twenty minutes after completion on Solaris
[ https://issues.jenkins-ci.org/browse/JENKINS-11920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159316#comment-159316 ] Stephen Morrison commented on JENKINS-11920: I see the same thing. I run the exact same job on Linux, HP, and Sun machines. The job always seems to hang on Sun after completion, although for me, whilst the job eventually disappears from the executor and is marked in the job history as complete, when I look at the console the build output shows the "in progress" animation circle still going. > All jobs (even a job with no steps) hang for twenty minutes after completion > on Solaris > --- > > Key: JENKINS-11920 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11920 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Host: SunOS 5.10 Generic_144488-04 sun4u sparc > SUNW,Sun-Fire > JVM: java version "1.6.0_12" > Java(TM) Platform, Standard Edition for Business (build 1.6.0_12-b04) > Java HotSpot(TM) Server VM (build 11.2-b01, mixed mode) > Run method: java -jar jenkins.war > JVM Args: -server -d64 -XX:+UseConcMarkSweepGC -Xmx5G > Jenkins Args: --ajp13Port=20006 --httpPort=20006 >Reporter: Simon > Attachments: build-output-of-hanging-job.png, build-output.png, > build-status.png, hudson.util.Process-entries.log, noopjob-configuration.png, > thread_dumpt.txt > > > We find that on our solaris host that all jobs hang for about twenty minutes > after they have completed. This is true even of jobs that contain no steps. > No additional plugins have been installed. > The threaddump page reveals that the job seems to hang on reading from the > proc file system, > Executor #0 for master : executing noopjob #1 > "Executor #0 for master : executing noopjob #1" Id=82 Group=main RUNNABLE > at java.io.RandomAccessFile.read(Native Method) > at > hudson.util.ProcessTree$Solaris$SolarisProcess.readLine(ProcessTree.java:846) > at > hudson.util.ProcessTree$Solaris$SolarisProcess.getEnvironmentVariables(ProcessTree.java:826) > - locked hudson.util.ProcessTree$Solaris$SolarisProcess@6322be0b > at > hudson.util.ProcessTree$OSProcess.hasMatchingEnvVars(ProcessTree.java:266) > at hudson.util.ProcessTree$Unix.killAll(ProcessTree.java:482) > at hudson.Launcher$LocalLauncher.kill(Launcher.java:730) > at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:484) > at hudson.model.Run.run(Run.java:1404) > at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) > at hudson.model.ResourceController.execute(ResourceController.java:88) > at hudson.model.Executor.run(Executor.java:230) > The noopjob job is a "free-style software project" job and contains no steps. > I've attached the thread dump and several screenshots > I have more information now after increasing the logging level of > hudson.util.ProcessTree to FINER. I have attached the log entries that were > written during the execution of the job with no steps. From the log entries > it seems that one or more instances of ProcessTree$Solaris$SolarisProcess are > reading the /proc//as of several processes (perhaps all processes on the > host). It blocks on a few of them: 11665 for just under a minute, 20118 for > 4 minutes, 9522 for 1 minute, 11665 for 4 minutes, and 357 for just under a > minute. Each of these process have nothing to do with jenkins. > I've figured out that each of these processes are instances of the same > application - a large java application that is running on the same host. -- 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-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
[
https://issues.jenkins-ci.org/browse/JENKINS-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Freed updated JENKINS-12837:
--
Priority: Blocker (was: Minor)
> Using a variable injected during "Prepare envrionment" stage doesn't work for
> Perforce Label during SCM
> ---
>
> Key: JENKINS-12837
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
> Project: Jenkins
> Issue Type: Bug
> Components: envinject, perforce
>Affects Versions: current
> Environment: Windows
>Reporter: Brian Freed
>Assignee: gbois
>Priority: Blocker
>
> I am trying to inject a variable from a file which will tell a Jenkins test
> job what perforce label it should use during SCM
> My file is named change.properties and looks like this:
> p4.changelist=386494
> In the test job, I have clicked the 'Prepare an environment for the job'
> section and then added the file location in the 'Properties File Path' box
> In the Perforce section, I am setting the perforce Label to be
> GPTCDTEST${p4.changelist}
> However when I run the job, I get this error:
> Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> which makes me think that it wasn't able to pick up the p4.changelist
> variable I injected.
> I have been able to do this by having an upstream job trigger the test job
> with parameters from the file, and this works fine, but I want to be able to
> have the job run on it own without requiring the upstream job.
> I also tried just inserting this variable in the 'Properties Content'
> section, but Perforce still can't find it:
> [EnvInject] - Injecting as environment variables the properties content
> p4.changelist=322332
> [EnvInject] - Variables injected successfully.
> ...
> com.tek42.perforce.PerforceException: Errors encountered while force syncing:
> error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> Is there an issue with linking up a variable from the Prepare Environment
> section to the perforce SCM section?
--
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-12828) semicolon parameter separator for cloudformation
[
https://issues.jenkins-ci.org/browse/JENKINS-12828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
edovale resolved JENKINS-12828.
---
Resolution: Fixed
> semicolon parameter separator for cloudformation
>
>
> Key: JENKINS-12828
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12828
> Project: Jenkins
> Issue Type: Improvement
> Components: cloudformation
>Reporter: Matt Fair
>Assignee: edovale
>
> Currently the parameter list is comma delimited and therefore does not
> support CommaDelimitedList type parameter values. To fix this the semicolon
> delimiter can be added as the primary delimiter. The cfn-create-stack
> command line application uses the semicolon as its parameter separator:
> {code}
> param1=value1;param2=value2;param3=list1,list2,list3,list4;param5=value5
> {code}
--
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-12838) Update documentation for parameters field in stack form
edovale created JENKINS-12838: - Summary: Update documentation for parameters field in stack form Key: JENKINS-12838 URL: https://issues.jenkins-ci.org/browse/JENKINS-12838 Project: Jenkins Issue Type: Improvement Components: cloudformation Reporter: edovale Assignee: edovale Need to add that parameters can also be separated by semi colons now to allow for passing lists into CF. -- 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-10466) repository from jenkins main menu shows plain html codes
[ https://issues.jenkins-ci.org/browse/JENKINS-10466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159317#comment-159317 ] cforce commented on JENKINS-10466: -- There is also an report for Safari Browser Paul Austin says: The plugin looks great but it does not create full HTML and/or set the correct m... The plugin looks great but it does not create full HTML and/or set the correct mime type. This means in Safari you see. com.revolsys.openFri Feb 17 14:15:39 PST 2012DIR SHA1Fri Feb 17 14:15:39 PST 2012 DIRBuild Fri Feb 17 14:15:39 PST 2012DIRLastSuccessful Recommendation: 1. Make all the tags in lower case 2. Include the full html (e.g. ... source: https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Maven+Repository+Server?focusedCommentId=59511509#comment-59511509 > repository from jenkins main menu shows plain html codes > > > Key: JENKINS-10466 > URL: https://issues.jenkins-ci.org/browse/JENKINS-10466 > Project: Jenkins > Issue Type: Bug > Components: repository >Reporter: cforce >Assignee: magnayn > > There must be an error in hmtl side, because the browser (ie, fox) can't show > the html code that is printed as plain text wehn clicking "Maven Repository" > link in Jenkins Main Menu. -- 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-8298) Reloading persona does not reloads existing persona quotes
[ https://issues.jenkins-ci.org/browse/JENKINS-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159318#comment-159318 ] whren commented on JENKINS-8298: Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 > Reloading persona does not reloads existing persona quotes > -- > > Key: JENKINS-8298 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8298 > Project: Jenkins > Issue Type: Bug > Components: persona >Affects Versions: current >Reporter: whren > Attachments: persona.hpi, persona.jar, persona.zip > > > When using the reload persona url, it does not reload personas quotes. It > only loads potentialy new personas. > Looks like a Persona.reload() is missing in > hudson.plugins.persona.xml.XmlPersonaReloader.doIndex(StaplerResponse rsp). -- 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-8298) Reloading persona does not reloads existing persona quotes
[ https://issues.jenkins-ci.org/browse/JENKINS-8298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] whren updated JENKINS-8298: --- Description: When using the reload persona url, it does not reload personas quotes. It only loads potentialy new personas. Looks like a Persona.reload() is missing in hudson.plugins.persona.xml.XmlPersonaReloader.doIndex(StaplerResponse rsp). Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 was: When using the reload persona url, it does not reload personas quotes. It only loads potentialy new personas. Looks like a Persona.reload() is missing in hudson.plugins.persona.xml.XmlPersonaReloader.doIndex(StaplerResponse rsp). > Reloading persona does not reloads existing persona quotes > -- > > Key: JENKINS-8298 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8298 > Project: Jenkins > Issue Type: Bug > Components: persona >Affects Versions: current >Reporter: whren > Attachments: persona.hpi, persona.jar, persona.zip > > > When using the reload persona url, it does not reload personas quotes. It > only loads potentialy new personas. > Looks like a Persona.reload() is missing in > hudson.plugins.persona.xml.XmlPersonaReloader.doIndex(StaplerResponse rsp). > Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 -- 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-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
[
https://issues.jenkins-ci.org/browse/JENKINS-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159319#comment-159319
]
Brian Freed commented on JENKINS-12837:
---
I have been able to verify that the Perforce Plugin can use global environment
variables such as PATH, but is unable to find the local environment variables
that were injected.
Can the Perforce Plugin be updated to be able to use these local environment
variables for property substitution?
> Using a variable injected during "Prepare envrionment" stage doesn't work for
> Perforce Label during SCM
> ---
>
> Key: JENKINS-12837
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
> Project: Jenkins
> Issue Type: Bug
> Components: envinject, perforce
>Affects Versions: current
> Environment: Windows
>Reporter: Brian Freed
>Assignee: gbois
>Priority: Blocker
>
> I am trying to inject a variable from a file which will tell a Jenkins test
> job what perforce label it should use during SCM
> My file is named change.properties and looks like this:
> p4.changelist=386494
> In the test job, I have clicked the 'Prepare an environment for the job'
> section and then added the file location in the 'Properties File Path' box
> In the Perforce section, I am setting the perforce Label to be
> GPTCDTEST${p4.changelist}
> However when I run the job, I get this error:
> Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> which makes me think that it wasn't able to pick up the p4.changelist
> variable I injected.
> I have been able to do this by having an upstream job trigger the test job
> with parameters from the file, and this works fine, but I want to be able to
> have the job run on it own without requiring the upstream job.
> I also tried just inserting this variable in the 'Properties Content'
> section, but Perforce still can't find it:
> [EnvInject] - Injecting as environment variables the properties content
> p4.changelist=322332
> [EnvInject] - Variables injected successfully.
> ...
> com.tek42.perforce.PerforceException: Errors encountered while force syncing:
> error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> Is there an issue with linking up a variable from the Prepare Environment
> section to the perforce SCM section?
--
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-8296) Allow use of random persona instead of a fix one
[ https://issues.jenkins-ci.org/browse/JENKINS-8296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] whren updated JENKINS-8296: --- Description: It would be great to allow per project use of a random persona at each launch of a build. How : In the configuration of a project, the "Random Persona" will be choose in the list of available personas. At each launch of a build the plugin will verify if the choosen persona is the "Random Persona", if so this "Random Persona" will randomize the choose of one of the personas configured. The remaining process will be the same as today. The project quote and icon will of course reflect the last build. Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 was: It would be great to allow per project use of a random persona at each launch of a build. How : In the configuration of a project, the "Random Persona" will be choose in the list of available personas. At each launch of a build the plugin will verify if the choosen persona is the "Random Persona", if so this "Random Persona" will randomize the choose of one of the personas configured. The remaining process will be the same as today. The project quote and icon will of course reflect the last build. > Allow use of random persona instead of a fix one > > > Key: JENKINS-8296 > URL: https://issues.jenkins-ci.org/browse/JENKINS-8296 > Project: Jenkins > Issue Type: Improvement > Components: persona >Affects Versions: current >Reporter: whren > Attachments: persona.hpi, persona.jar, persona.zip > > > It would be great to allow per project use of a random persona at each launch > of a build. > How : > In the configuration of a project, the "Random Persona" will be choose in the > list of available personas. > At each launch of a build the plugin will verify if the choosen persona is > the "Random Persona", if so this "Random Persona" will randomize the choose > of one of the personas configured. > The remaining process will be the same as today. > The project quote and icon will of course reflect the last build. > Pull request made : https://github.com/jenkinsci/persona-plugin/pull/1 -- 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-12616) Tests failes but the job is still OK
[ https://issues.jenkins-ci.org/browse/JENKINS-12616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159320#comment-159320 ] gbois commented on JENKINS-12616: - If you don't have any threshold set, the expected build result is always set to SUCCESS. > Tests failes but the job is still OK > > > Key: JENKINS-12616 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12616 > Project: Jenkins > Issue Type: Bug > Components: xunit > Environment: jenkins 1.445 > xunit 1.34 > Ubuntu server 11.11 >Reporter: Thomas Fürer >Assignee: gbois >Priority: Blocker > Attachments: boost-config.PNG, failedButOK.PNG, TEST-failed.xml > > > just use the attached result file with BOOST > the error is listed correct in the test report, but the job is still OK but > need to be at least UNSTABLE. > As you can see in the screenshot I do not have any thresholds set. > I do not have any example at the moment, but I think we have this problem > also with NUnit tests. -- 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-6692) Timeline should use server's timezone, not GMT
[ https://issues.jenkins-ci.org/browse/JENKINS-6692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159321#comment-159321 ] andrey regentov commented on JENKINS-6692: -- Still seeing this in 1.450. Time is 1 hour back. > Timeline should use server's timezone, not GMT > -- > > Key: JENKINS-6692 > URL: https://issues.jenkins-ci.org/browse/JENKINS-6692 > Project: Jenkins > Issue Type: Bug > Components: core >Affects Versions: current > Environment: Server: Windows Server 2008 R2, Tomcat 6.0.20, JDK > 1.6.0_20, Hudson 1.357 > Client: Windows 7 Enterprise, Google Chrome 5.0 >Reporter: Mark Lewis >Assignee: Alan Harder >Priority: Minor > Attachments: JENKINS-6692.png, timeline-timezone.png > > > When viewing a job, the timeline displays times using GMT rather than the > server's timezone — EDT (GMT-0400) in my case. This means that a build > which took place at 12:57 PM shows up right before "17h" on the timeline, but > it should appear right before "13h" (see attached screenshot). -- 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-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
[
https://issues.jenkins-ci.org/browse/JENKINS-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159322#comment-159322
]
SCM/JIRA link daemon commented on JENKINS-12837:
Code changed in jenkins
User: Rob Petti
Path:
src/main/java/hudson/plugins/perforce/PerforceSCM.java
http://jenkins-ci.org/commit/perforce-plugin/5befc6822dbb7af0fb0f18a535efa0c826b89838
Log:
[FIXED JENKINS-12837] use full build environment for substitutions, not just
job parameters
> Using a variable injected during "Prepare envrionment" stage doesn't work for
> Perforce Label during SCM
> ---
>
> Key: JENKINS-12837
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
> Project: Jenkins
> Issue Type: Bug
> Components: envinject, perforce
>Affects Versions: current
> Environment: Windows
>Reporter: Brian Freed
>Assignee: gbois
>Priority: Blocker
>
> I am trying to inject a variable from a file which will tell a Jenkins test
> job what perforce label it should use during SCM
> My file is named change.properties and looks like this:
> p4.changelist=386494
> In the test job, I have clicked the 'Prepare an environment for the job'
> section and then added the file location in the 'Properties File Path' box
> In the Perforce section, I am setting the perforce Label to be
> GPTCDTEST${p4.changelist}
> However when I run the job, I get this error:
> Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> which makes me think that it wasn't able to pick up the p4.changelist
> variable I injected.
> I have been able to do this by having an upstream job trigger the test job
> with parameters from the file, and this works fine, but I want to be able to
> have the job run on it own without requiring the upstream job.
> I also tried just inserting this variable in the 'Properties Content'
> section, but Perforce still can't find it:
> [EnvInject] - Injecting as environment variables the properties content
> p4.changelist=322332
> [EnvInject] - Variables injected successfully.
> ...
> com.tek42.perforce.PerforceException: Errors encountered while force syncing:
> error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> Is there an issue with linking up a variable from the Prepare Environment
> section to the perforce SCM section?
--
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-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
[
https://issues.jenkins-ci.org/browse/JENKINS-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
SCM/JIRA link daemon resolved JENKINS-12837.
Resolution: Fixed
> Using a variable injected during "Prepare envrionment" stage doesn't work for
> Perforce Label during SCM
> ---
>
> Key: JENKINS-12837
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
> Project: Jenkins
> Issue Type: Bug
> Components: envinject, perforce
>Affects Versions: current
> Environment: Windows
>Reporter: Brian Freed
>Assignee: gbois
>Priority: Blocker
>
> I am trying to inject a variable from a file which will tell a Jenkins test
> job what perforce label it should use during SCM
> My file is named change.properties and looks like this:
> p4.changelist=386494
> In the test job, I have clicked the 'Prepare an environment for the job'
> section and then added the file location in the 'Properties File Path' box
> In the Perforce section, I am setting the perforce Label to be
> GPTCDTEST${p4.changelist}
> However when I run the job, I get this error:
> Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> which makes me think that it wasn't able to pick up the p4.changelist
> variable I injected.
> I have been able to do this by having an upstream job trigger the test job
> with parameters from the file, and this works fine, but I want to be able to
> have the job run on it own without requiring the upstream job.
> I also tried just inserting this variable in the 'Properties Content'
> section, but Perforce still can't find it:
> [EnvInject] - Injecting as environment variables the properties content
> p4.changelist=322332
> [EnvInject] - Variables injected successfully.
> ...
> com.tek42.perforce.PerforceException: Errors encountered while force syncing:
> error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> Is there an issue with linking up a variable from the Prepare Environment
> section to the perforce SCM section?
--
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-12837) Using a variable injected during "Prepare envrionment" stage doesn't work for Perforce Label during SCM
[
https://issues.jenkins-ci.org/browse/JENKINS-12837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159323#comment-159323
]
dogfood commented on JENKINS-12837:
---
Integrated in !http://ci.jenkins-ci.org/images/16x16/blue.png!
[plugins_perforce #180|http://ci.jenkins-ci.org/job/plugins_perforce/180/]
[FIXED JENKINS-12837] use full build environment for substitutions, not
just job parameters (Revision 5befc6822dbb7af0fb0f18a535efa0c826b89838)
Result = SUCCESS
Rob Petti :
Files :
* src/main/java/hudson/plugins/perforce/PerforceSCM.java
> Using a variable injected during "Prepare envrionment" stage doesn't work for
> Perforce Label during SCM
> ---
>
> Key: JENKINS-12837
> URL: https://issues.jenkins-ci.org/browse/JENKINS-12837
> Project: Jenkins
> Issue Type: Bug
> Components: envinject, perforce
>Affects Versions: current
> Environment: Windows
>Reporter: Brian Freed
>Assignee: gbois
>Priority: Blocker
>
> I am trying to inject a variable from a file which will tell a Jenkins test
> job what perforce label it should use during SCM
> My file is named change.properties and looks like this:
> p4.changelist=386494
> In the test job, I have clicked the 'Prepare an environment for the job'
> section and then added the file location in the 'Properties File Path' box
> In the Perforce section, I am setting the perforce Label to be
> GPTCDTEST${p4.changelist}
> However when I run the job, I get this error:
> Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> which makes me think that it wasn't able to pick up the p4.changelist
> variable I injected.
> I have been able to do this by having an upstream job trigger the test job
> with parameters from the file, and this works fine, but I want to be able to
> have the job run on it own without requiring the upstream job.
> I also tried just inserting this variable in the 'Properties Content'
> section, but Perforce still can't find it:
> [EnvInject] - Injecting as environment variables the properties content
> p4.changelist=322332
> [EnvInject] - Variables injected successfully.
> ...
> com.tek42.perforce.PerforceException: Errors encountered while force syncing:
> error: Invalid changelist/client/label/date '@GPTCDTEST${p4.changelist}'.
> Is there an issue with linking up a variable from the Prepare Environment
> section to the perforce SCM section?
--
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-11933) Subversion plugin doesn't probably work correctly with svn server version 1.7.1
[ https://issues.jenkins-ci.org/browse/JENKINS-11933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159324#comment-159324 ] Luke Last commented on JENKINS-11933: - Can someone please update to SVNKIT 1.3.7? This is preventing us from upgrading our server to Subversion 1.7 > Subversion plugin doesn't probably work correctly with svn server version > 1.7.1 > --- > > Key: JENKINS-11933 > URL: https://issues.jenkins-ci.org/browse/JENKINS-11933 > Project: Jenkins > Issue Type: Bug > Components: subversion >Affects Versions: current > Environment: svn server 1.7.1 > ubuntu >Reporter: Nikita Aznauryan >Priority: Blocker > Labels: plugin > Attachments: 0001-imported-1.3.7.patch, > 0002-Adjust-version-number-in-pom.patch, > 0003-update-version-and-add-second-maven-repository-to-ge.patch, > 0005_subversion_plugin_svnkit_1_3_7.patch > > > I use usernames in my svn path like: > svn+ssh://jenkins@somepath > but I get a warning "... doesn't exist in the repository" > I think it started after svn server has been updated to 1.7.1 version > It worked fine before. > Subversion pooling log : > Started on Nov 30, 2011 8:11:31 PM > Location 'svn+ssh://jenkins@path' does not exist > One or more repository locations do not exist anymore for > hudson.model.FreeStyleProject@3937bf4[], project will be disabled. > Done. Took 1.3 sec > No changes -- 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
How to clear workspace at the starting of every build
Hi Team, I need to clean the workspace at the starting of every build. I'm not able to see an option for this in Jenkins. I'm using Jenkins 1.443 version. Can anyone help me on this? -- View this message in context: http://jenkins.361315.n4.nabble.com/How-to-clear-workspace-at-the-starting-of-every-build-tp4406077p4406077.html Sent from the Jenkins issues mailing list archive at Nabble.com.
[JIRA] (JENKINS-9540) Copy Artifacts Plugin Throws "IOException: Pipe is already closed"
[
https://issues.jenkins-ci.org/browse/JENKINS-9540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159325#comment-159325
]
Ringo De Smet commented on JENKINS-9540:
Today I ended up in a situation where even the workaround of cleaning the
workspace and triggering a clean build doesn't work. A new build again ends up
having the exception.
What I do notice however: I have two times the Copy Artifact as build step in
place in this project. The first instance has a filter filled in, the second
one not. If Copy Artifact fails, it is always the second one that fails. While
I left the field "Artifacts to copy" blank to copy all artifacts, the exception
has as message:
{code}
ERROR: Failed to copy artifacts from Utilities-2.1-linux-64bit with filter: **
{code}
Filling in {{\*\*}} as filter myself is invalid input, so where does this
{{\*\*}} come from?
> Copy Artifacts Plugin Throws "IOException: Pipe is already closed"
> --
>
> Key: JENKINS-9540
> URL: https://issues.jenkins-ci.org/browse/JENKINS-9540
> Project: Jenkins
> Issue Type: Bug
> Components: copyartifact, core
>Affects Versions: current
> Environment: Windows XP SP3, Sun JRE 1.6.25
>Reporter: Dirk Weinhardt
>Assignee: Kohsuke Kawaguchi
> Fix For: current
>
>
> Since updating to Jenkins 1.409 and Copy Artifacts Plugin 1.16, build jobs
> fail with an IOException when copying build artifacts from the Master to the
> current Slave.
> ERROR: Failed to copy artifacts from ABC Build with filter:
> _tests\UnitTests\bin\Debug\**
> java.io.IOException: Pipe is already closed
> at hudson.remoting.PipeWindow.checkDeath(PipeWindow.java:83)
> at hudson.remoting.PipeWindow$Real.get(PipeWindow.java:165)
> at hudson.remoting.ProxyOutputStream._write(ProxyOutputStream.java:118)
> at hudson.remoting.ProxyOutputStream.write(ProxyOutputStream.java:103)
> at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
> at java.io.BufferedOutputStream.write(Unknown Source)
> at java.util.zip.DeflaterOutputStream.deflate(Unknown Source)
> at java.util.zip.DeflaterOutputStream.write(Unknown Source)
> at java.util.zip.GZIPOutputStream.write(Unknown Source)
> at java.io.BufferedOutputStream.write(Unknown Source)
> at org.apache.tools.tar.TarBuffer.writeBlock(TarBuffer.java:410)
> at org.apache.tools.tar.TarBuffer.writeRecord(TarBuffer.java:351)
> at
> hudson.org.apache.tools.tar.TarOutputStream.writeEOFRecord(TarOutputStream.java:356)
> at
> hudson.org.apache.tools.tar.TarOutputStream.finish(TarOutputStream.java:137)
> at
> hudson.org.apache.tools.tar.TarOutputStream.close(TarOutputStream.java:149)
> at hudson.util.io.TarArchiver.close(TarArchiver.java:119)
> at hudson.FilePath.writeToTar(FilePath.java:1596)
> at hudson.FilePath.copyRecursiveTo(FilePath.java:1521)
> at hudson.FilePath.copyRecursiveTo(FilePath.java:1450)
> at
> hudson.plugins.copyartifact.FilePathCopyMethod.copyAll(FilePathCopyMethod.java:51)
> at
> hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:225)
> at
> hudson.plugins.copyartifact.CopyArtifact.perform(CopyArtifact.java:199)
> at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
> at
> hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:649)
> at hudson.model.Build$RunnerImpl.build(Build.java:177)
> at hudson.model.Build$RunnerImpl.doRun(Build.java:139)
> at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:423)
> at hudson.model.Run.run(Run.java:1362)
> at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
> at hudson.model.ResourceController.execute(ResourceController.java:88)
> at hudson.model.Executor.run(Executor.java:145)
> Caused by: java.io.IOException: Pipe is already closed
> at
> hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:147)
> at
> hudson.remoting.FastPipedOutputStream.write(FastPipedOutputStream.java:131)
> at
> hudson.remoting.ProxyOutputStream$Chunk$1.run(ProxyOutputStream.java:185)
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
> at java.util.concurrent.FutureTask.run(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: hudson.remoting.FastPipedInputStream$ClosedBy: The pipe was closed
> at...
> at
> hudson.remoting.FastPipedInputStream.close(FastPip
[JIRA] (JENKINS-12839) no help file for "Build current patches only"
rin_ne created JENKINS-12839: Summary: no help file for "Build current patches only" Key: JENKINS-12839 URL: https://issues.jenkins-ci.org/browse/JENKINS-12839 Project: Jenkins Issue Type: Bug Components: gerrit-trigger Reporter: rin_ne Assignee: rsandell Priority: Minor In GerritManagement, help-GerritBuildCurrentPatchesOnly.html is specified as help for "Build current patches only". But it is not found in repository. -- 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-12616) Tests failes but the job is still OK
[ https://issues.jenkins-ci.org/browse/JENKINS-12616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=159326#comment-159326 ] Thomas Fürer commented on JENKINS-12616: it is the same behavior if I set a threshold of Build StatusTotal New Total New Thresholds: 1 1 10 10 I'm using the file attached which has only one failing test. > Tests failes but the job is still OK > > > Key: JENKINS-12616 > URL: https://issues.jenkins-ci.org/browse/JENKINS-12616 > Project: Jenkins > Issue Type: Bug > Components: xunit > Environment: jenkins 1.445 > xunit 1.34 > Ubuntu server 11.11 >Reporter: Thomas Fürer >Assignee: gbois >Priority: Blocker > Attachments: boost-config.PNG, failedButOK.PNG, TEST-failed.xml > > > just use the attached result file with BOOST > the error is listed correct in the test report, but the job is still OK but > need to be at least UNSTABLE. > As you can see in the screenshot I do not have any thresholds set. > I do not have any example at the moment, but I think we have this problem > also with NUnit tests. -- 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
