New submission from Filipe Laíns <filipe.la...@gmail.com>:
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.
----------
components: Build
messages: 368371
nosy: FFY00
priority: normal
severity: normal
status: open
title: PRs should be rebased on top of master before running the build/tests
type: enhancement
versions: Python 3.9
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue40551>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
