Friday I updated some .drone.yml settings and docker images. Today someone made a PR from an out of date branch with the old .drone.yml settings, and it failed due to this (their PR didn’t change .drone.yml).
My current answer to the user was “rebase off master, and repush” which lacks something in a customer service aspect.
How can I influence the clone step of our pipelines to replay the PRs commits off latest Master? I believe Jenkins calls this a “merge commit”. Obviously if there’s a merge conflict, this should fail the whole pipeline.
Here is the clone output for a real pull request (taken from cloud.drone.io)
+ git fetch origin +refs/heads/master:
* branch master -> FETCH_HEAD
* [new branch] master -> origin/master
+ git checkout master
Branch 'master' set up to track remote branch 'master' from 'origin'.
Already on 'master'
+ git fetch origin refs/pull/2699/head:
* branch refs/pull/2699/head -> FETCH_HEAD
+ git merge 740c2b469d1ae9919cd9a27d0299bd8ca7633e1d
It is import to note, however, that the Yaml is retrieved using the GitHub Contents API before the code is cloned and it uses the /head ref and commit sha for the pull request as input parameters to the API. GitHub does create a /merge ref for pull requests, however, it is unreliable and often fails and we were explicitly told by github  that it should not be used by third party systems.
The /merge refs that are being used here are an undocumented feature and you shouldn’t be relying on them. That feature was build to power Pull Requests in the Web UI, it was not built to be used by 3rd party services. Because it’s undocumented – you should not have any expectations about behavior, the behavior might change at any time and those refs might completely go away without warning.