Jump to: navigation, search

EDT:Release Engineering

Revision as of 13:06, 24 February 2012 by Mheitz.us.ibm.com (Talk | contribs)

Release Engineering for EDT

This page contains hints, tips, links, and instructions for the EDT project's release engineer.

Background Information

General Information

The Eclipse Wiki is sometimes useful, and sometimes outdated or missing info you think it should have...it may drive you insane.

The Eclipse sysadmins can be reached at webmaster@eclipse.org. They're very helpful. Before writing to them, check their FAQ at Webmaster_FAQ and the other resources on this page.

You can learn a lot by reading Development_Resources and IT_Infrastructure_Doc.

Developing EDT

To be the release engineer, you have to know the EDT development process in addition to the build process.

Releng Resources and Information

Bugs

The Bugzilla component for release engineering is EDTBuilds, though some people might report problems on the Website component. See EDT:How to be notified of EDT bugs.

Hudson

Our builds run in Eclipse's Hudson system. The build job is at https://hudson.eclipse.org/hudson/job/cbi-edt-nightly/.

Once you log in, you can disable/enable nightly builds with the Disable/Enable Project button. Click the Configure link to edit the build schedule and many other parameters. One thing you must do is enter your email address in the Email Notification box at the bottom of the Config page. That way you'll know when builds fail.

org.eclipse.edt.releng

Some aspects of our builds are configured in Hudson, and the rest are configured by files in the project named org.eclipse.edt.releng. It's a regular Eclipse project, not a plugin. It contains the map file, and the main build.properties and build.xml.

build.eclipse.org

Eclipse provides a machine called build.eclipse.org where you can do various build tasks. Any committer can log in, but the default shell only lets you run one command and then logs you out (to limit the number of people who can screw up the system). The EDT release engineer needs a real shell. Send a request to webmaster@eclipse.org .

Downloads

The last step in our build process makes the new build available for download from download.eclipse.org/edt/. You can access and modify the downloadable files when you're logged in to build.eclipse.org, by going to /home/data/httpd/download.eclipse.org/edt/.

People are encouraged to use a mirror when downloading files. So rather than using a direct link like http://download.eclipse.org/edt/A/B/C, use http://www.eclipse.org/downloads/download.php?file=/edt/A/B/C. The download.php script lets people choose a mirror. (But do NOT use this kind of URL for a P2 update site.)

The Archive

Space on the Eclipse download server is limited. It has the latest release, the latest milestone of the next release, and the latest nightly builds. Older nightly builds are deleted, but older milestone and release builds are moved to the archive instead. Its URL is http://archive.eclipse.org/edt/. When you're logged in to build.eclipse.org, our archive can be found at /home/data/httpd/archive.eclipse.org/edt/.

The MyFoundation Portal

The MyFoundation portal at https://dev.eclipse.org/portal/myfoundation/portal/portal.php lets you view and modify various kinds of meta-data about the EDT project.

In the Eclipse Projects box, choose 'view' next to tools.edt, and click '[maintain]' to edit the project meta-data. Fields that may need to be updated from time to time are Bugzilla, Source Repository, and Release.

If you choose '[tools]' next to tools.edt in the Eclipse Projects box, there are links for 'download stats', or to manage Bugzilla stuff use 'Bugzilla components, targets, versions'. You can add milestones, releases, components, etc. Be very careful when working with Bugzilla because many changes are permanent.

cross-project-issues-dev

Eclipse's cross-project-issues-dev mailing list is for announcements and problems that affect many projects. You should subscribe to it by going to https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Our website

The files of www.eclipse.org/edt are stored in CVS. To view them, make a repository connection like :extssh:<USER>@dev.eclipse.org:/cvsroot/org.eclipse, and go to the folder www/edt/.

Starting a Build

Log in to Hudson and click Build Now. The single build parameter identifies the kind of build: use N for nightly, M for milestone, and R for release. Nothing special needs to be done for nightly builds, but see below for special instructions for milestone and release builds.

Outputs of a Build

Builds use a workspace directory on one of the Hudson slave machines. The workspace can be viewed through Hudson, but it can't be accessed from build.eclipse.org.

After a successful build, the new update sites are accessible from build.eclipse.org. The zipped update site (and JUnit results when we get those going) is in downloads/edt/downloads/drops/BuildTypeName/Version/BuildType_ThisBuild, where

  • downloads is /home/data/httpd/download.eclipse.org/
  • BuildTypeName is nightly, milestones, or release
  • Version is a three-digit version number
  • BuildType is a letter: N for nightly, M for milestone, R for release

Examples:
downloads/edt/downloads/drops/nightly/0.8.0/N_ThisBuild
downloads/edt/downloads/drops/milestones/0.8.0/M_ThisBuild

The build process also unzips the update site. The update site for a nightly build is unzipped into downloads/edt/updates/nightly/. A milestone build is unzipped into downloads/edt/milestones/1.0/, and a release build is unzipped into downloads/edt/updates/1.0/. See EDT:Update_Site_Guidelines for more info about these update sites.

We give Hudson permission to write into our downloads area using ACLs. The Hudson user is hudsonBuild. If you change the existing structure or make a new directory, but sure to modify its ACL.

How To Deal With a Failed Build

When a build fails, Hudson will send and email to you and everyone who committed a change in that build. The message lists the changes and shows the tail of the build log.

If the build failed because something didn't compile, you probably don't need to remind the developer to fix the problem or help them, unless the failure was a missing plugin. Missing plugins are discussed at EDT:How_to_add_new_EDT_plugins.

If the build failed because of a Hudson problem, check Bugzilla. Hudson bugs have Classification=Eclipse Foundation, Product=Community, and Component=Hudson. If there's no bug for the problem, open one (you can use this link https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Community&component=Hudson).