I don't have access to a GitHub webhook, so I attempted to duplicate the problem from a simple webhook from a bare git repository. I think I may have seen the failure in about 1 in 20 builds. Here are the steps I tried:
- Configure a job with Git as SCM using git://mark-pc1.markwaite.net/git/mwaite/bin.git as the URL
- Enable concurrent execution of the job
- Set quiet period to 0
- Limit the job to execute on any of 12 different slaves (windows || linux)
- Enable SCM polling but do not set any polling value (so that notifyCommit is primary way to start job)
- Add an Xshell build step "git log -n 1"
- Poll now with the job to run the first build
- Commit a change to the bare repository, confirm the change is detected and job runs once and only once
- Create a fast commit loop which pushes a series of changes to the bare repository
for a in 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
do
date >> README.md && git add README.md && git commit -m "Add $(date) to README" && git push
done
I ran that tight loop multiple times then compared the SHA1 of many builds and their predecessor builds. In the 100+ builds that were run, about 1 in 20 showed the preceding job using the same SHA1 hash as the running job.
This does not happen all the time, but frequent enough to be annoying.
Occasionally I notice that all executors are building the same branch/same sha.