Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Modeling Project Builds
This article is a stub. You can help Eclipsepedia by expanding it.
Proposed process using build.eclipse.org for EMF/EMFT/UML2 builds (once they move into the Modeling Project). The goal of this redesign is to simplify the maintenance of the 12+ builds. As a side-effect, a common build infrastructure will be developed which other projects can use to their benefit.
The old process was two steps: tag+build+test then promote+build. In order to improve security and place responsibility for code changes (cvs tagging) on the developers instead of on an automated process run by a central ID, the process is being split.
The new process consists of four steps.
- TAG: CVS Tagging / Mapfile Generation
- BUILD: Building Zips, Jars, and other artifacts
- TEST: Offline testing (performance, API, other)
- PROMOTE: Promoting builds
Contents
TAG: CVS Tagging / Mapfile Generation
This step can be done by hand by developers (commandline cvs or in Eclipse) or can be done via crontab on a server OTHER than build.eclipse.org (eg., dev.eclipse.org or an internal test server).
Crontab script need perform the following functions:
- rtag cvs using a given tag (generated from branch name + timestamp, eg., R2_2_maintenance_200611011234)
- generate a mapfile using that new tag, and commit that file to CVS to preserve history.
- generate test manifest file (?)
A web UI may be developed to allow adhoc tagging to be done for non-scheduled builds, which is simply a wrapper to the crontab script.
BUILD: Building Zips, Jars, and other artifacts
This section is under construction. Here are some quick notes.
- can apache sudo to modelingBuild? need to run specfic shell scripts:
- run a build
- NEW kill a tree of processes (stop a build)
- NEW delete a build (clean up)
- NEW change status of a build (tests failed/passed); called as web service at end of TEST step below.
- rename a build (eg., RC3 -> GM) (script exists, but web UI is new)
- /opt/public/modeling/public_html/ -> http://build.eclipse.org/modeling/
- .htaccess restricted build pages for each subproject; shared common code (php includes), but each project gets its own .htaccess page/password
- NEW: change build to produce all artifacts (some now produced during promote)
- UM site - NEW: split UM site.xml - one per project
- maven jars
- javadocs
- build-specific documentation (warnings, "News and Noteworthy", etc.)
- release-notes.xml (complete snapshot)
- site news / build announcement
- RSS feed
- aggressive clean up - 3 day old builds purged via crontab
- limit a given project's branch to 5 builds (?)
- RSS - notify for ready builds, tested bulds, and promoted builds (status codes in the feed must change)
- if listening for a build, look at build.eclipse
- if listening for a promote, look at download.eclipse
- allow browsing build folders (since no SSH access (?) -- seems to me I can ssh to build.eclipse.org)
- NEW: build page will now either build from HEAD or from a given specific tag
- JUnits run as part of a PDE build are included here
- Jar signing to be done here too
TEST: Offline testing (performance, API, other)
This section is under construction. Here are some quick notes.
- offline/internal test server(s) for performance, API, or other non-standard tests that can't be run as part of PDE (different JDKs? different architectures?)
- listen to RSS feed to determine when to run tests
- wget (rsync?) from build.eclipse.org to pull down driver to test
- internal server's downloads page needs extra status details (as it does now for EMF builds)
- update RSS feed and build.cfg w/ test status (via .php script running on build.eclipse); revise downloads page to reflect this information
- This allows for the case where JUnits passed but offline tests failed so that a build can be tagged as bad, or if a build is good but a test needs to be fixed to reflect new expected results
PROMOTE: Promoting builds
This section is under construction. Here are some quick notes.
- promote a build (web UI) on internal test server -- NOT on dev.eclipse
- web UI is just a wrapper to ssh to dev and run a script there (so it's the same code for everyone)
- promote script runs on dev.eclipse to pull from build.eclipse and commit web artifacts to cvs; runs as committer
- NEW need commandline flags to specify if pulling data, promoting data, or both, eg.
-get /tmp/emf-3.3-I200703031234 -promote
- can rsync be used to sync between build.eclipse and dev.eclipse?
- publish snapshots produced in build to cvs (web) instead of generating content while promoting