Mike, On 5/10/20 3:29 PM, Michael D Kinney wrote:
There is no difference between CI checks run during code review and the final CI checks before merge. I think it is an interesting conversation to decide how many times those CI checks should be run and if they should run automatically on every change during review or on demand.
I'd suggest following what other Github projects do, which I think is to run the CI checks automatically on every change that's made in a pull request - I don't know if it might also be necessary to run them during the merge, if master has changed in the meantime. That gives the _submitter_ feedback about any changes they need to make, instead of having to wait until the maintainer tells them their change has broken something: it speeds up the development process.
Mergify is more flexible. We want to make sure the git history is linear with not git merges and supports both single patches and patch series without squashing. GitHub merge button by default squashes all commits into a single commit.
Wouldn't disabling all but "Allow rebase merging" do the same thing without the additional potential failure point? Though it sounds like we've resolved the problems with Mergify, so it's not important.
https://help.github.com/en/github/administering-a-repository/configuring-commit-squashing-for-pull-requests -- Rebecca Cran -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#59017): https://edk2.groups.io/g/devel/message/59017 Mute This Topic: https://groups.io/mt/74089163/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
