Skip to main content

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.

Jump to: navigation, search

Modeling Project Builds

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.

  1. TAG: CVS Tagging / Mapfile Generation
  2. BUILD: Building Zips, Jars, and other artifacts
  3. TEST: Offline testing (performance, API, other)
  4. PROMOTE: Promoting builds


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

Back to the top