Maybe, but Git has hooks. The author could deploy on push to do it only when needed, and immediately when relevant, rather than having to decide on a trade-off between immediacy and doing a lot of useless operations.
Obviously, this approach might not work for everyone, but I like to self-host my repos and use a git hook (post-receive) like this:
#!/bin/sh
BUILDDIR=/home/buildhook/.ib-build
BUILD=`grep build |cut -d" " -f2`
if [ -n "$BUILD" ]
then
touch $BUILDDIR/$BUILD
fi
And then the buildhook user has a job that runs every minute by cron:
#!/bin/sh
BUILDDIR=/home/buildhook/.ib-build
BUILD=`ls -t $BUILDDIR | head -1`
if [ -n "$BUILD" ]
then
rm -f $BUILDDIR/$BUILD
(
echo Building $BUILD on builder...
ssh builder time ./build $BUILD
) 2>&1 | mail -s "Building $BUILD on builder" build@example.com
fi
For my use case, on this repo, pushing to a branch with the word "build" in its name will trigger a build of that commit, which builds and packages it into a dpkg, and the build server hosts a private apt repository so I can just `apt-get update; apt-get install blah` on all the servers.
An alternative strategy is pushing to a different repo on a build server, etc.
I guess that would have been fine if we didn't have alternatives (ie: callbacks). He is already running a web server, so he could listen through that for updates.