Build Workshop 1/Report

Report to the Planning Council from the Europa Build Workshop

Summary

We met at McMenamin's Edgefield in Portland, Oregon, September 12-13, 2006 to discuss build systems and release engineering around Europa (and Eclipse in general).

Our discussions gathered around the following four focii. We respectfully submit this report to the Planning Council for their consideration in Europa planning. Some of us have taken action items (recorded below) to improve the build and release process for Eclipse projects in general. This documentation is a recommendation by the group but not a commitment on behalf of any PMC.

For future communication, the cross-projects mailing list is at https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Eclipse Build Best Practices

We have identified a number of release engineering best practices across eclipse.org projects. This topic is about promoting these practices and providing tools to encourage standardized adoption of these practices. We have discovered we are replicating tools across projects and this wastes valuable committer time. We want to encourage these practices because the most successful projects employ a high level of automation to reduce the amount of human induced error.

1. Implement versioning consistent with the the versioning guidelines and tooling to compare plugin and feature versions between releases (TPTP, WTP, BIRT and platform teams written tools.)
   1. Use a meaningful qualifer. For instance, use a qualifier that reflects the cvs tag in an integration build. Having the qualifier reflect the timestamp of the build for integration builds is not useful because all the plugins will have the same timestamp in the build regardless of whether they have changed or not. This will result in duplicate content in your update site and unncessary downloads by users. Implementation details available here .
2. Track API changes - To see what has been added, changed or removed. Identify usage of internal APIs. It's recommended that the use of internal APIS be documented in a bug report with an explanation.
   1. TPTP uses jdiff to generate reports API change reports.
   2. TPTP has a bash script to generate a report on internal API usage.
   3. WTP also has a tool
3. Tag files from each release with the same human-readable tag
   1. Use eclipse releng tool to tag release from map files.
4. Specify plugin dependancy requirements with a version range.
5. Use execution environments to specify minimal JRE dependancies.
6. Make builds reproducible
   1. Tag the map files and builder projects with a tag that matches the build identifier. This will ensure that you can run the build again, or branch to incorporate a fix if required.
7. Have an update site; optimize update sites and implement pack 200 for a better update manager experience and significant reductions in bandwidth utilization at eclipse.org and mirrors.
8. Hubert wrote a tool that generates a web page that displays feature structure and depandancies. report
   1. He also has an additional tool that conducts dependancy analysis.
9. The JDT core team's, Distribution Diff Tool is a command line tool which compares two Eclipse based distributions and creates a report of the differences between them. It performs differences on the structure of class files, but does not compare resources (.properties, .gif, .jpg files etc.). This gives the user an idea of what changed between two builds, without having to wade through source changes.
   1. Distribution diff tool
10. A tutorial or example for new projects on how to set up their builds.
11. Keep documentation up-to-date; current link available on website; remove old contents
12. Backup redundant systems
13. Separate publishing script from “build” (compilation); able to turn functions on the build on or off e.g. turn off publishing
14. Regularly scheduled builds and automatically notify developers of build issues.
    1. Gentle public humiliation
    2. Send email to public mailing list or wiki/web page
    3. Send email to responsible parties
15. Feature design – group plug-ins based on functional grouping, optimize feature design for PDE build.
16. Use the packager to avoid multiple recompilation of plugins and speed up the build process.

Go to Europa Build Workshop Home page

Action Items for BBP

