Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [buckminster-dev] Hudson plugin and provisioning 
Hi Thomas,

please see comments inline.



 > 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.
It's an option I think we will always need. I would expect many company environments don't want their build infrastructure to automatically download things from the internet, they might not even be connected to the internet, so the 'manual way' should always be an option. 


 > 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.
That sounds really good to me. Much better than hard wire it into the code. Because if I hard wire this information I would have to release a new version every time there is a new buckminster version or feature... 


 > 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?
Yeah, that's what I thought too, you need it if you extended buckminster or if you want to install from a intranet mirror instead of the buckminster update site. I guess you are right, 2. and 3. can be merged. In 2. you simply select the version (3.5 or 3.6 could be default) and that's all you need to do. Then there could be an 'advanced' button that reveals the exact installation details (download URL for the director, update sites and features to be installed). That way the user would be free to edit this information however (s)he wants. 
But first I need to see if this is even possible with jelly script.
If not, I'll do it with 3 alternatives instead of 2.
Once I figured out how to make this work in hudson, we can discuss the details on the file format that defines the versions and lists the features. I'll get back to you once I have an inital working implementation I would say.
This feature will be very handy for a hudson cluster environment, but I have only one hudson server available for testing. It would be greatly appreciated if anybody that runs a hudson cluster is interested in such a feature and would be willing to test automatic tool installation in a master/slave scenario with a pre-released version the plugin... 

Best regards,
Johannes

Back to the top