Assuming the following git commits in master (we use pull requests, but the below is simpler to reproduce the problem):
$ git clone <my_repo> my_repo
$ cd my_repo
$ git checkout master
$ for delta in 17 34 68; do # touch & commit a file and then sleep for $delta
f=$(date +%H%M%S)-$delta # hhmiss dateformat
touch $f
git add $f
git commit $f -m"timestamped file $f"
sleep $delta
done
$ git push origin
And there is a builder with a GitPoller
with pollInterval=60, usetimestamps=False
This push results in 2 builds being triggered:
I would like to configure buildbot (0.8.10) so that for one push (or merge request) there is only a single build triggered.
What I've looked so far:
pollInterval
is nice, but with a merge requests, potentially tons of commits come into master in a short timeUse a scheduler that has treeStableTimer
set to the time span during which you want the scheduler to wait until the tree is no longer changing. For instance SingleBranchScheduler
supports it. It is described as follows:
treeStableTimer
The scheduler will wait for this many seconds before starting the build. If new changes are made during this interval, the timer will be restarted, so really the build will be started after a change and then after this many seconds of inactivity.
If
treeStableTimer
isNone
, then a separate build is started immediately for each Change.
I use a SingleBranchScheduler
with a 5-minute timer, and it works very nicely. As long as I'm committing, no build is started. If I stop for 5 minutes, then a build starts.
I happen to be using git too but this solution should work with any version control system.