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

Hi Johannes,

On 03/21/2010 04:14 PM, Johannes Utzig wrote:
I'm uncertain what this means. What other installers can install
Buckminster? Can you please elaborate?

Hudson offers two generic installers: 1. Execute a shell script (pseudocode) This can perfectly fine install buckminster. wget director extract director director create buckminster product buckminster install features

2.Download and extract an archive
An admin can prepare a prepackaged custom buckminster, deploy it on some
webserver and have the generic download installer extract that archive
on the build machine as needed.

OK, clear.

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?

Currently 4 possibilities: 1. manually specify a path to a custom buckminster installation 2. use the generic script based installer 3. use the generic download installer 4. create a 'configure buckminster' build job that doesn't really build anything, but executes 'install' commands

It would also be possible I guess to add additional features +
repositories in the configuration of the custom installer, but I wasn't
able to do that just yet with the jelly script.

I think the four possibilities covers this :-) No need to dig deeper unless there's a real demand for it.

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

I was thinking about that too. There's two different scenarios: 1. The user activated the auto tool installation In this case the tool installer would have a chance to perform an update but that might be too expensive to do for every build run.

I agree. This should only happen when explicitly requested (vouches for better build stability).

What about an 'update' command for buckminster? How hard would that be
to implement?

What's needed is an 'update' command for the director I think. IIRC, there is a p2 bugzilla for that.

For now, I'm happy if the admin can just clean out what's current and reinstall.

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.

I'm afraid this is not so easy. This information needs to be available as soon as the manage hudson site is requested. Waiting for a server reply would cause the site to hang if the server is not available for some reason. As far as I understand the mechanics so far, this is avoided in hudson by downloading the update files up front, store them locally and update them once a day, or so. I don't see a way how it would be possible to have the user enter a different URL and process that at runtime, because I don't think it's possible to update the web form once it has been created.

That said, a workaround of some sort should be possible of course.
The installer could for example look for a custom.json at a specific
place in the hudson dir, or look for a system property, or something
like that. If present, it overrides the remote file.

Yes, this was what I was thinking too. Something simple that can override. Doesn't need to be exposed in the UI.

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.

I tried that, but it doesn't work. Looks like the redirect is causing problems for the download logic (which is provided by Hudson)

OK, perhaps it does something with the parameters of the URL. In any case, I think it must be OK to download using a direct URL. The director is relatively small and this is not something that will happen on every run.

I can't really list the site features at the moment.

buckminser listsite

gives me this (latest buckminster 3.6 headless):

java.lang.IllegalArgumentException: Cannot find a public member 'id' in
a org.eclipse.equinox.internal.p2.metadata.expression.Everything

Ouch! Would appreciate a bugzilla on that.

So every feature from eclipe.org und subclipse (no subversive) from
cloudsmith, right? What about the emma feature, or is that available
from the eclipse.org site?

Yes, nowadays emma is also included from Eclipse.

Thomas Hallgren