[llvm-dev] [cfe-dev] [Github] RFC: linear history vs merge commits (original) (raw)

Wyatt Childers via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 4 08:17:25 PST 2019

It's worth mentioning that Travis CI allows open source projects free access to their CI service, and they integrate with Github PRs. ( https://travis-ci.com/plans)

On Sat, Feb 2, 2019 at 9:48 AM Hubert Tong via llvm-dev < llvm-dev at lists.llvm.org> wrote:

On Sat, Feb 2, 2019 at 7:32 AM David Chisnall via cfe-dev <_ _cfe-dev at lists.llvm.org> wrote:

On 1 Feb 2019, at 22:48, Peter Wu via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > On caveat is that the test coverage would be limited or else the build > times would be very long. There are quite some builders for various > projects (llvm, cfe, compiler-rt, etc.) on a lot of different platforms > and targets (Linux, macOS, Windows, Android, etc.). > > With limited resources, Arthur's suggestion seems workable to me: > - Enable pre-commit testing of few configurations (in parallel). > - Encourage developers to wait for tests to pass before pushing changes. > - Do not block hard to avoid a situation where unrelated changes > (commits or build environment) cause failures.

GitHub does let you block merges (by anyone who isn’t an administrator) of PRs that don’t meet certain requirements. For one project, we have it set up so that you need to have at least one reviewer saying approved, you have to have signed the CLA, and you have to pass all of the CI checks. It’s then easy to set up automatic merging when all of the prerequisites are met (you can get a notification and process it automatically). We allow self approval for small changes (not automatically enforced, this is a judgement call, but you can remove people who abuse it from the team quite easily and then they can’t approve changes). I’ve found it leads to a very nice workflow: developers aren’t in the loop for merges, they just prepare something that they think works, submit it, and get on with something else. If you’re lucky, someone approves it and you pass CI first go, then everything is fine. Reviewers can wait until CI is finished and not bother looking for things that are going to break. If the change introduces new tests, reviewers know that those tests are passing. If you broke a platform that you don’t test on locally, you get notified but no one else is spammed with breakage reports. Once you’ve fixed it, you get a review, and make any changes. The master branch is always buildable and passing CI. If your changes break CI, you don’t have a race to fix things before someone reverts your change, you just fix things in the PR and wait for it to be automatically merged. Compared to the current model, the CI in your description operates on more branches. I imagine it uses more machine resources.

David

cfe-dev mailing list cfe-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

LLVM Developers mailing list llvm-dev at lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190204/927d8a5d/attachment.html>

More information about the llvm-dev mailing list