[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Update on the improved buildbot setup

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-06-30 20:38:38 CEST

On Jun 30, 2007, at 10:25 AM, Lieven Govaerts wrote:

> Blair Zajac wrote:
>> Lieven Govaerts wrote:
>>> I want to update you all on the new types of build now added to the
>>> buildbot configuration.
>>> From now on each revision is built and tested for all four ra
>>> layers.
>>> That means the continuous integration setup is:
>>> - the Intel Mac builds and tests ra_neon x fsfs
>>> - on Windows we build and test ra_svn x fsfs
>>> - on Debian Linux we build and test ra_local x fsfs
>>> For ra_serf I added a daily build on the Mac buildslave. The
>>> build is
>>> started every day at 14:00 CEST (=UTC+2). This builder builds both
>>> ra_neon/_serf and the python bindings and runs the testsuite for
>>> ra_serf.
>>> All buildslaves now test with FSFS, so I'm gonna look to change
>>> one to
>>> BDB to have full 4x2 coverage.
>>> As always, you can find the buildbot status page here:
>>> http://www.mobsol.be/buildbot/
>>> I'm sure these improvements will make hacking Subversion more fun
>>> for us
>>> all :)
>> If the buildbot tests each commit and not just the HEAD revision when
>> it goes to do the next build, I think it should send email to the
>> committer who broke a build.
>> For example, when I did the fsfs transaction change, it broke with
>> Windows build. I would not have known.
> It tests the HEAD revision, so typically between 20:00 and 24:00 CEST
> each build includes multiple changesets.

Why not switch to successive revisions. I would rather have a delay
in finding out which exact commit broke the build then skipping

> This is one of the reasons why we originally decided against added the
> committer in CC. The other two being:
> - the builds also fail due to broken network connections between
> master
> and slave, which happens a lot (relatively speaking). Now we also
> include part of the log message in the email making it easier to
> filter
> out such failures so it's not much of an issue

Can we distinguish them from compile and test suite failures, so
don't email them out?

> - fixing a build is not necessarily the responsibility of the original
> committer. I know this might not seem logical to some, but in the
> end I
> prefer to look at it as a shared responsibility. This also ensures
> that
> failed builds are solved soon, instead of people waiting and
> looking at
> the change committer.

I agree, but I would rather have known that Windows was broken, even
though I may not be able to do anything about it, then not know.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 30 20:39:12 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.