[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[buckminster-dev] Re: Tutorial for building an RCP from hudson
|
Hi Thomas,
more comments inline
Thomas Hallgren schrieb:
Hi Achim and Johannes,
Achim Demelt wrote:
Johannes,
I totally agree that the best strategy for integration builds is to
have the CI server checkout/update the source. Buckminster can
populate the workspace using a local resolver. This is much faster
than having Buckminster perform the checkout.
While it might be faster and give some advantages for the Hudson user,
it also has serious implications:
1. The Hudson build is no longer the same build as you would run locally
(reproducibility is key).
Well, it is, as long as the target platform is the same. Doesn't matter
who checks something out, as long as it is the same thing that's checked
out.
2. You no longer maintain the data about the SCM's in one place (the
build model is scattered).
My rmap contains both the local resolver and the SCM resolver actually.
A new developer resolves the query to populate the workspace from SCM
and once that's set up, just invokes the action which will act in
exactly the same way as it does in the CI environment.
3. You cannot control the resolution/materialization with a CQUERY.
A cquery is involved and maintains what's getting resolved. The only
thing that's controled by the CI system is the availablity of certain
artifacts
4. The list of material to check-out will be static.
Not necessarily static. I'd say it is a very common scenario that all
the bundles involved in a specific build job reside in one common module
in the SCM. In the hudson job you check out that parent module and let
buckminster resolve whatever other artifacts are necessary and allowed.
You add a new bundle to the scm -> the checkout job will get it, throw
it into the hudson workspace, buckminster will resolve try to resolve
the query again, notices a new dependency and tries to pick it up.
Using Hudson to check out is perhaps faster but remember that the reason
it takes a bit longer when Buckminster does it is that Buckminster
doesn't maintain a list of things to check out. The list is computed
dynamically. AFAIK, Hudson is not capable of doing that. This feature is
of some importance since the developer that adds a bundle to a feature
might have insufficient privileges to change the Hudson configuration.
See above, most of the time you'll just check out the parent module, and
even if that's more than you actually need, buckminster won't even see
the additional artifacts.
Having said that, I see the point in the example showing SVN checkout
instead of local resolution. Maybe we can have _both_ resolvers in the
RMAP and select the appropriate one using a resolutionFilter? It would
default to SVN checkout, but in the presence of a "integrationBuild"
property, the RMAP could then select the local resolver.
That's better, but you still need to maintain a static list and you
still have issues with permissions.
I would much rather see a solution where Hudson can actually benefit
from what Buckminster finds. Which makes me curious, what does Hudson
need in terms of functionality in order to maintain its workspace +
changelog? Perhaps it's not that hard to accomplish.
I'd really be interested in that option.
It should be possible since AFAIK it is the SCM plugin's responsibility
to fill the hudson workspace with content and hudson shouldn't care at
all how that happens and where everything comes from.
The thing really is: how to make buckminster behave well as a 'meta scm'
for hudson? How to force an update on every build, how to retrieve the
commit logs? If you show me the way , I'll do my best to implement the
dirty little details.
I'd like to bring up another point for a _really_ comprehensive
example: target platform. I am a strong proponent for defining a
target platform up front that everybody, i.e. all developers and the
integration build, compile against. So the first step in a build
process would be to populate the target platform. We're currently
using Buckminster to do this, although I really like PDE's new target
platform story. At the moment, though, it can only deal with exact
bundle versions, which is not really what I want. A combination of
Buckminster and PDE would be great. Maybe we can hook Buckminster into
PDE as a target platform source. I'll investigate that...
IMO, Buckminster now has an even better way to populate the target
platform. Simply use the eclipse.import reader and the p2 materializer.
The advantage is that the provisioning that takes place when you do it
that way can be platform independent and very exact (based on the
resolution). The target platform provision mechanism provided with PDE
will use the planner when installing from a remote repository. The
planner is unfortunately always bound to a particular platform
configuration. The PDE provider must also be told explicitly what
features to include from the repository.
Also, Buckminster will provision the target platform in parallel with
the SCM checkouts. How's that for speed ;-)
Regards,
Thomas Hallgren
Best regards,
Johannes
