[
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 answers inside:
Thomas Hallgren schrieb:
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.
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.
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)?
If you don't activate 'auto installation' you specify a home directory
of your tool and give the Tool Installation a name. Tool Installations
are always identified by name.
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.
2. The tool installation has not been installed by the custom installer
which means the installer logic has no chance to run an update.
So I guess the update logic should be placed in the build step, and not
in the installer to make it work no matter how buckminster has been
installed.
Unfortunately I don't see a way to find out what's currently installed
and therefore I don't know which features need updating.
What about an 'update' command for buckminster? How hard would that be
to implement?
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.
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)
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.
true, thank you
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?
I got a little curious when I noticed that the Hudson JDK Installer
requires the user to accept SUN's licence agreement. You are right, this
is most likely unnecessary, so I don't do anything like that.
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.
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
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?
Best regards,
Johannes
