[
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
repositories?
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
director?
I don't think you need to. An external build can use this link:
http://www.eclipse.org/downloads/download.php?file=/tools/buckminster/products/director_latest.zip&r=1
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
http://download.eclipse.org/tools/buckminster/headless-3.6/
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.
Regards,
Thomas Hallgren
