So I have done my penance for failing to set up a cron to run testing. I've got routine testing going every night on 2 boxes. It seems solid. I see that many others have done this as well - test.winehq.org wine results are really looking good. As promised, I'm attaching the script I'm using. This is my crontab line: 06 02 * * 2-6 /home/jwhite/bin/winetestcron --repo /home/jwhite/w/wine/.git --tag jw-nv-32 e.g. run the script at 2:06 am Tuesdays through Saturdays. I don't want this to be a general call for everyone to run this script; rather, this might be a handy tool for developers who are already running winetest to save them a little hassle. My script probably has only one materially useful feature - it uses a trap to enforce a timeout. The rest is all pretty easy/obvious stuff. Also, I've only tested on Linux, not Mac. Sorry :-(. Cheers, Jeremy #!/bin/bash #---------------------------------------------------- # winetestcron # script to run the Wine tests in an unattended fashion # Intended to be run from cron. If you run it in the # crontab of the user that is logged in to DISPLAY :0, # it should work. Otherwise, you might want to do a # xauth extract /your/file in your .xsession, and an # xauth merge /your/file in this script. #---------------------------------------------------- function usage() { echo -n "$0 --repo /path/to/your/.git/dir " echo "[--tag tag-to-report] " echo -n " [--gecko gecko-path] " echo "[--timeout secs] [--update-repo]" echo " [--configure extra-configure-args]" echo "repo is mandatory, must give the location of a .git directory, and " echo "will not be changed by default. If you specify update-repo, then a " echo "git fetch will be done in your repository before running winetest. " echo "The working tree will not be changed in any case." echo "tag is the tag name to report; see common tags on test.winehq.org for guidance." echo "timeout sets an overall script timeout, in seconds. Default is $TIMEOUT" echo "gecko specifies a path to the Gecko CAB file. Default is $GECKO_LOCATION" echo "configure will pass through the options to ./configure" } function parse_args() { GOPT=`getopt -o "" -l repo:,tag:,gecko:,timeout:,configure:,update-repo -- "$@"` GOPTERR=`getopt -o "" -l repo:,tag:,gecko:,timeout:,configure:,update-repo -- "$@" 2>&1` eval set -- "$GOPT" if [ $? != 0 -o "$GOPT" != "$GOPTERR" ] ; then usage exit 1 fi while true ; do case "$1" in --repo) export REFERENCE_GIT="$2"; shift 2;; --tag) export TAG="$2"; shift 2;; --gecko) export GECKO_LOCATION="$2"; shift 2;; --configure) export CONFIG_EXTRAS="$2"; shift 2;; --update-repo) export UPDATE_REPO="y"; shift;; --) shift; break;; *) echo "Error: uknown option $@"; usage ; exit ;; esac done if [ $# -gt 0 ] ; then echo "Error: Unexpected parameters $@" usage exit 1 fi if [ ! -d "$REFERENCE_GIT" ] ; then echo "Error: --repo must point to the .git directory of a valid WineHQ clone." usage exit 1 fi } function cleanup { "$TESTDIR/wine/server/wineserver" -k find /tmp -maxdepth 1 -type d -name 'winetest*' -ctime +2 -exec rm -rf {} \; exit } #--- # Set defaults #---- export GECKO_LOCATION=/usr/share/wine/gecko/ export TIMEOUT=3600 export TAG=`echo -n \`whoami\`-\`uname -m\` | sed 's/_/-/g'` #--- # Validate arguments #---- parse_args "$@" #--- # Get going... #---- TESTDIR=`mktemp -d /tmp/winetest.XXXXXXXX` TMPGITDIR="$TESTDIR/wine" mkdir "$TESTDIR/gecko" if [ -f "$GECKO_LOCATION/wine_gecko-1.0.0-x86.cab" ] ; then cp "$GECKO_LOCATION/wine_gecko-1.0.0-x86.cab" "$TESTDIR/gecko/" else echo $GECKO_LOCATION/wine_gecko-1.0.0-x86.cab not found. Bandwidth being wasted... ( cd "$TESTDIR/gecko" ; \ wget -o "$TESTDIR/wget.log" http://downloads.sourceforge.net/wine/wine_gecko-1.0.0-x86.cab \ ) fi if [ "$UPDATE_REPO" = "y" ] ; then git "--git-dir=$REFERENCE_GIT" fetch origin fi git clone --reference "$REFERENCE_GIT" git://source.winehq.org/git/wine.git "$TMPGITDIR" >"$TESTDIR/clone.log" 2>&1 cd "$TMPGITDIR" (./configure "$CONFIG_EXTRAS" && nice make ) > "$TESTDIR/build.log" 2>&1 export WINEPREFIX="$TESTDIR/.wine" export PATH="$TMPGITDIR:$PATH" export DISPLAY=:0 cd "$TESTDIR" # Set a trap to cleanup when a child exits. We either exit when # the Wine tests are complete, or the timeout happens; whichever # comes first set -m trap cleanup CHLD # Run the actual tests "$TMPGITDIR/wine" "$TMPGITDIR/programs/winetest/winetest.exe.so" -c -t "$TAG" >wine.log 2>&1 & # Set a timer to force an exit after $TIMEOUT sleep $TIMEOUT
On Wed, Nov 25, 2009 at 10:33 AM, Jeremy White <jwhite(a)codeweavers.com> wrote:
So I have done my penance for failing to set up a cron to run testing. I've got routine testing going every night on 2 boxes. It seems solid.
I see that many others have done this as well - test.winehq.org wine results are really looking good.
As promised, I'm attaching the script I'm using.
This is my crontab line: 06 02 * * 2-6 /home/jwhite/bin/winetestcron --repo /home/jwhite/w/wine/.git --tag jw-nv-32 e.g. run the script at 2:06 am Tuesdays through Saturdays.
I don't want this to be a general call for everyone to run this script; rather, this might be a handy tool for developers who are already running winetest to save them a little hassle.
My script probably has only one materially useful feature - it uses a trap to enforce a timeout. The rest is all pretty easy/obvious stuff.
Also, I've only tested on Linux, not Mac. Sorry :-(.
I really wish you had said something to me before..I've been cleaning my script up, with some help from Vincent. It's pretty similar, but a bit more advanced (and supports Linux, BSD, Solaris and supposedly Mac, but that's untested): http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh By default, just running: $ sh daily.sh will test for $HOME/wine-git, run git fetch in it, then clone it to a temp directory, run make and winetest.exe in that directory, then remove the temp directory. Gecko is handled automatically, similar to yours. If $HOME/wine-git doesn't exist (you can override that directory with the $WINEGIT environmental variable), then it will run a git clone --depth 1 for you. The tag is also handled in a similar way, overridable, but by default will use the username and hostname of the machine. What I've done a bit different is allowing for some different testing configurations: WINEDEBUG=+heap, oss, esound, jack, pbuffer, backbuffer, glsl-disabled, virtual desktop, etc. The other neat thing is that it will run git fetch in a loop every 30 minutes (again, overridable), so that you can run it in the morning while waiting for AJ to commit. Once commits are made to the git master branch (but not stable), the script will kick into motion. I'm not depending on others to run this script, but if anyone does use it and find it useful, please send me any bug reports or file them on winezeug. I'm using this daily on my Linux box, but would love to see this being used daily on a FreeBSD/Solaris/OS X box (though I think a couple people are now submitting OS X results daily, so not as big of a deal there). -- -Austin
On Wed, Nov 25, 2009 at 12:08 PM, Austin English <austinenglish(a)gmail.com> wrote:
On Wed, Nov 25, 2009 at 10:33 AM, Jeremy White <jwhite(a)codeweavers.com> wrote:
As promised, I'm attaching the script I'm using.
I really wish you had said something to me before..I've been cleaning my script up, with some help from Vincent. It's pretty similar, but a bit more advanced (and supports Linux, BSD, Solaris and supposedly Mac, but that's untested):
http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh
It looks like you guys might benefit from my own project, gitbuilder: http://github.com/apenwarr/gitbuilder/ It does pretty much what you're describing (including a timeout), but with a few added features: - you can build any program, not just wine, and test it using a shell script of your choosing - you can run it as often as you want, and it'll build the latest commit on *all* branches and tags - it avoids an unnecessary extra 'git clone' and uses 'git clean -fdx' instead - the test script can return a pass/fail exit code, and if it fails, gitbuilder will automatically 'git bisect' to find the commit that introduced the problem. That last one is a huge benefit for our group, although of course if your tests don't ever 100% pass, it's not as useful :( Some example output for one of my company's projects: http://versabanq.com/demo/build/versaplex/ Have fun, Avery
On Wed, Nov 25, 2009 at 12:08 PM, Austin English <austinenglish(a)gmail.com> wrote:
The other neat thing is that it will run git fetch in a loop every 30 minutes (again, overridable), so that you can run it in the morning while waiting for AJ to commit. Once commits are made to the git master branch (but not stable), the script will kick into motion.
It would be nice to dummy email account subscribed to the commit messages that it could poll to trigger the checkout, build, test cycle. To make a Continuous Integration Service around it it should run as a background process under another user out of init in a Xnest/VNC session. I am thinking something like a winecis user which would run these scripts, fetch and the Xnest session as a service we could call winecis. I did something similar recently for a stupid java service that had to have an interactive gui. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Wed, Nov 25, 2009 at 5:21 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
It would be nice to dummy email account subscribed to the commit messages that it could poll to trigger the checkout, build, test cycle.
To make a Continuous Integration Service around it it should run as a background process under another user out of init in a Xnest/VNC session. I am thinking something like a winecis user which would run these scripts, fetch and the Xnest session as a service we could call winecis.
I did something similar recently for a stupid java service that had to have an interactive gui.
Thinking about it a bit more, I guess the email thing is kind of redundant since git can poll more often. I guess it really depends on how many build agents you want to have hanging out hammering git. To you want them to hammer git or hammer your mail server? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
On Wed, Nov 25, 2009 at 5:24 PM, Steven Edwards <winehacker(a)gmail.com> wrote:
To make a Continuous Integration Service around it it should run as a background process under another user out of init in a Xnest/VNC session. I am thinking something like a winecis user which would run these scripts, fetch and the Xnest session as a service we could call winecis.
I did something similar recently for a stupid java service that had to have an interactive gui.
Thinking about it a bit more, I guess the email thing is kind of redundant since git can poll more often. I guess it really depends on how many build agents you want to have hanging out hammering git. To you want them to hammer git or hammer your mail server?
Checking git every few minutes for new revisions costs basically zero, in the event that there are no new revisions. BTW, gitbuilder can do this sort of thing for you. It also provides an rss feed of build results. Avery
On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote:
On Wed, Nov 25, 2009 at 12:08 PM, Austin English <austinenglish(a)gmail.com> wrote:
The other neat thing is that it will run git fetch in a loop every 30 minutes (again, overridable), so that you can run it in the morning while waiting for AJ to commit. Once commits are made to the git master branch (but not stable), the script will kick into motion.
It would be nice to dummy email account subscribed to the commit messages that it could poll to trigger the checkout, build, test cycle.
To make a Continuous Integration Service around it it should run as a background process under another user out of init in a Xnest/VNC session. I am thinking something like a winecis user which would run these scripts, fetch and the Xnest session as a service we could call winecis.
I did something similar recently for a stupid java service that had to have an interactive gui.
As AJ is pushing just once a day you can also run your fetch script once a day... Perhaps triggered by a commit mail. Ciao, Marcus
On Wed, Nov 25, 2009 at 4:45 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote:
On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote:
On Wed, Nov 25, 2009 at 12:08 PM, Austin English <austinenglish(a)gmail.com> wrote:
The other neat thing is that it will run git fetch in a loop every 30 minutes (again, overridable), so that you can run it in the morning while waiting for AJ to commit. Once commits are made to the git master branch (but not stable), the script will kick into motion.
It would be nice to dummy email account subscribed to the commit messages that it could poll to trigger the checkout, build, test cycle.
To make a Continuous Integration Service around it it should run as a background process under another user out of init in a Xnest/VNC session. I am thinking something like a winecis user which would run these scripts, fetch and the Xnest session as a service we could call winecis.
I did something similar recently for a stupid java service that had to have an interactive gui.
As AJ is pushing just once a day you can also run your fetch script once a day... Perhaps triggered by a commit mail.
Sure, that would be an option if the system has e-mail configured, but since I use webmail, I went with the 'sit and wait' method. For other projects that script would obviously need a different strategy (though I don't other projects are running winetest.exe daily ;-)). -- -Austin
2009/11/25 Austin English <austinenglish(a)gmail.com>:
On Wed, Nov 25, 2009 at 4:45 PM, Marcus Meissner <marcus(a)jet.franken.de> wrote:
On Wed, Nov 25, 2009 at 05:21:30PM -0500, Steven Edwards wrote:
On Wed, Nov 25, 2009 at 12:08 PM, Austin English <austinenglish(a)gmail.com> wrote:
The other neat thing is that it will run git fetch in a loop every 30 minutes (again, overridable), so that you can run it in the morning while waiting for AJ to commit. Once commits are made to the git master branch (but not stable), the script will kick into motion.
It would be nice to dummy email account subscribed to the commit messages that it could poll to trigger the checkout, build, test cycle.
To make a Continuous Integration Service around it it should run as a background process under another user out of init in a Xnest/VNC session. I am thinking something like a winecis user which would run these scripts, fetch and the Xnest session as a service we could call winecis.
I did something similar recently for a stupid java service that had to have an interactive gui.
As AJ is pushing just once a day you can also run your fetch script once a day... Perhaps triggered by a commit mail.
Sure, that would be an option if the system has e-mail configured, but since I use webmail, I went with the 'sit and wait' method. For other projects that script would obviously need a different strategy (though I don't other projects are running winetest.exe daily ;-)).
-- -Austin
You could watch http://test.winehq.org/builds/ to see if there is any update (a push is followed by a test build). -- Nicolas Le Cam
On Wed, Nov 25, 2009 at 5:48 PM, Austin English <austinenglish(a)gmail.com> wrote:
Sure, that would be an option if the system has e-mail configured, but since I use webmail, I went with the 'sit and wait' method. For other projects that script would obviously need a different strategy (though I don't other projects are running winetest.exe daily ;-)).
Having the private vncserver or Xnest session is more important than the polling method. You should be able to turn your script in to a proper service without much trouble, the following psudo-init script is a snippet of the serivce I wrote. start() { echo -n $"winecis spam" /usr/bin/vncserver -geometry 1152x900 -depth 16 :$DISPLAY >> /var/log/vncserver.log 2>&1 doaustinswinecismagic RETVAL=$? echo [ $RETVAL = 0 ] return $RETVAL } stop() {..} restart() {..} etc,etc... -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
participants (6)
-
Austin English -
Avery Pennarun -
Jeremy White -
Marcus Meissner -
Nicolas Le Cam -
Steven Edwards