Before getting into the feature request, consider the purpose and bigger picture for pull request builds.
- A contributor submits a pull request.
- An owner needs to review the code changes before merging the pull request.
- Part of the owner’s criteria for merging the pull request is seeing the circleci build status go green. This status implies “safe to merge”.
When CircleCI runs a pull request build, it simply pulls the code from the pull request source branch. It does not merge with the target branch. This means that the built code, and therefore the status, does not necessarily apply to whether or not the pull request is “safe to merge”.
Allow me to try to illustrate a scenario:
- Tuesday: User A pulls code locally. He changes a function signature and updates all usages.
- Wednesday: User B pushes code that adds a new usage of this function.
- Thursday: User A submits a pull request with his refactor.
- Note that User A never rebased his change to pick up User B’s new code.
- The CircleCI build passes, because it only pulled the PR source branch.
- The owner merges the PR, and the upstream build fails, because User A’s and User B’s changes are functionally incompatible.
The scenario would be solved if CircleCI would automatically merge the source branch with the target branch during the “checkout” phase of the build.