• File:Checkmark-10x10.gif(15 September - Andrew, Ben) Finish Making Builds Reproducible page
• 29-Sep Max will update his GMF build documentation as an example of how to write it correctly and put the doc on the wiki; will send email on cross-project-issues-dev@eclipse.org; Ben will edit for native English. Content should include a contact person should there be problems with understanding the build.
• File:Checkmark-10x10.gif Oct 2: (Kim with the assistance of Hubert and Dave) Post an initial list of the best practices from the workshop to the wiki; send an email to cross project list asking them to submit their own best practices to the wiki
• September 29 - (Kim, Hubert, Sue, and Jeff) Provide all existing versioning tools for download and evaluation. Each writes a wiki page on their tool; also evaluate the other three pages. The team of four will either agree on a best one for all Europa or they will return to the cross-projects-issues-dev@ list with a request for more discussion. Tell the Planning Council to promote the best tool for use within the Europa Release. (Sept 29 - BIRT's tool is available in CVS, you can find it in org.eclipse.birt.build plugin, Oct 10 - Eclipse project tool is in org.eclipse.sdk.tests-feature/plugins/org.eclipse.pde.tools.versioning in /cvsroot/eclipse).
• October 2: (Kim) Recommendation to all teams to use pack200 in their builds. (Added to list of possible recomendations for Europa.)
• October 15 Dave will ask a smaller project to provide their templates and Dave will write them up as a wiki page and solicit a vote from the cross-project-issues-dev@ list to the suitability of that result. Also ask EclipseCon 2007 to schedule a session around The Perfect Build.
• October 15 (Bjorn) Send an email to the committers@ asking them to get their nearby build engineers involved in this discussion.
• 1-Nov Projects will have followed Max's lead; prize drawing or something like a T-shirt will be given away to those who've participated. Max is the eligibility judge. Ben, Andrew, Hubert, John, u, Dave, o, Kim, i, Ted will help.
• 31-Dec or earlier Hubert will make the feature dependancy tool open source. Hubert will find one other project to try out the tool. If that other project finds it useful, that project and Hubert will return with a recommendation that the tool be used more widely.

RSS Feeds

The use of RSS feeds solves a number of issues in cross-project communication, and also open a door for cross-project build automation. It can serve as a tool for notification, and also as the input to builds which depend on updates to their upstream dependent projects.

More information on how to set up feeds, XML Schema describing the feed, examples and related bugs can be found here.

Discussion Points:

• All Europa enabled projects will publish an RSS feed based upon the same XML Schema.
• All Europa enabled projects are recommended to store RSS feeds in CVS for auditing/backup.
• All Europa enabled projects must publish on download.eclipse.org in predictable and consistent locations.
  • This will ensure a consistent format for all downstream projects that may be listening for RSS build notifications.
• All project build RSS notifications will be published to download.eclipse.org to minimize node replication and mirroring delays.
  • This will allow RSS listeners to wait for their most convenient mirror.
• Project builds will publish an RSS feed entry for any build that may be of interest.
  • Feeds should include all types of builds (i.e. nightly, integration, maintenance, stable, release).
  • Feed updates should be published the same way projects currently publish builds; eg., if N builds are currently not published to download.eclipse.org, N build feeds are probably not necessary.
  • Feeds can be updated with changed build/test status as needed, so that responding to the notification of a new build need not be held up by long-running tests (eg., Eclipse platform)
• It is up the RSS listener to determine what type of action should be taken depending upon the content of the RSS notification.

RSS Action Items

Action items with dates and (where possible) individuals.

• September 25: (Nick) Improve the already good spec on the wiki/web to a highly detailed spec, including restrictive vocabulary for build and test status. Send email (Cross Project Issues Dev mailing list) to the Europa build engineers and project leads of the Europa leads asking them for feedback before October 13.
  • Email sent. Latest schema and code is now in CVS. The following documents will contain new information as it becomes available:
    • Eclipse Build Available RSS Feeds
    • Eclipse Build Available RSS Schema

Getting Started With RSS Feeds

To get started using this code, I'd suggest extracting everything from CVS and having a look at the examples provided:

cvs -d :pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse -q checkout -r releng_test \
-d org.eclipse.build.tools org.eclipse.releng.basebuilder/plugins/org.eclipse.build.tools

Make sure you get the releng_test branch, not HEAD, if you want the latest implementation.

Then go here: Getting Started With RSS Feeds

• October 20: (Nick) Declare the specification to be "mostly" frozen. Not withstanding continued incremental improvement, this is the RSS spec that all the projects will implement.
• November 20: (All Europa projects) Have implemented publishing RSS information for their build, and provide a link on their website's homepage to that feed
• January 26: (All Europa projects) Have implemented listening to RSS information for their build's upstream dependencies, plus some degree of automated response (eg., emails or automated builds).

Buckminster/Maven Build Enablement for BIRT and ECF

Background goes here on Buckminster/Maven and the corresponding Europa Workshop discussions (Build Best Practices and Common Build Infrastructure) that led to this initiative. What this is (Buckminster and Maven as a build technology). How Buckminster and Maven offered to help BIRT restructure their build. How ECF is the "small project" example. Why this is a good idea.

Introduction

The following organizations and individuals will be working on this Europa initiative to deliver complete build project migration for BIRT and ECF by March 3, 2007, based on agreed-upon requirements and milestones from this initiative.

• Buckminster: Thomas Hallgren, Henrik Lindberg - Buckminster Engineers
• Maven: John Casey - Maven Engineers
• BIRT: Sue Lee - Release Engineer
• ECF: Pete Mackie - Release Engineer
• Simula Labs: Natalie Burdick - Project Manager/Coordinator for this initiative

Action Items

Initial Milestones based on High Level Activities below to be delivered by September 22, 2006:

1. Buckminster/Maven Integration Activity:
   • Buckminster User/Dev Mailing List Membership (John to subscribe)
   • Committer Status at Buckminster for John (Team to vote)
2. BIRT Build Project Conversion
   • Buckminster User Mailing List Membership (Sue/BIRT Team to subscribe)
   • BIRT team to download/perform initial Buckminster evaluation (Sue)
   • BIRT team to review Buckminster Wiki (Sue)
   • Plugin/TLP Build Scripts needs to be reviewed (Sue to send to Thomas)
   • UPDATE：BIRT/Buckminster/Maven had a meeting on October 17, discussed the next steps and initial milestones for this conversation
3. ECF Build Project Conversion
   • CVS Access for Henrik (CVS access information provided to Henrik on Sep 15, 2006 -PHM)
   • Buckminster User Mailing List Membership (Pete to subscribe) (Subscribed to buckminster-dev mailing list on Sep 16, 2006 -PHM)
   • ECF Build Conversion (Henrik to review)

Feature Requirements for Buckminster/Maven

1. Support for maven-artifact(-manager)/maven-project and m2 POMs through revision of Revise MavenComponentType/MavenReader
2. Support for a MavenActor (see AntActor) to fire off Maven plugins/mojos from Buckminster
3. Support to map the Maven life cycle to the Buckminster build
4. Bi-directional synchronization between Maven POMs and Buckminster CSPEC instance

Feature Requirements for BIRT

1. Support to handle versioning requirements: important to check timestamps in CVS and update versions accordingly in plug-ins and features that refer to such plug-ins (Buckminster can resolve this by adding action that checks (ant-task already present) and modifies)
2. Support to host required jar files currently stored in p4 from the Maven repo
3. Javadoc publication support via Maven plugin
4. Support to test components conditionally, e.g., if db2 is not installed, that test should not be enabled
5. Support for site.xml creation
6. Support for existing BIRT project email build notification functionality (build failures and test output sent as emails to developers)
7. Platform/environment-independent support for the BIRT build

Feature Requirements for ECF

1. Adding plug-in and/or feature sets to the build needs to be such that any ECF team member can master it with an hour or two of training and be able to add new project elements to the build in one hour, or less.
2. Support for both local file and remote CVS source and binary code fetch for builds.
3. Report ECF build results to all ECF team members via email.
4. Support for running JUnit plugin tests with test result reporting all ECF team members via email.
5. Automated run of "nightly" builds at pre-defined build times.
6. Support for user-initiated builds via web dashboard.
7. Build administration, which is simple to master; such that any ECF team member can quickly learn "how to."
   • Note: Requirement builds on Support for user-initiated server-based builds via web dashboard item.
8. Ability to optionally perform and report of ECF build each time one or more source code is updated via CVS.
9. Support to host required jar files currently stored in p4 from the Maven repo.
10. Platform/environment-independent support for the ECF build.
11. Javadoc publication support via Maven plugin.
12. Support to test components conditionally, e.g., if db2 is not installed, that test should not be enabled.
13. Provide build output packaged in both Eclipse Update site format and zipped groups of plug-ins, optionally including source code.
14. Support automated upload of successful build contents (zips, update site, docs) to download/update servers.
    • Note: Core ECF plug-in source code frequently provide the base abstract functionality when developing application level messaging plug-ins running on ECF functinality.
15. Be able to select output ECF builds following the five Eclipse Foundation build type formats:
    • Releases: Releases are builds that have been declared major releases by the ECF development team - for example "R1.0". Releases are the right builds for people who want to be on a stable, tested release, and don't need the latest greatest features and improvements. Release builds always have an "R" at the beginning of the name i.e. R1.0, R2.0 etc. Non-release builds are named according to the date of the build - for example 20050710 is the build from July 10, 2005.
    • Stable Builds: Stable builds are integration builds that have been found to be stable enough for most people to use. They are promoted from integration build to stable build by the architecture team after they have been used for a few days and deemed reasonably stable. The latest stable build is the right build for people who want to stay up to date with what is going on in the latest development stream, and don't mind putting up with a few problems in order to get the latest greatest features and bug fixes. The latest stable build is the one the development team likes people to be using, because of the valuable and timely feedback.
    • Integration Builds: Periodically, component teams version off their work in what they believe is a stable, consistent state, and they update the build configuration to indicate that the next integration build should take this version of the component. Integration builds are built from these stable component versions that have been specified by each component team as the best version available. Integration builds may be promoted to stable builds after a few days of testing. Integration builds are built whenever new stable component versions are released into the build.
    • Nightly Builds: Nightly builds are produced over night from whatever has been released into the HEAD stream of the CVS repository. They are completely untested and will almost always have major problems. Many will not work at all. These drops are normally only useful to developers actually working on the ECF project.
      • Note: Nightly builds are produced only as requested, and not necessarily every night, by developers to build what was in HEAD.
    • Maintenance Builds: Periodically builds for maintenance of the current release will be performed. They will not necessarily be stable builds. When the maintenace is finalized and released, it will be moved up to a Release build. If the build name starts with an "M" i.e. M200500810,then it has not been tested for stability. If it is a release candidate, i.e. 0.5.0.1RC1, then it is a stable maintenance build.

Common Build Infrastructure

Introduction

• A common build infrastructure encompasses a build farm, a tool for build management, and a "dashboard"-esque tool for post-build investigation.
• We believe that an 80/20 rule can be applied here: we can easily and quickly meet the needs of 80% of the projects out there with a simple, common build setup. Functionality can be built up to satisfy the remaining projects with "special needs" (ie. native code).
• In an ideal world, all projects would make use of this infrastructure. In the real world, we realize that teams will continue to make use of their existing infrastructure.

Benefits

• This common infrastructure will augment project facilities and act as a second build environment available for use.
• This infrastructure can be used by both new projects to ease their startup pain and also by existing projects to standardize build procedures and to take away maintenance costs.
• Consistency: builds will be reproducible and auditable due to consistent practices
• Best practices: build best practices are more easy to enforce when build procedures are transparent and consistent
• Outreach: this can be considered an outreach activity to a certain extent. Increased transparency is not a bad thing :)
• Committers and projects need not worry about so much setup/infrastructure

