Re: build.gnome.org

[Colin Walters <walters verbum org>]

On Sun, 2012-12-30 at 19:43 +0100, Cosimo Cecchi wrote:
> Exactly, often a module was "red" because it needed a "git clean",

See https://bugzilla.gnome.org/show_bug.cgi?id=656081

I wrote that patch specifically for use in autobuilders.  A lot of the
reliability of the gnome-ostree build system versus jhbuild comes from
*always* starting from a git clean -dfx tree; by using the --distclean
option, jhbuild too can be a lot more reliable.  (At a cost of some
compilation speed, but if you're worried about that, first install
and configure ccache)

>  for a missing dependency, or because the moduleset wasn't updated to
> include a newer version of a dependency.

Both of these are blocked on a sustainable way for multiple people
to control the base set of packages installed on the build servers; see
my other mail.

> Finally, when a new module was added to the moduleset (usually a new
> dependency), the build.gnome.org master instance itself needed a
> manual restart to get the change propagated to the build slaves, and
> this required pinging people with a SSH access to the server to do it.

Honestly, the jhbuild-buildbot integration is well intentioned, but not
worth the pain.

It'd be *significantly* simpler and more reliable if a jhbuild-based
build bot was effectively:

while true; do sleep 1m; jhbuild build || post-irc-message; done

Basically all of the jhbuild-buildbot glue work is so that modules can
be in a build-or-not-building state *independently*, but that doesn't
make any sense because we want to act aggressively on any failures - we
don't want to let e.g. at-spi2-atk be in a failing state but still build
gtk+.