That's not normal. It would be good to know which
part of the build is taking longer.
Denis
On 09/23/2010 02:03 PM, Trip Gilman wrote:
Meant to send this to the whole list.
It appears that the build did finally finish, though the
overall build time on slave 2 is about 2X longer than on the
master. If this is normal I’ll just update our docs with the
expected time and continue on.
Trip
------ Forwarded Message
From: Terran Gilman <trip@xxxxxxxxxxxxxxx>
Date: Thu, 23 Sep 2010 11:36:35 -0500
To: David Carver <d_a_carver@xxxxxxxxx>
Conversation: [cross-project-issues-dev] Hudson users:
Please attach your builds to slaves
Subject: Re: [cross-project-issues-dev] Hudson users:
Please attach your builds to slaves
I’ll do that. Also, it appears that the
buckminster-voicetools-nightly job continues to hang at the
materialization stage each time. Even with the debug setting
there are no errors listed, just silence at some point. Maybe
I’m doing something wrong with my configuration now that I’m
on slave 2?
Trip
On 9/23/10 11:16 AM, "David Carver" <d_a_carver@xxxxxxxxx>
wrote:
Trip, best thing to do in this
case is open a bug and ask for it to be configured
appropriately for Buckminster.
Dave
On 09/23/2010 08:38 AM, Trip Gilman wrote:
Re: [cross-project-issues-dev]
Hudson users: Please attach your builds to slaves We can
actually get rid of my job dependencies completely if the
standard platform packages (rcp/classic/etc) were made
available through the buckminster hudson plugin target
platform mechanism. What we are doing right now is
grabbing a subset of this platform and creating a faux
platform for our other jobs to build against. If I could
just select the proper target (version/package) directly,
I could run my real build jobs as floating on any
available node. Thoughts?
Trip
On 9/23/10 10:20 AM, "David Carver" <d_a_carver@xxxxxxxxx>
wrote:
What Hudson will do, is use
the first available Node for the build. Subsequent
builds will always try to use the same Node if it is
available, if not, it will then go to one of the other
Slave machines. You can also select to Tie the build
to only run on Slave machines (i.e. Nodes with labels
like Linux, Windows, etc). Then it will try and use one
of those nodes for a build. If your build was tied to
master before, uncheck that option, or choose one of the
other slave machines. It'll help all the other
projects as well.
Dave
On 09/23/2010 07:36 AM, Denis Roy wrote:
Let me try that again:
The "?" icon next to the option says:
Sometimes
a project can only be successfully built on a
particular slave (or master). If so, this option
forces Hudson to always build this project on a
specific computer. If there is a group of machines
that the job can be built on, you can specify that
label as the node to tie on, which will cause Hudson
to build the project on any of the machines with that
label.
Otherwise, uncheck the box so that Hudson can
schedule builds on available nodes, which results in
faster turn-around time.
This option is also useful when you'd like to make
sure that a project can be built on a particular node.
So my guess is "yes" your best bet is to leave it
unchecked.
Denis
On 09/23/2010 10:19 AM, Stéphane Bouchet wrote:
Hi,
what if we just untick the "Tie this project to a
node" option ? will hudson choose automatically the
best node ?
Le 23/09/2010 16:04, Denis Roy a écrit :
Folks,
Please configure your jobs to use the Hudson
Slave instances. We've
allocated more memory and CPU resources to the
slave than to the master,
since we were recommended to use the master
primarily as a Hudson
control device.
Right now the master is running 4 concurrent
jobs (out of 4) while both
slaves are perfectly idle.
To make the change, simply log into
hudson.eclipse.org and on your job,
click "Tie this project to a node" and select
one of the slaves.
Thanks a bunch,
Denis
--
Eclipse Summit Europe, Nov 2-4
http://www.eclipsecon.org/summiteurope2010/
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
------ End of Forwarded Message
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|