Community
Participate
Working Groups
On today's Babel call we agreed to the following: Release schedule * The current Language Pack build process runs for almost a day, we need to cut down on the process * In my opinion, it is useless to rebuild language packs for Ganymede and Europa every night, as the changeset must be very small * Also, to avoid the current situation where our Language Packs and update site are broken/not available, here is a proposal: o Our Nightly build consists of the Current Train only. In this case, our nightly build would be Galileo only. Our nightly build stays on build.eclipse.org o Our Weekly build consists of All Trains. This weekly build would stay on build.eclipse.org, instead of going to download.eclipse.org o We promote a known good Weekly build to our official download site (download.eclipse.org) on a regular basis (Perhaps monthly, or as needed after a large syncup). * I'd also like to propose to kick off the Weekly build on Friday night or Saturday night, so we can inspect the output on the weekend and discuss any issues on Monday This bug is opened to track progress.
Created attachment 132672 [details] Patch for generate1.php Here's a patch for generate1.php. I up the memory limit and accept a command-line parameter for a specific train. I also moved the database connection inside the 'while there are trains' loop, since generating the metadata takes several hours (on the babel server, anyway).
I still need a solution for the language pack index.php inside generate1.php
I've started building our nightly builds in separate, date-encoded directories. See: http://build.eclipse.org/technology/babel/ Here's what I'm thinking is left: - script the removal of builds older than 7 days - perform some automated tests on each nightly build, and post the results in the build directory. - separate the trains, only build the current train in the nightly build, all trains in a weekly build - craft a way to promote a known good weekly build to the live download site - Re-implement the p2 metadata
Created attachment 135020 [details] Patch v2 Here is a revised patch. It accepts a train name as an argument, and instead of building an index.php for all the language packs (which was a very long html file) it will build a train_id.php file (galileo.php, ganymede.php) containing the lang packs of that train. This approach will allow us to create index.php as part of our test processes.
Created attachment 135156 [details] Patch v3 Here's an updated patch. The links on build.eclipse.org referenced the Eclipse mirroring system. This patch will create a blank variable inside each index file, allowing our promote process to properly update it to use the mirrors when a build is promoted.
Created attachment 135163 [details] Patch v4 Please ignore the previous patch, it was bogus. This one works as intended on my dev box. I'll be committing this later so that our builds can start using the separate trains and I can progress on a promote method.
Created attachment 135221 [details] Patch2 v1 I have committed Patch v4, and I have deployed it into R_0_200905111332. It is currently running a Galileo build, so by tomorrow morning we'll see the build on our nightly builds page. Here is another patch which a) takes two command-line parameters: the train name (optional) and the Build ID from the shell script. I'm now using getopt() to make this easier b) places the basic HTML header into an HTML file, since I'll be using it in index.php (not just in trainname.php). This is shaping up -- bear with me.
Build N20090511-1300 and W20090512-0400 were both successful, although W20090512-0400 was incorrectly identified as a weekly build. galileo.php is correctly generated. http://build.eclipse.org/technology/babel/babel_language_packs/ Next step: introduce a 'tests' step that will assemble the index.php and indicate if the build was successful or not.
I've pushed out the latest patch > R_0_200905121327
(In reply to comment #8) > Next step: introduce a 'tests' step that will assemble the index.php and > indicate if the build was successful or not. > For testing could we compare the errors generated from running a clean Eclipse launch and one with X language pack. We could then put the difference of the errors logged on the index.php page for the promoter to inspect before promoting the build. Just a thought.
(In reply to comment #3) > Here's what I'm thinking is left: DONE: script the removal of builds older than 7 days DONE (although quite thin): perform some automated tests on each nightly build, and post the results in the build directory. DONE: separate the trains, only build the current train in the nightly build, all trains in a weekly build DONE: craft a way to promote a known good weekly build to the live download site TODO: - promote script needs to implement the mirroring. This is as simple as substituting one line in train_name.php - Re-implement the p2 metadata - Implement more automated tests.
On today's call, Kit expressed a desire to take an I-build and 'promote' it to an RC status before promoting it live. I'll hack the current promote.sh script to support the following workflow: ./promote.sh I20090531-0400 RC1 -> promote May31 I-build to RC1 on build server ./promote.sh I20090607-0400 RC2 -> promote Jun07 I-build to RC2 on build server ./promote.sh I20090614-0400 RC3 -> promote Jun14 I-build to RC3 on build server ./promote.sh RC3 -> promote RC3 build to the public downloads area This means we would no longer be able to promote an I-build to the public downloads area, favouring instead a release cycle. Kit, is this what you are looking for?
Assuming the previous, I've implemented the I-build -> RC -> Release workflow in promote.php, and I have updated the instructions at http://wiki.eclipse.org/Babel_/_Building_and_Releasing_Language_Packs TODO: - promote script needs to implement the mirroring. This is as simple as substituting one line in train_name.php - Re-implement the p2 metadata - Implement more automated tests.
Thanks, Denis! The promotion plan sounds good. I'm just thinking ahead. When we get to RC1 for Service Release 1 (SR1) of Galileo, or RC1 for the next release train of Eclipse, do we need another parameter for the script, so we can promote the build to a different directory? It may be too early to think about that now :-)
> - promote script needs to implement the mirroring. This is as simple as > substituting one line in train_name.php DONE > - Re-implement the p2 metadata There is a bug for that. > - Implement more automated tests. Yeah.
