[vlc-devel] buildbot test farm

[Rafaël Carré]

Le 2012-01-28 13:40, Jean-Baptiste Kempf a écrit :
> On Sat, Jan 28, 2012 at 11:50:19AM -0500, Rafaël Carré wrote :
>> What the bots were deployed for does not matter, we can use as a tool
>> for whichever purpose we want.
> 
> The cool thing would be to be able to give the buildbots a patch and see
> how it fares.

And it's live!

We have added a new repository vlc/vlc-test.git which is monitored by
buildbot and will trigger a build when changes are pushed in.

You should not pull from this tree because it might contain all sort of
untested crap.


Here is how to use it:

#
### Add the repository to your tree
#
git remote add vlc-test git://git.videolan.org/vlc/vlc-test.git
git fetch vlc-test                   # fetch repository
git checkout -b test vlc-test/master # create remote-tracking branch
git checkout master                  # go back to normal things


# When ever you have a patch to test:


git pull                  # sync with vlc.git
git checkout test         # checkout your test branch
git reset --hard master   # reset to the same point than master
git am ~/doubtful.patch   # apply the patch(es) you want to test

git push --force vlc-test test:master # send the patches

Command line options break-down:

* --force 	= forces non fast-forward history, you want to remove the
crap that was in the repository before your push
* vlc-test 	= the name of the remote repository (vlc-test.git)
* test:master	= merges local branch test in remote branch master


Then you can see the results on http://buildbot.videolan.org

The most interesting page I think is http://buildbot.videolan.org/grid ,
it will show your commit on the rightmost part of the page (wait for the
yellow builders to turn green or red).


It is only available for push to vlc team (people allowed to push in
vlc.git).




The builders use the continuous update mode, they have the same name
(suffixed with '-test') and options than their vlc.git counterparts
except for the clone url.

That also means that the build directory is not cleaned for a new build
so they should be relatively fast to complete.

Try to not commit when there is already a build occuring for vlc.git or
a nightly build, else all the builds could slow to a crawl.

This holds especially true for altair which is already very busy with:

win32, win64, linux32, linux64, wince, android, their nightly builds;
and the source/dist nightly builds.



Today I added a processes limit of 100 for the ftp server on jones which
handles windows crash reports (that means it now should be started
through launchd and not by the GUI); so if jones proves to be stable
again we could move at least source/dist builds there, and perhaps a
windows buildbot or both.