This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author FFY00
Recipients FFY00, methane, xtreak
Date 2020-05-09.10:41:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1589020897.58.0.521256323654.issue40551@roundup.psfhosted.org>
In-reply-to
Content
> "Rather than build the commits that have been pushed to the branch the
pull request is from, we build the merge between the source branch and
the upstream branch."

Okay, great. But this still only happens for Linux. And still has the same problem, the build needs to be re-triggered.

> Both are fine, but...

...

> Bot shouldn't use rebase, but merge master branch.
Rebase in pull request branch break the pull request sometime.
See this thread:
https://discuss.python.org/t/info-rebase-origin-master-push-f-workflow-corrupts-pull-request-rarely/2558/7

Okay, so maybe I was not clear enough here. The PR would be rebased locally in the CI runs before building and running the tests. Nothing would ever be pushed. We don't really want users have to pull their branch before making changes, also the users might not give us write access to their branch.

What I am proposing is to do here the same as Travis apparently does, and then maybe figure out a workflow where we (semi-/)automatically  re-trigger the CI, to make everything works correctly with master.

This is a low risk change. Rethinking the core workflow is the difficult part.
History
Date User Action Args
2020-05-09 10:41:37FFY00setrecipients: + FFY00, methane, xtreak
2020-05-09 10:41:37FFY00setmessageid: <1589020897.58.0.521256323654.issue40551@roundup.psfhosted.org>
2020-05-09 10:41:37FFY00linkissue40551 messages
2020-05-09 10:41:37FFY00create