[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [mdt-ocl.dev] Releng - Updated Status Report
|
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