There was a weird case on our build server.
A single commit triggered a commit build and a PR build, which kicked off at the same time. They both show the same commit hash on the UI.
However the commit build passed, the PR build failed, because the changes of this commit did not reflect in the PR build yet. After manually restarting the PR build, it succeeded.
I digged a bit in how Drone does the clone step:
commit builds do a “git reset --hard” on the git hash, so no room for error
while PR builds just go on the merge HEAD:
* branch refs/pull/361/merge -> FETCH_HEAD
git checkout -qf FETCH_HEAD
My explanation on the described behavior, that if this merge HEAD lags behind, we get inconsistent builds.
Does anyone seen similar before?
This is a known issues with CI systems like Drone, Travis, Apveyor, etc which use the merge ref to clone the pull requests. There are plans to change the pull request clone logic in a future release, which is discussed in the following thread:
I am planning to change how we clone GitHub pull requests in a future version of drone. The below script demonstrates what this new logic will look like:
git clone -b master --single-branch https://github.com/octocat/Spoon-Knife.git \
git fetch origin pull/14596/head:
git rebase 26923a8f37933ccc23943de0d4ebd53908268582
Improved error when merge conflicts exist
Uses the correct sha for pull …
Fantastic, thanks for the answer Brad. It does make me more comfortable.