I would like to propose that when the CI builds artifacts for a pull request, that it first attempts to merge the changes into master, and then those artifacts will be shared to the user.

• On merge failure: the CI will fail and stop, we can't merge the changes anyway when there is a conflict. This should help prevent unnecessary CI builds when the author will have to rebase anyway.
• On successful merge: the artifacts will be built based on this new master branch, the benefits will be that when you test your PR it will be as if it was merged. This will also help the tiger bot give better results when telling you the binary file size change in case the forked repo the pr is based on is behind master.

Alternatively, we could be more flexible and have the CI continue even if the PR can't be merged into master yet and have the bot add a message telling them to resolve the merge conflict. At the moment I prefer the fail if there is a conflict approach, but open for discussion.