IMO this should be configurable. Of course build will need to be done again before merge, but knowing if PR was correct in the first place is important also. IMO, if source branch changes, then yes, a new build should be fired and old one canceled, but changes to target branch cancelling and firing new builds should, at least, be opt-in.

In GitHub, when you open a PR, it keeps track of base branch (the target) only at the time of creation, so, no builds are done if base branch is updated, only if PR branch is updated. For triggering another build, the head (source) branch has to be updated and people do that by merging base branch into the PR branch.

I think pull request build should always run against merged commit of base branch and PR branch. GitHub's approach of forcing user to merge base branch into PR branch in order to run build against merge commit seems inconvenient to me, especially when your merge strategy is rebase/squash.

And when a new pull request build is fired due to base branch being updated, I think it is a waste of resource keeping on running out-dated pull request builds.

Well, if a project has a single owner, maybe, but if there is a project with multiple owners (who can push) and multiple contributors (who can do PR), then it might be better to finish testing the PR before firing a new one. Imagine the build takes long and it is almost finishing, but there is errors that might be detected by CI, then, someone merge a PR to base branch, that build will be cancelled and run all over again, just to report an error at the end. Now imagine this scenario with tens of people working in a project. I think human resources might be more important than computing resources...

In that case, it is a waste of computing resources, instead of human resource. As human should not be waiting for completion of the build. As long as the base branch receives commit frequently, I do not think this is a problem. Let's see how it works in production, and I will adjust the behavior if it really causes problems.

As long as the base branch receives commit frequently

As long as the base branch IS NOT receiving commit frequently

State changed as code fixing the issue is committed

State changed as build #3440 is successful

@markkrj with 8.0 release, new commits in target branch will no longer trigger pull request builds.