Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Modeling Project Builds"
m |
m |
||
| (5 intermediate revisions by the same user not shown) | |||
| Line 22: | Line 22: | ||
* rtag cvs using a given tag (generated from branch name + timestamp, eg., R2_2_maintenance_200611011234) | * 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 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. | 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. | ||
| Line 32: | Line 33: | ||
:* run a build | :* run a build | ||
:* '''NEW''' kill a tree of processes (stop 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. | :* '''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) | :* rename a build (eg., RC3 -> GM) (script exists, but web UI is new) | ||
| Line 42: | Line 44: | ||
:* maven jars | :* maven jars | ||
:* javadocs | :* javadocs | ||
| + | :* build-specific documentation (warnings, "News and Noteworthy", etc.) | ||
:* release-notes.xml (complete snapshot) | :* release-notes.xml (complete snapshot) | ||
:* site news / build announcement | :* site news / build announcement | ||
| Line 53: | Line 56: | ||
:* if listening for a promote, look at download.eclipse | :* if listening for a promote, look at download.eclipse | ||
| − | * allow browsing build folders (since no SSH access) | + | * 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 | * '''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 | * JUnits run as part of a PDE build are included here | ||
| + | |||
| + | * Jar signing to be done here too | ||
= TEST: Offline testing (performance, API, other) = | = TEST: Offline testing (performance, API, other) = | ||
| Line 78: | Line 83: | ||
* can rsync be used to sync between build.eclipse and dev.eclipse? | * 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 | * publish snapshots produced in build to cvs (web) instead of generating content while promoting | ||
| + | |||
| + | |||
| + | [[Category:Releng]] [[Category:Modeling]] | ||
Latest revision as of 14:24, 25 January 2007
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