Re: [mdt-ocl.dev] Releng - Updated Status Report

[Kenn Hussey <kenn.hussey@xxxxxxxxx>]

I just downloaded and inspected the integration build and can verify that the changes for 331143 made it into the build.

Kenn

On Fri, Dec 10, 2010 at 11:02 AM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi Adolfo

- Firstly, announce that the last succesfull build correspond to an Integration build which containts the OCL-based implementation of the new (M4) EMF Query Delegation feature.
zips: http://www.eclipse.org/modeling/mdt/downloads/?project=ocl
p2 repository: http://download.eclipse.org/modeling/mdt/ocl/updates/interim/3.1.0/

Are you sure it's successful?

https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/changes

shows no sign of the commit for Bug 331143.

- Secondly, We finally have some automated publishing (promotion) scripts.

Fantastic.

The policy I've established is the following (let me know if this sound good to you):

- Our nightly buckminster job will be executed every day at 3:00 am (servers time zone).
- I've defined a personal cron entry which will publish the last succesful night build at 3:30 am (servers time zone).

This is very tight. The builds have taken 45 minutes on the old server, and don't always start immediately.

I suggest a degenerate promote job triggered by the successful build, or just auto-promote. No. Why have a second job to auto-promote wrong, when the first could at least auto-promote consistently?

If we promote daily we will need to purge N-builds automatically.

I'm currently working on some documentation in our wiki to at least explain how to run a  build and publish the resulting artifacts

My next step is learning how to deal with composite repositories, with two objetives in mind:

- Our current ant-based publishing script doesn't create composite p2 repositories, so that the last successful build will overwrite the last published p2 repository. It could be ideally that at least for Stable, Release and Maintenance builds the resulting p2 repository were published in a composite repository (in updates/milestones, updates/releases and updates/maintenance, correspondently).
- Kenn, explained me that EMF (core)  is currently using a composite p2 repository to distinct between "base" p2 repository, which contains some basic EMF functionality to be consumed by e4, and "core" p2 repository which contains all the EMF core functionality. I think that we will require something similar to distinct between our MDT/OCL "core" and "tools" builds.

Good luck. Seems like fun...

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