Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-ocl.dev] Build Funnies

El 09/02/2011 17:08, Ed Willink escribió:
Hi Adolfo

I started build 221 to pick up my commits that make Complete OCL editor useable.

Hudson shows no sign of these CVS changes.

Build 221 got stuck on a final 'mv'. Maybe a diskspace issue.

Build 222 got stuck even earlier; maybe a hudson slave 1 issue.

Three funnies!

Yeap. I've been trying to find a proper machine on which make our builds run.  I guess it's a server problem since there are a lot of jobs trying to build. Let's see what happens tomorrow...

Also we should set a timeout at twice normal running to avoid hogging a slot.
I did that this morning.

BTW, Now that M6 has started I want to do some experiments concerning Core + Tools jobs, so that in +1 time frame we only create Core artifacts and in +3 time frame we create Tools (currently examples) artifacts.

However, I have a couple of questions/doubts (ideas :D )  which may need consideration, specially when publishing artifacts:

1. Separating Core from Tools. The idea is the following:

In principle, every repository (nightly, interim, milestones, etc) would be a composite repository which composes a "CORE" repository and "TOOLS" repository. The CORE repository would contain what we know as OCL SDK [1] which will be generated by a first build. The TOOLS repository would contain the Examples feature, which will be generated by a second build. Therefore the Eclipse Release Train would be feeded by the correspodent repository (i.e milestones repository for M1, M2, M3, etc) so that it may  find both the OCL SDK and the OCL Examples features via the composite repository.

2. Creating incremental builds. The idea is the following:

In principle, every repository works as it has been wornking so far. In a first build (+1) only OCL SDK is built. In a second build (+3) OCL All-in-one (OCL SDK + Examples [1]) is built so that the content of the generated repository will replace the content from the first build.

In both cases I'll have to manage to create downloadable zips from the downloads web page. The only difference is that "Core" builds won't provide downloadable examples zips. We will probably proper need a build alias when creating milestones and release candidates. Some ideas:

a) 3.1.0M6 (in +1) and 3.1.0M6a (in +3).
b) 3.1.0M6-Core (in +1) and 3.1.0M6-Tools (in +3).

It looks like the idea 2 could be done quicker, and probably without any undesirable surprise (For instance, when trying the idea 1,  I'm not sure If I'll be able to produce all the expected downloadable zips: Update, SDK, Core SDK, etc If I only want to generate a p2 repository with the examples).

Finally another idea to consider is using "OCL Core SDK" instead of the "OCL SDK" to use in the build scheduled at +1. It's lighter and it's only what downstream projects need. In +3 everybody will have the remaining stuff available...

[1] http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Features_Organization

Best Regards,
Adolfo.

    Regards

        Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev


--
Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
adolfosbh(at)opencanarias(dot)com
C/Elías Ramos González, 4, ofc. 304
38001 SANTA CRUZ DE TENERIFE
Tel.: +34 922 240231

Back to the top