Ed,
Comments in-line below
El 10/12/2010 16:02, Ed Willink escribió:
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.
Sure, already confirmed by Kenn.
I believe I had something bad configured in the hudson's job. Since
I only needed the org.eclipse.ocl/releng stuff I hadn't configured
the job to download all org.eclipse.ocl from CVS. That may be the
reason why hudson didn't notice the change. This morning I changed
that so that now it downloads into the workspace all CVS
org.eclipse.ocl. Hopefully, changes in the source code will be now
detected by hudson.
- 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.
As you may check in our last build, now it only lasts around 15
minutes (https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/146/).
I think that launching the publishing script 30 minutes later should
suffice
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?
I'm not sure about what you mean by "auto-promote". Maybe It means
that I should execute the ant-script always after the build
finishes.... It could be good for nightly executions, but at this
moment is not good for S, R or M builds.
If we promote daily we will need to purge N-builds automatically.
Yes that's a good point which is not solved. The p2 repository is
currently overwritten but the zips are proliferating as long as the
builds are run and published. Anyway, since I'll probably use
different scripts when adopting composite repositories, I won't
spend time on this for the moment.
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...
I changed my mind. Helios SR2 RC will come before Inidigo's M5, so
I'll probably fix our maintenance build before looking into
composite p2 repositories.
P.S: http://wiki.eclipse.org/MDT/OCL/Dev/Releng/Buckminster
is ready. I'll gradually add more information, specially some bits
concerning buckminster but I suppose that the information could be
useful, or at least it's better than nothing ;P
Best Regards and have a nice weekend,
Adolfo.
Ed
_______________________________________________
mdt-ocl.dev mailing list
mdt-ocl.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-ocl.dev
|
