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 2: Build Harder/Report"

(New page: == Meeting notes == === Pain points === * Build takes 2 weeks to setup * Steep learning curve * Enforcing eclipse.org rules * No one wants to build === Existing build approaches === * Set ...)
 
Line 1: Line 1:
 
== Meeting notes ==
 
== Meeting notes ==
 +
=== Attendees ===
 +
Igor Fedorenko, Nick Boldt, Bjorn Freeman-Benson, Denis Roy, Kim Moir (morning), Pascal Rapicault (morning), DJ Houghton (morning)
 
=== Pain points ===
 
=== Pain points ===
 
* Build takes 2 weeks to setup
 
* Build takes 2 weeks to setup

Revision as of 16:07, 26 June 2008

Meeting notes

Attendees

Igor Fedorenko, Nick Boldt, Bjorn Freeman-Benson, Denis Roy, Kim Moir (morning), Pascal Rapicault (morning), DJ Houghton (morning)

Pain points

  • Build takes 2 weeks to setup
  • Steep learning curve
  • Enforcing eclipse.org rules
  • No one wants to build

Existing build approaches

  • Set of scripts that run headless eclipse with basebuilder. Builds are scheduled from WebUI but actual work is done by cron job. WebUI and the cron job communicate via tmp file.
  • Maven
  • Scripts + Buckminster to collect dependencies

Other considerations

  • Ability to build/test projects against multiple versions of target platform. Not many projects use that, ones that do would need to setup separate build for each target platform.
  • Ability to reproduce builds (needs to be tagging, but there is more to this). Some exploiters rebuild eclipse.org projects from sources, so builds should be reproducible outside of eclipse.org too.

Discussed topics

  • Common build infrastructure for smaller projects. Configuration will be done via project portal. Committers will be able to trigger builds via http://build.eclipse.org/cbi/.
  • As a way to promote best practices, there will be only one way of doing builds in CBI. Projects that want/need to deviate, will have to fork CBI or setup their own build from scratch.
  • One build or one build per top-level project. Use build queue as a way to measure build server utilization.
  • Bigger projects will likely need dedicated build person/team.
  • Building Eclipse SDK is outside of CBI scope.
  • Separate virtual server for each project will require too much hardware resources, but individual projects can request virtual build server.
  • Cruisecontrol or similar tool to execute builds on as needed bases or by request. For CVS, watch changes to map file(s) instead of entire source tree. Not a problem for SVN.

Back to the top