[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Hudson plugin and provisioning
|
On 03/15/2010 04:09 PM, Johannes Utzig wrote:
Hi,
sorry, I check my inbox before I checked the newsgroup, so I sent my
answer directly to your mail address instead of to the newsgroup...
So here's a copy of the mail I sent you earlier for everyone to read:
Hi Thomas,
this is actually something I was already thinking about myself.
Hudson has a thing called a 'Tool Installation' which is a generic
description of any kind of build tool that a build can depend on.
That includes things like ANT, Maven, JDK,...
For some Tools there is an automatic tool installation available which
usually means download something from somewhere and install it.
Having the same thing for Buckminster would have several advantages:
-Easier to configure for the user
-Easy to update/upgrade buckminster
-And most of all, this would enable master/slave scenarios. If a build
is executed on a slave machine and relies on a tool that has an
automatic installation available, it can check if this tool is already
installed and install it on the fly if necessary. This is a great
feature if you have something like a build cloud where new slaves get
added on demand.
So in my opinion it would be better to participate in the logic provided
by hudson instead of doing it plugin-internal during the build run. What
is your opinion on that?
As for the 'how', does this sound ok to you? :
Sounds good. Better to reuse as much as possible and be good Hudson citizens then inventing new stuff.
> How would this sound to you:
> In configure Hudson you have 3 options:
> 1. enter a location to a buckminster installation (that's how it works
> currently)
>
This has it's drawbacks. The client is required to install a Buckminster first. And this installation must be on the
same platform where the build is supposed to run. In case you have one Hudson manager that sets things up, and then
clients that configures their builds, this is good though. Hides the complexity from the end user.
> 2. pick a version and install a default buckminster automatically (pretty
> much all the features on the headless update site I would say)
>
I like this. Question is how the builder would now what versions that are available. Perhaps we could put up a file of
some sort at http://download.eclipse.org/tools/buckminster/, i.e. the parent folder of our update sites where we list
the versions and their respective feature sets. That way, the Hudson plugin wouldn't need to hard wire the sites and
features, and it would give us freedom to move things around.
> 3. provide a list of update sites and features to be installed
>
>
Something like this is needed when a client provides their own extensions to Buckminster. Perhaps this can be additional
info provided for case #2?
- thomas