Components

1. Build farm
   1. ie. build.eclipse.org.
   2. Longer term, this may grow to include architectures and operating systems used by projects with native code. This growth will be managed by the needs of projects and provided by the foundation.
2. Build management tool
   1. EMFT currently has an exemplary tool for customizing and starting builds. Here is a screenshot:
3. "Dashboard"-esque tool

• • common location for interested individuals (team members, external parties, interested projects, community members, etc.) to examine build results
  • provide a source of information for data mining and/or statistical analysis
  • provide a common view for each project so as to enable easy at-a-glance inspection
  • common locations and look and feel for all the builds/downloads are good because they help with community understanding and adoption
  • eg., http://packages.qa.debian.org/f/firefox.html
  • include [CruiseControl]

Action Items for CBI

• (7 October - Denis) MySQL upgrade
• (15 October - Nick, Andrew) Assist in migrating ECF to web UI for kicking builds & running tests on their vserver using EMFT as example
• (1 November - Andrew) Work on proposal for Foundation including what we intend recommendations will entail
• (1 November - Denis, Henrik, Sue) Set up a vserver for Buckminster/BIRT builds. Denis estimates that if we end up going with vservers, this will cost $750/project (in increments of 6); Denis will ask for money if that route is chosen. Predicted alternative: set this up on build.eclipse.org and don't have vservers. UPDATE: It has been determined that individual project vservers for building is not an option. build.eclipse.org is to be used instead. --Denis.roy.eclipse.org 15:09, 4 October 2006 (EDT); According to Meeting minutes for BIRT/Buckminster/Maven, this action item will be delayed to December 1.
• (15 November - Nick, Henrik, Andrew) Explore Buckminster as wrapper for running EMF/EMFT builds
• (15 November - Nick, Henrik, Andrew) Explore creating a web UI for running Buckminster builds (PHP, XMLRPC?)
• (1 December - Henrik, Sue, Nick, Denis, Andrew) Report on past few months' work to determine what is required of the foundation for the future
  • (15 December) Based upon report, propose required resources to foundation including the following recommendations:

(Potential) Recommendations

• staff at eclipse.org to maintain infrastructure (both IT and UI)
• staff at eclipse.org to manage releng of release train
• member companies must provide a small (2-4 people total) team of rotating releng people to manage release train
• build infrastructure hardware at eclipse.org

Communication Channels

For Europa, there needs to be at least one designated contact from each project available via phone, email, IM, etc. For critical periods (milestones and release candidates), the Europa build engineers should be on a common IRC channel or IMs or something.

Signature Block

Nick Boldt, Natalie Burdick, John Casey, Ward Cunningham, Max Feldman, Bjorn Freeman-Benson, Thomas Hallgren, Ben Konrath, Sue Lee, Hubert Leung, Scott Lewis, Henrik Lindberg, Pete Mackie, Kim Moir, Dennis O'Flynn, Andrew Overholt, Denis Roy, Ted Williams, David Wolfe