eclipse-ocl-bot
commented
5 hours ago By Adolfo Sanchez-Barbudo Herrera on Aug 27, 2012 12:48
IMO, This is the desired situation
a) Nightly-Build.
- Automatic build.
- Core build detects changes into the Git repo, and it's triggered.
- Tools build is automatically kicked out by the Core build, using the last successful generated p2 repository (core artifacts) to feed the Tools build
b) Interim-Build.
- Manual build.
- Core build is kicked out by hand.
- Tools build is a automatically kicked out by the Core build, using the last successful generated p2 repository (which contains Core artifacts) to feed the Tools build.
c) Stable-Build.
- Manual build.
- Core build is kicked out by hand.
- Tools build is kicked out by hand, using the milestone core p2 repository (which contains Core artifacts) to feed the Tools build.
d) Releases-Build.
- We are not currently doing R-Builds. Since our final release is actually a copy from our last RC (S-build). However, this should be quite similar to the S-build.
e) Maintenance-build.
- This is like the N-build from the maintenance stream. However this build.type (M-build) + build.alias (e.g 4.0.1RC1) configuration is also used to manually produce the Service Release RCs.
I see a couple of problems:
- To make b) properly work. The tools.rmap file needs to be adjusted so that it uses the last successful generated OCL Core p2 repository. Otherwise, an intermediate "publishing" step would be required.
- It looks like that sometimes (case a) and b) ) we would want to run automatically the Tools build and some other times (i.e. c)) we don't want to do it. The worst of this requirement, is that it depends on a job paramater and, therefore, it doesn't look to be possible to accomplish.
- Since we use the M-build for both maintenance "Nightly builds" and RC (Stable builds) I don't see an uniform solution based on the own build type. Do we require an extra letter for that kind of Maintenance Stable build?. Solving this doesn't sound to be trivial from the releng point of view, since downloads area artifacts and p2 repositories are placed/located using this build.type information)
Firstly, let's forget problem 3 and focus on setting the releng stuff to have a) b) and c) properly working:
-
The current releng configuration:\ a) properly works.\ b) and c) wouldn't work because the Tools build automatically runs as an N-build.\
-
Making the Tools build receive the jobs parameter used for the Core build\ a) would properly work.\ b) would properly work (Taking into account that the trivial problem 1. needs to solved).\ c) would not properly work, since an automatic Tools S-build would be run when we want to wait until +3 time frame to run it (problem 2).\
-
Changing the trigger of the builds so that Core and Tools build automatically check the Source Code repository for example at 0:00 am and 1:00 am respectively. The other change is removing the automatic Tools build run when the core one finishes.\ a) would properly work and now it's a real Nightly build. Likewise, we don't make the build run several times per day when we are doing changes along the day.\ b) would partially work, since we don't have an automatic Tools build kicked out. We would have to manually do it (similar to what we do with the S-one).\ c) would properly work.\ \ I think that 3.b) is the minor of our problems, so I'm inclined to adopt the solution 3.
Any other ideas, of course, are welcome.
Cheers,\ Adolfo.
| --- | --- | | Bugzilla Link | 380170 | | Status | CLOSED FIXED | | Importance | P3 normal | | Reported | May 21, 2012 14:28 EDT | | Modified | May 27, 2014 09:52 EDT | | Reporter | Adolfo Sanchez-Barbudo Herrera |
Description
In some circumstances is desirable that the core build propagates (after finishing) some parameters to the Tools one (before starting).
This jobs chaining was introduced basically to make the Tools N-build run after the automatically executed Core N-builds finishes.
However, when manually launching some builds is desirable that some parameters are passed between jobs, for instance, the own build.type, so that a Core I-build kicks out a Tools I-build.
Study the different desire cases, and find a proper way to make this propagation happen (if possible).