This site has been retired. For up to date information, see handbook.gnome.org or gitlab.gnome.org.


[Home] [TitleIndex] [WordIndex] 

Contents

  1. Build Brigade
    1. The Gnome Buildbot
    2. Our Goals
    3. Existing efforts
    4. Social aspects
    5. Todo
    6. Long term ideas
    7. Done
    8. Build Tools
      1. Tinderbox 3
      2. JHBuild
      3. BuildBot
      4. Garnome
    9. Requirements
    10. Niceties
    11. Questions
    12. Interesting links and documentation
    13. Meetings
    14. Background
    15. Contact us
    16. Who are we?

Build Brigade

The Build Brigade is an effort to automate discovery and reporting of Gnome build errors and
to make testing of the development version easy for everyone

The Gnome Buildbot

This is a continuous integration system based on Buildbot adapted to build all Gnome modules through jhbuild:

http://build.gnome.org

Our Goals

Roughly in order of priority:

Detailed requirements obtained mainly from Luis Villa's experience with MicroTinder can be found here:

Existing efforts

Social aspects

Todo

This is a list of tasks that need to be done. If you think you can help with any of them, please, let us know, your help would be very welcomed ;-). After each task there is a set of attributes between parenthesis that state for (priority, difficulty, technology, asigneee). If you want to collaborate in a task which is already assigned, you can contact the people the task is assigned to. Otherwise, if you want to help in an unassigned task, you can talk to us using the mailing list and the IRC channel, or you can contact me (IagoToral) directly.

Long term ideas

Done

Build Tools

Tinderbox 3

JHBuild

JHbuild builds Gnome from git (before: svn/cvs) or tarballs

BuildBot

Garnome

Garnome builds Gnome from latest tarballs (both stable and unstable branch)

Requirements

Niceties

Questions

ChristianKirbach: This cannot easily be answered. Updating the sources is faster than checking out everything each time. Keeping the old object modules, i.e. not running 'make clean', usually saves a lot of building time. However, cvs sometimes cannot update properly and gives up because of conflicts. I have sometimes experienced that after successfully updating the sources autogen must be run again for a successful build. I have also rarely seen that make clean actually was required. So, for fast building we probably want some fallback system like

  1. Update sources and build. (If updating fails jump to d?)

  2. If build fails run autogen and build.

  3. If build fails run make clean and build.

  4. If build fails purge the sources, check them out, run autogen and build.

  5. If build finally fails the module is definitely broken. Reasons can be a broken module or e.g. an API change in one of its dependencies.

I assume steps b and c recover the build in 90% of all failing cases.

JoseDapenaPaz: an easy solution is combining "compiling caches" (like ccache) and a "copy" update model (see my post about implementing checkout modes in jhbuild).

JoseDapenaPaz: I would definitely use the previous build. We cannot taint all the modules because of every single change. Anyway, it would be interesting that Continuous Integration could warn that an error compiling a dependency has happened.

Meetings

Background

These ideas have grown out of a presentation (CI BoF 2006) and a subsequent discussion at GUADEC 2006.

Contact us

You can contact us through:

Who are we?

2024-10-23 11:00