[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [buckminster-dev] Hudson plugin and provisioning

Hi Johannes,
This looks great! I have a few questions/suggestions inline.

On 03/21/2010 11:59 AM, Johannes Utzig wrote:
Hi again,

it actually works like a charm now :)
Here's the current workflow, please let me know what you think about it:

1. The administrator opens the configure hudson page
2. He presses 'Add Buckminster' In the Buckminster section
3. He enters a name for the tool installation (that will be shown in the
job configuration)
4. By default 'Install Automatically' is checked and the default
'Install from Eclipse.org/Cloudsmith.com' installer is checked
5. He selects a version (the versions are fed from a json file on
6. He can also remove this installer or add other installers (execute
shell script/ download and extract from URL)

I'm uncertain what this means. What other installers can install Buckminster? Can you please elaborate?

7. If install automatically gets unchecked, the installer section
disappears and gets replaced with a textfield to enter the buckminster
home location (this is how it's done in the current buckminster plugin)

How do we cover the case where the admin wants to install a custom feature from some other repository?

8. In a job configuration the build manager can choose between all known
buckminster tool installations

How is a known tool installation identified? Is this the same as the "versions" in #5 or can custom installations be created (and named)?

9. If the "Install from Eclipse.org/Cloudsmith.com" installer was
selected and the job is started, the installer checks if buckminster is
already installed on this machine. If not:
-it downloads and extracts the p2 director from the URL in the JSON file
-it invokes the p2 installer with the URL and IU given in the JSON file
to provision a buckminster headless product
-it iterates over all repositories listed in the JSON file and installs
all features associated with them.

What happens when new versions of the features arrive in the appointed repositories?

In the console output of the job the result looks like this:

to /home/joe/workspaceHudson2/buckminster/work/tools/Buckminster_3.5 on
[buckminster] $ sh -e

Installing org.eclipse.buckminster.cmdline.product 1.1.350.r11146.
Operation completed in 13049 ms.
Installed Feature org.eclipse.buckminster.core.headless.feature from
Installed Feature org.eclipse.buckminster.cvs.headless.feature from
Installed Feature org.eclipse.buckminster.pde.headless.feature from
Installed Feature org.eclipse.buckminster.maven.feature from
Installed Feature org.eclipse.buckminster.subversive.headless.feature
from http://download.cloudsmith.com/buckminster/external/

The JSON File consists of an array of Buckminster Installables with the
following contents (shortened):

"id":"3.5", //the unique ID of the installable
"name":"Buckminster 3.5", //the human readable name that will be shown
in the version selection
//the URL of the director application
"iu":"org.eclipse.buckminster.cmdline.product"; //which IU to install
//where to find the headless product
"repositories":[ //a list of repositories where to install features from
{ "url":"http://download.eclipse.org/tools/buckminster/headless-3.5/";,
//the repository URL
"features":[ //a list of features to install from this repo
{ "id":"org.eclipse.buckminster.core.headless.feature"},
{ "id":"org.eclipse.buckminster.cvs.headless.feature"}...

I'm almost ready to release this but there are a few questions remaining that I need answered first:

1. Is the approach ok with you or should I change something?

I think it would be great if we could use an alternative json file for specific hudson instances. On build.eclipse.org for instance, all URL's pointing to http://download.eclipse.org/ can be replaced with file:/home/data/httpd/download.eclipse.org/, a change that removes a lot of load from the web server. That applies both to the director download and the actual install.

2. Is it ok to use the direct download link from eclipse.org for the p2

I don't think you need to. An external build can use this link:


Note the r=1 parameter at the end. It causes a bypass of the selection page so the download is immediate. The closest geographical mirror is chosen.

3. Is it ok to automatically download additional features from
cloudsmith or should I restrict to eclipse.org?

It must be OK. This is about tooling for our build environment and not about what we publish at Eclipse.org.

4. Do I need to have the user accept some kind of licence agreement for
features (like subversive, or so)?

Quite frankly, I have no idea who agrees to what licenses on what tools in our build environment. Who agreed to use Linux, Java, Hudson, Ant, Maven, CVS, SVN, Git, the Buckminster plug-in, etc.? I guess this must fall into the same category. It somehow feels that it's the admins responsibility and that he implicitly accepts the licenses of the stuff that is put to use. But as I said, I really have no idea.

What happens when you install a new Hudson plug-in? Do you have to accept its license and all licenses that it depends on at that point?

5. I need some help writing the final JSON file with the version/feature
informations. What should be included in which version?

The latest on our headless-3.5 and headless-3.6 update sites + the latest Subclipse at cloudsmith external-3.5 and external-3.6. We might want to switch to Subversive at some point but at present they have some bugzillas that need attending first.

- thomas