Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Build Workshop 1/Report"

(Benefits)
m (RSS Feeds)
Line 17: Line 17:
  
 
=RSS Feeds=
 
=RSS Feeds=
What this is about (common reporting mechanism for all projects). Why this is a good idea. Explain all the details we know so far including links to other pages on the topic. Explain the discussions that have occured (reasons) and why certain decisions were taken (for example, that Bjorn claims that all builds should be included, but the group decided to recommend against that because...)  Explain outstanding discussion points such as whether to include nightly builds, whether to include failed builds, how to represent builds whose status is unknown, how we plan to define the vocabulary, etc. Specification should include where the URLs for the RSS feeds, etc.
+
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.  
  
===Action Items===
+
More information on how to set up feeds, [[Eclipse_Build_Available_RSS_Schema XML Schema describing the feed]], examples and related bugs can be found [[Eclipse_Build_Available_RSS_Feeds here]].
Action items with dates and (where possible) individuals. For example:
+
 
* September 15: (Nick) Improve the already good spec on the wiki/web to a highly detailed spec. Send email around to the Europa build engineers and project leads of the Europa leads asking them for feedback before October 15.
+
Discussion Points:
* October 15: (Nick) Declare the specification to be "mostly" frozen. Not withstanding continued incremental improvement, this is the RSS spec that all the projects will implement.
+
* All Europa enabled projects will publish an RSS feed based upon the same XML schema.
* November 15: (All Europa projects) Have implemented publishing RSS information for their build.
+
* All Europa enabled projects will store RSS feeds in CVS and 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 the project's download area.
 +
** This will allow RSS listeners to wait the download area, or equivalent mirror, for the notification at a location that is most convenient to that project.
 +
* Project builds will publish a RSS notification for any build event that may be of interest.
 +
** Project build notifications will include all types of builds (i.e. nightly, weekly, milestone, etc...)
 +
** Project build notificaitons will be sent regardless of the build result (i.e. pass, fail)
 +
** It is up the RSS listener to determine what type of action should be taken depending upon the content of the RSS notification.
 +
* Each project build process will archive its RSS feed within CVS.
 +
** This will provide a historical trace of the project's build activity.
 +
 
 +
==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 around to the Europa build engineers and project leads of the Europa leads asking them for feedback before October 13.
 +
* 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.
  
 
=Buckminster/Maven Build Enablement for BIRT and ECF=
 
=Buckminster/Maven Build Enablement for BIRT and ECF=

Revision as of 17:02, 13 September 2006

Draft
Report to the Planning Council from the Europa Build Workshop

Summary

Dates, attendees, summary of discussion topics, summary of recommendations to the Planning Council, i.e., that they should staff these four focii sufficiently to allow them to succeed in the Europa timeframe.

Eclipse Build Best Practices

What this is about. Why this is a good idea. What we intend that an effort in this area will accomplish. Explain how these are usually motherhood and apple pie type best practices, but that this effort is about specific recommendations at the level of detail that can be followed by engineers.

Action Items

Action items with dates and (where possible) individuals. For example:

  • September 25: (Paul, Susan, William) Post an initial list of the best practices from the workshop to the wiki; send an email to all committers and project leads asking them to submit their own best practices to the wiki
  • October 2: (Paul) Recommend to the Planning Council that they adopt practices X, Y, Z as requirements for Europa and M, N, P as 'should do' for Europa. Etc.
  • October 15: (William) Send another email to the same group encouraging more conversation
  • October 15: (Susan) ask EclipseCon 2007 to schedule a session around Build Best Practices.
  • ...etc...

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, Eclipse_Build_Available_RSS_Schema XML Schema describing the feed, examples and related bugs can be found Eclipse_Build_Available_RSS_Feeds here.

Discussion Points:

  • All Europa enabled projects will publish an RSS feed based upon the same XML schema.
  • All Europa enabled projects will store RSS feeds in CVS and 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 the project's download area.
    • This will allow RSS listeners to wait the download area, or equivalent mirror, for the notification at a location that is most convenient to that project.
  • Project builds will publish a RSS notification for any build event that may be of interest.
    • Project build notifications will include all types of builds (i.e. nightly, weekly, milestone, etc...)
    • Project build notificaitons will be sent regardless of the build result (i.e. pass, fail)
    • It is up the RSS listener to determine what type of action should be taken depending upon the content of the RSS notification.
  • Each project build process will archive its RSS feed within CVS.
    • This will provide a historical trace of the project's build activity.

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 around to the Europa build engineers and project leads of the Europa leads asking them for feedback before October 13.
  • 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.

Buckminster/Maven Build Enablement for BIRT and ECF

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.

Action Items

Action items with dates and (where possible) individuals. For example:

  • September 20: Initial Milestone based on High Level Activities(Group)
    • Buckminster/Maven Integration Activity:
      • Buckminster User/Dev Mailing List Membership (John to subscribe)
      • Committer Status at Buckminster for John (Team to vote)
    • BIRT Build Project Conversion
      • Buckminster User Mailing List Membership (Sue/BIRT Team to subscribe)
      • BIRT team to download/perform initial Buckminster evalution (Sue)
      • BIRT team to review Buckminster Wiki (Sue)
      • Plugin/TLP Build Scripts needs to be reviewed (Sue to send to Thomas)
    • ECF Build Project Conversion
      • CVS Access for Henrik (Pete to provide)
      • ECF Build Conversion (Henrik to review)
      • Buckminster User Mailing List Membership (Pete to subscribe)

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
  5. Supplying dialog-driven addition of maven plugins to the buckminster action mapping.

Feature Requirements for BIRT

  1. Support to handle versioning requirements: Important to check timestamps in CVS and update versions accorgingly in plugins and features that refer to such plugins (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

TBD - initial set by Sept 20

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 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. Initially, this can be comprised of virtual machines much like the current vservers maintained by Denis.
    2. Longer term, this will 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: EMFTBuildPage2.jpg
  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

  • (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 - Denis, Henrik, Sue) Set up a vserver for Buckminster/BIRT builds
  • (15 November - Nick) Explore Buckminster as wrapper for running EMF/EMFT builds
  • (15 November - Nick) 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
  • staff at eclipse.org to manage release train
  • member companies must provide a small team of rotating releng people to manage release train
  • hardware requirements

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.

Back to the top