Let's imagine this scenario:

(master history)
abcd - some commit
hijk - change something

(pull request history)
abcd - some commit
defg - add feature


      master                                  pull request

abcd - some commit           -------      defg - add feature
hijk - change something


Currently in the CI we checkout defg and run the tests. If hijk introduces some change that breaks defg, we only know about it after defg is in master.

I propose pull requests to be automatically rebased on top of master, so that the resulting story becomes:

abcd - some commit
hijk - change something
defg - add feature

Now defg is properly tested :)

This may not be an issue in smaller projects, but in cpython where most things are a moving target, it should make a difference. Here I am referring to master but applies to all other maintained branches.

Github can't merge if the PR doesn't cleanly rebase to master, or rather, it will ask you to resolve conflicts, so I don't think there should be any problem.

Keep in mind that this only works at the time the pull request is created. To check against the latest master the build needs to be retriggered, which you should be able to do manually.
Even if we don't check against the latest master when the PR is merged, this is already an improvement. After this we could look into maybe automatically retriggering the CI on approvals, or better, managing merges with a bot.