Ammar Askar <am...@ammaraskar.com> added the comment: Just like Travis, Github actions also automatically rebases pull requests onto the latest master. As you can see from a recent workflow run, it uses the special ref: "refs/remote/pull/20047/merge" https://github.com/python/cpython/pull/20047/checks?check_run_id=665377507#step:2:898
What is this ref that Github provides? https://git-scm.com/book/en/v2/GitHub-Maintaining-a-Project > There’s also a refs/pull/#/merge ref on the GitHub side, > which represents the commit that would result if you push > the “merge” button on the site. This can allow you to test > the merge before even hitting the button Unless there's real world examples of ongoing problems with PRs being merged with outdated test runs, I don't think this is worth complicating our CIs for. As Inada-san mentioned, the occasional slip through will eventually be caught by the buildbots and promptly reverted. Re-triggering the CI for very stale pull requests might be worth doing. I'm kinda opposed to an automated system because this creates an undue burden on our CI providers, Travis graciously provides us with extra time for our coverage builds to finish already. Re-running pull requests that might never be merged is a lot of added work for them. Maybe we can get one of the bots to tag old pull requests and then have some guidance in the core-dev guide to re-run the CIs manually when merging those PRs. ---------- nosy: +ammar2 _______________________________________ 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
