[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[mdt-ocl.dev] Releng Status
|
Hello Team,
After some days working on the releng, here you have a small report
concerning my progress:
1.
https://hudson.eclipse.org/hudson/job/buckminster-mdt-ocl-core-3.1-nightly/
As commented, the buckminster based build is quite stable. However, the
following are topics in which I've been working on:
- The following https://bugs.eclipse.org/bugs/show_bug.cgi?id=332546
bugzilla exposed a problem in our generated artifacts. I've partly fixed
the problem since every required .zip contains both lpg.runtime.java and
lpg.runtime.java.source bundles. However, the zip which contains the P2
repository (The all in one Update zip) only contains the
lpg.runtima.java bundle and I haven't been able to make it contain the
source bundle one... Still pending.
- Due to the recent request about making I-builds ( to create an interim
p2 repository with bleeding edge stuff) which should be feeded by the
other dependant project (such EMF) Integration P2 repositores, I've
configured hudson and the buckminster stuff so that depending on the
build-type (N,I,S) our build will be feeded by other dependent project
Interim/Integration or Milestones P2 repositories. So that
1) When doing an MDT/OCL N or I-build, EMF, UML, ..., Integration
P2 repositories will be used.
2) When doing an MDT/OCL S-build (milestone), EMF, UML, ...,
Milestones P2 repositories will be used instead.
- Due to EMF and UML doesn't produce nightly P2 repositories, I 've
decided to revert to our night-build policy so that now our builds are
run when changes are detected in our CVS and they are based on the EMF
and UML Intergration P2 repsotories. I think that it doesn't make sense
doing a nightly build (which may detect incompatibilities with our
dependent projects), if we are not basing our code in some kind of
nightly P2 repository.
- I wanted to try to use some publishing scripts from EMF releng, which
deal with composite repositories and such. However, since Kenn told me
that Mickal is working on them and in its documentation, I prefer to
wait a little bit.
2. https://hudson.eclipse.org/hudson/job/cbi-mdt-ocl-3.0-integration/
- The job has been fixed, which relies on the maintenance branch and it
should be only used to manually create M-builds (and the final SR2 build)
- I wanted to create a true M-build with updated content (which means
update ocl.map files, etc). However, I want to clarify this bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=327823 before doing any
kind of tag on our branch.
3. https://hudson.eclipse.org/hudson/job/cbi-mdt-ocl-3.0/
- This build is supposed to use our maintenance branch code to do a
build. Now, it only differs from the previous job that it uses the
"-forceContextQualifier -fetchTag R3_0_maintenance" extra flags, so that
instead of using the ocl.map file the build is feeded by the last
maintenance branch code. However, I've not been able to fix this job so
far (it complains about not finding an org.eclipse.tests plugin).
- Tomorrow, I'll try to do a deep study of the logs to see what's wrong.
I don't know why this worked with HEAD, and despite being identical to
the integration job definition it doesn't work neither.... If I don't
find a solution tomorrow, I'll probably give up trying to fix this, and
we will only have availabe the manual launched build using the ocl.map file.
P.D: I'll also add an entry to Alex's cheatsheet concerning the M-build.
Best Regards,
Adolfo.
