[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [buckminster-dev] Hudson plugin and provisioning
- From: Thomas Hallgren <thomas@xxxxxxx>
- Date: Thu, 26 Aug 2010 22:49:48 -0000
- Newsgroups: eclipse.tools.buckminster-dev
- Organization: EclipseCorner
- User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b1 Thunderbird/3.0.3
This looks great! I have a few questions/suggestions inline.
On 03/21/2010 11:59 AM, Johannes Utzig wrote:
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
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
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
//the repository URL
"features":[ //a list of features to install from this repo
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?
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
5. I need some help writing the final JSON file with the version/feature
informations. What should be included in which version?