[JIRA] [core] (JENKINS-33334) Out of the Box: Restart -button is barely visible on 1280 x 800 screen
Title: Message Title Jyrki Puttonen created an issue Jenkins / JENKINS-4 Out of the Box: Restart -button is barely visible on 1280 x 800 screen Issue Type: Bug Assignee: Unassigned Attachments: Screenshot 2016-03-05 06.26.52.png Components: core Created: 05/Mar/16 4:29 AM Labels: 2.0 Priority: Minor Reporter: Jyrki Puttonen After installing Plugins on first run, the "Restart Jenkins" (or something, can't see it right now) is barely visible, see attached screenshot.
[JIRA] [core] (JENKINS-20501) Slave leaving cached jars open
Jyrki Puttonen commented on JENKINS-20501 Slave leaving cached jars open Working fine now. For a day now, "lsof |grep jenkins |grep .jar |wc -l" has been giving same amount of lines when builder is idle. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [core] (JENKINS-20501) Slave leaving cached jars open
Jyrki Puttonen closed JENKINS-20501 as Fixed Slave leaving cached jars open Change By: Jyrki Puttonen (05/Sep/14 3:20 AM) Status: Open Closed Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven] (JENKINS-20429) hudson.model.ResourceList _getConflict Collision with cp-engi(1)=1 and cp-engi(1)
Jyrki Puttonen commented on JENKINS-20429 hudson.model.ResourceList _getConflict Collision with cp-engi(1)=1 and cp-engi(1) that "cp-engi" should give some hint, hard to say where it comes. Does this cause you any problems? When I encountered this and added that logging, the port allocator plugin got deadlocked and prevented jobs from starting. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Jyrki Puttonen commented on JENKINS-18786 Port allocation blocks jobs from executing concurrently Seems to be working properly, thanks a lot! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Jyrki Puttonen commented on JENKINS-18786 Port allocation blocks jobs from executing concurrently Great, I'm able to test this on next Monday, I'll report results then. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Jyrki Puttonen commented on JENKINS-18786 Port allocation blocks jobs from executing concurrently I have three slaves and each of them have multiple executors. There's two different jobs which both allocate a port with name ARQUILLIAN. Both of these jobs have concurrent builds. Now only one build gets executed at a time, leaving other slaves and executors unused. Other builds stay in the queue with text "Blocked by running build". When the running build is completed, next one starts. At some times, multiple builds are assigned to executors, but only one of them is actually running. Others are just waiting with empty consoles. So, answers to your questions: Do the queued builds continue once the build holding the blocked port has completed? Yes, they do Is a build on one slave being blocked because a port is being used on another slave? Yes Do you have a use case where you need all of the slaves to start running but then block during the build? No, I just need one random port assigned to one job. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [port-allocator] (JENKINS-18786) Port allocation blocks all jobs from executing
Jyrki Puttonen created JENKINS-18786 Port allocation blocks all jobs from executing Issue Type: Bug Assignee: ramapulavarthi Components: port-allocator Created: 17/Jul/13 5:01 AM Description: I'm assigning one port in configuration, called Arquillian. When using version 1.6 of port allocator, only one job starts execution and others are blocked by it. Thread dump had following: "Executor #1 for virt-slave1 : executing Project #3464" Id=38 Group=main WAITING on hudson.model.Queue@67a7efcb at java.lang.Object.wait(Native Method) - waiting on hudson.model.Queue@67a7efcb at java.lang.Object.wait(Object.java:503) at hudson.model.ResourceController.execute(ResourceController.java:80) at hudson.model.Executor.run(Executor.java:247) "Executor #5 for virt-slave1 : executing Project #3465" Id=42 Group=main WAITING on hudson.model.Queue@67a7efcb at java.lang.Object.wait(Native Method) - waiting on hudson.model.Queue@67a7efcb at java.lang.Object.wait(Object.java:503) at hudson.model.ResourceController.execute(ResourceController.java:80) at hudson.model.Executor.run(Executor.java:247) "Executor #4 for virt-slave2 : executing Project #3463 / waiting for hudson.remoting.Channel@279eb40d:virt-slave2" Id=48 Group=main TIMED_WAITING on hudson.remoting.UserRequest@20f46461 at java.lang.Object.wait(Native Method) - waiting on hudson.remoting.UserRequest@20f46461 at hudson.remoting.Request.call(Request.java:146) at hudson.remoting.Channel.call(Channel.java:722) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:162) at com.sun.proxy.$Proxy32.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:925) at hudson.Launcher$ProcStarter.join(Launcher.java:360) at hudson.tasks.Maven.perform(Maven.java:327) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:586) at hudson.model.Run.execute(Run.java:1593) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:247) Executor #5 for virt-slave1 : executing Project #3465 "Executor #5 for virt-slave1 : executing Project #3465" Id=42 Group=main WAITING on hudson.model.Queue@67a7efcb at java.lang.Object.wait(Native Method) - waiting on hudson.model.Queue@67a7efcb at java.lang.Object.wait(Object.java:503) at hudson.model.ResourceController.execute(ResourceController.java:80) at hudson.model.Executor.run(Executor.java:247) After adding https://github.com/jenkinsci/jenkins/pull/853, log got following lines: Jul 17, 2013 7:23:45 AM hudson.model.ResourceList _getConflict INFO: Collision with standalone port ARQUILLIAN(1)=1 and standalone port ARQUILLIAN(1) Downgrading to version 1.5 of port allocator solved the problem Environment: Jenkins .1523, port-allocator 1.6 Project: Jenkins Priority: Blocker Reporter: Jyrki Puttonen This message is automatically generated by JIRA. If you think it was sent
[JIRA] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Jyrki Puttonen updated JENKINS-18786 Port allocation blocks jobs from executing concurrently Change By: Jyrki Puttonen (17/Jul/13 5:13 AM) Summary: Portallocationblocks all jobsfromexecuting concurrently Environment: Jenkins 1 . 1523 523 ,port-allocator1.6 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [concurrent-build] (JENKINS-13810) Maven modules marked to wrong build when running concurrent job
Jyrki Puttonen commented on JENKINS-13810 Maven modules marked to wrong build when running concurrent job I've changed to freestyle project with Maven buildsteps at the end of February, and this was valid then. Jenkins version was 1.502. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15439) Jenkins build records lazy-loading failed to load some of my jobs.
Jyrki Puttonen commented on JENKINS-15439 Jenkins build records lazy-loading failed to load some of my jobs. Tried jenkins_main_trunk #1982, got following errors in log Oct 10, 2012 6:53:19 AM jenkins.model.lazy.AbstractLazyLoadRunMap search WARNING: Assertion error: failing to load #2147483647 DESC: lo=101,hi=201,pivot=151,size=200 (initial:lo=0,hi=201) java.lang.Exception at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:414) at jenkins.model.lazy.AbstractLazyLoadRunMap.newestBuild(AbstractLazyLoadRunMap.java:293) at hudson.model.AbstractProject.getLastBuild(AbstractProject.java:998) at hudson.maven.AbstractMavenProject.createTransientActions(AbstractMavenProject.java:184) at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:665) at hudson.maven.MavenModule.updateTransientActions(MavenModule.java:411) at hudson.model.AbstractProject.onLoad(AbstractProject.java:299) at hudson.maven.MavenModule.onLoad(MavenModule.java:236) at hudson.model.Items.load(Items.java:221) at hudson.model.ItemGroupMixIn.loadChildren(ItemGroupMixIn.java:99) at hudson.maven.MavenModuleSet.onLoad(MavenModuleSet.java:669) at hudson.model.Items.load(Items.java:221) at jenkins.model.Jenkins$17.run(Jenkins.java:2507) 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$7.runTask(Jenkins.java:883) 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.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Oct 10, 2012 6:53:19 AM jenkins.InitReactorRunner$1 onTaskFailed SEVERE: Failed Loading job ProjectX_Analysis java.lang.ArrayIndexOutOfBoundsException: Assertion error: failing to load #2147483647 DESC: lo=101,hi=201,pivot=151,size=200 (initial:lo=0,hi=201) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:415) at jenkins.model.lazy.AbstractLazyLoadRunMap.newestBuild(AbstractLazyLoadRunMap.java:293) at hudson.model.AbstractProject.getLastBuild(AbstractProject.java:998) at hudson.maven.AbstractMavenProject.createTransientActions(AbstractMavenProject.java:184) at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:665) at hudson.maven.MavenModule.updateTransientActions(MavenModule.java:411) at hudson.model.AbstractProject.onLoad(AbstractProject.java:299) at hudson.maven.MavenModule.onLoad(MavenModule.java:236) at hudson.model.Items.load(Items.java:221) at hudson.model.ItemGroupMixIn.loadChildren(ItemGroupMixIn.java:99) at hudson.maven.MavenModuleSet.onLoad(MavenModuleSet.java:669) at hudson.model.Items.load(Items.java:221) at jenkins.model.Jenkins$17.run(Jenkins.java:2507) 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$7.runTask(Jenkins.java:883) 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.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15439) Jenkins build records lazy-loading failed to load some of my jobs.
Jyrki Puttonen commented on JENKINS-15439 Jenkins build records lazy-loading failed to load some of my jobs. I got something similar, exception below. This job didn't have any triggers as it is launched by another job. I managed to get this one to load by adding SCM trigger manually into config.xml. SEVERE: Failed Loading job jobX java.util.NoSuchElementException at java.util.AbstractList$Itr.next(AbstractList.java:364) at jenkins.model.lazy.AbstractLazyLoadRunMap.all(AbstractLazyLoadRunMap.java:537) at jenkins.model.lazy.AbstractLazyLoadRunMap.entrySet(AbstractLazyLoadRunMap.java:230) at java.util.AbstractMap$2$1.init(AbstractMap.java:378) at java.util.AbstractMap$2.iterator(AbstractMap.java:377) at hudson.util.RunList.iterator(RunList.java:102) at org.jvnet.hudson.plugins.DownStreamProjectActionFactory.createFor(DownStreamProjectActionFactory.java:59) at hudson.model.AbstractProject.createTransientActions(AbstractProject.java:675) at hudson.maven.AbstractMavenProject.createTransientActions(AbstractMavenProject.java:177) at hudson.model.AbstractProject.updateTransientActions(AbstractProject.java:665) at hudson.maven.MavenModule.updateTransientActions(MavenModule.java:411) at hudson.model.AbstractProject.onLoad(AbstractProject.java:299) at hudson.maven.MavenModule.onLoad(MavenModule.java:236) at hudson.model.Items.load(Items.java:221) at hudson.model.ItemGroupMixIn.loadChildren(ItemGroupMixIn.java:99) at hudson.maven.MavenModuleSet.onLoad(MavenModuleSet.java:669) at hudson.model.Items.load(Items.java:221) at jenkins.model.Jenkins$17.run(Jenkins.java:2507) 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$7.runTask(Jenkins.java:883) 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.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13810) Maven modules marked to wrong build when running concurrent job
[
https://issues.jenkins-ci.org/browse/JENKINS-13810?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jyrki Puttonen updated JENKINS-13810:
-
Description:
I have a Maven project build with one module, named jenkins-test. This module
contains one test, which fails everytime (assertTrue(false) :)). There is a
problem when this project is executed with Execute concurrent builds if
necessary turned on and when multiple jobs are started at same time. Multiple
builds start and finish, but some of these jobs are completed succesfully and
some are marked as failed. What I see in the build status page is something
like this:
{quote}
(Success) Build #180 (May 12, 2012 8:17:09 PM)
...
Module Builds
jenkins-test (didn't run)
{quote}
{quote}
(Success) Build #181 (May 12, 2012 8:17:12 PM)
...
Module Builds
(disabled) jenkins-test (didn't run)
{quote}
{quote}
(Unstable) Build #182 (May 12, 2012 8:17:19 PM)
...
Module Builds
jenkins-test (Unstable) #182 (Unstable) #183 (Unstable) #184
{quote}
Logs show that the builds were executed properly (commit ids are right, and
[ERROR] There are test failures. is there). The next build then gets build
number #187.
In my setup I'm using Gerrit and Gerrit Trigger to launch jobs, so when I push
multiple commits into Gerrit in one push, Jenkins starts multiple jobs at same
time. I don't know if you can duplicate this behavior without Gerrit, though.
Currently MavenModule and MavenModuleSet have their own build numbers, which
are increment when a new module is built. These might get mixed up when
multiple builds are executed concurrently. Multiple MavenModuletSets are built
starting at the same time, and some how the numbering of MavenModules gets out
of sync.
The commit in
https://github.com/jyrkiput/jenkins/commit/0d076e610b39b215ed34c35a5d4840e56183d5e4
fixes this, but I haven't tested it other cases than mine and I don't think
that I'm qualified to change something that is this deeply on the jenkins core
:) The commit probably has some unnecessary bits in it too at the moment. So I
don't think that it should be merged :)
was:
I have a Maven project build with one module, named jenkins-test. This module
contains one test, which fails everytime (assertTrue(false) :)). There is a
problem when this project is executed with Execute concurrent builds if
necessary turned on and when multiple jobs are started at same time. Multiple
builds start and finish, but some of these jobs are completed succesfully and
some are marked as failed. What I see in the build status page is something
like this:
(Success) Build #180 (May 12, 2012 8:17:09 PM)
...
Module Builds
jenkins-test (didn't run)
(Success) Build #181 (May 12, 2012 8:17:12 PM)
...
Module Builds
(disabled) jenkins-test (didn't run)
(Unstable) Build #182 (May 12, 2012 8:17:19 PM)
...
Module Builds
jenkins-test (Unstable) #182 (Unstable) #183 (Unstable) #184
Logs show that the builds were executed properly (commit ids are right, and
[ERROR] There are test failures. is there). The next build then gets build
number #187.
In my setup I'm using Gerrit and Gerrit Trigger to launch jobs, so when I push
multiple commits into Gerrit in one push, Jenkins starts multiple jobs at same
time. I don't know if you can duplicate this behavior without Gerrit, though.
Currently MavenModule and MavenModuleSet have their own build numbers, which
are increment when a new module is built. These might get mixed up when
multiple builds are executed concurrently. Multiple MavenModuletSets are built
starting at the same time, and some how the numbering of MavenModules gets out
of sync.
The commit in
https://github.com/jyrkiput/jenkins/commit/0d076e610b39b215ed34c35a5d4840e56183d5e4
fixes this, but I haven't tested it other cases than mine and I don't think
that I'm qualified to change something that is this deeply on the jenkins core
:) The commit probably has some unnecessary bits in it too at the moment. So I
don't think that it should be merged :)
Maven modules marked to wrong build when running concurrent job
---
Key: JENKINS-13810
URL: https://issues.jenkins-ci.org/browse/JENKINS-13810
Project: Jenkins
Issue Type: Bug
Components: concurrent-build, maven
Reporter: Jyrki Puttonen
Assignee: Kohsuke Kawaguchi
I have a Maven project build with one module, named jenkins-test. This module
contains one test, which fails everytime (assertTrue(false) :)). There is a
problem when this project is executed with Execute concurrent builds if
necessary turned on and when multiple jobs are started at same time.
Multiple builds start and finish, but some of these jobs are completed
succesfully and some are marked as failed. What I see in the build status
page is something like this:
[JIRA] (JENKINS-13810) Maven modules marked to wrong build when running concurrent job
Jyrki Puttonen created JENKINS-13810: Summary: Maven modules marked to wrong build when running concurrent job Key: JENKINS-13810 URL: https://issues.jenkins-ci.org/browse/JENKINS-13810 Project: Jenkins Issue Type: Bug Components: concurrent-build, maven Reporter: Jyrki Puttonen Assignee: Kohsuke Kawaguchi I have a Maven project build with one module, named jenkins-test. This module contains one test, which fails everytime (assertTrue(false) :)). There is a problem when this project is executed with Execute concurrent builds if necessary turned on and when multiple jobs are started at same time. Multiple builds start and finish, but some of these jobs are completed succesfully and some are marked as failed. What I see in the build status page is something like this: (Success) Build #180 (May 12, 2012 8:17:09 PM) ... Module Builds jenkins-test (didn't run) (Success) Build #181 (May 12, 2012 8:17:12 PM) ... Module Builds (disabled) jenkins-test (didn't run) (Unstable) Build #182 (May 12, 2012 8:17:19 PM) ... Module Builds jenkins-test (Unstable) #182 (Unstable) #183 (Unstable) #184 Logs show that the builds were executed properly (commit ids are right, and [ERROR] There are test failures. is there). The next build then gets build number #187. In my setup I'm using Gerrit and Gerrit Trigger to launch jobs, so when I push multiple commits into Gerrit in one push, Jenkins starts multiple jobs at same time. I don't know if you can duplicate this behavior without Gerrit, though. Currently MavenModule and MavenModuleSet have their own build numbers, which are increment when a new module is built. These might get mixed up when multiple builds are executed concurrently. Multiple MavenModuletSets are built starting at the same time, and some how the numbering of MavenModules gets out of sync. The commit in https://github.com/jyrkiput/jenkins/commit/0d076e610b39b215ed34c35a5d4840e56183d5e4 fixes this, but I haven't tested it other cases than mine and I don't think that I'm qualified to change something that is this deeply on the jenkins core :) The commit probably has some unnecessary bits in it too at the moment. So I don't think that it should be merged :) -- 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
