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.
EDT:Release Engineering
Contents
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.
- EDT:Developer's Guide to Getting Started on EDT
- EDT:Downloading and installing EDT builds
- EDT:How to commit code to EDT
- EDT:How to add new EDT plugins
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).