> On Mar 30, 2021, at 5:51 AM, Derick Rethans <der...@php.net> wrote: > > On 30 March 2021 10:43:41 BST, Max Semenik <maxsem.w...@gmail.com> wrote: >> On Tue, Mar 30, 2021 at 3:29 AM Stanislav Malyshev >> <smalys...@gmail.com> >> wrote: >> >>> Hi! >>> >>> On 3/29/21 4:49 AM, Max Semenik wrote: >>>> Would it also make sense if direct pushes (bypassing the pull >> requests >>>> system) were disallowed completely? I can see multiple problems >> with >>> direct >>>> pushes: >>> >>> This is possible. In fact, there are Git bots that make it easier >> (e.g. >>> prow: https://github.com/kubernetes/test-infra/tree/master/prow) - I >> am >>> using such system over Github at my $DAYJOB and it's generally >> working >>> well. It even has its own built-in karma-like system. However, it has >>> some downsides, as the experience shows: >>> >>> 1. Quick management patches, typofixes, release management patches, >> etc. >>> become more high friction processes. >>> 2. Setup and configuration of such system involves some time >> investment >>> by some knowledgeable people, and it has certain learning curve >> (though >>> once it is set up, it's pretty easy to use). >>> 3. Somebody knowledgeable needs to maintain it, as periodically bots >> can >>> get stuck and need a gentle kick to continue. >>> 4. CI needs to be very stable and clean for having CI pass as gateway >> to >>> merge, otherwise a flaky test can block all work in the repo for >> days. >>> 5. Managing multiple active branches can be a pain. >>> >>> None of these are critical, and we could start small and build it >>> incrementally, of course. >>> >> >> We don't even have to use bots - GitHub allows you to require passing >> CI >> and/or approving reviews to merge. > > How well does that work for merging up fixes from an older bug fix branch up > through PHP 7.4, PHP 8.0, and then into master? > > Or for things like new timezone definitions, which is now automated, and > would then require a pointless PR?
Accepting some PRs can be automated. Repos can be protects on Github via per-branch rules[1] where permissions and requirements can be assigned. PRs are actually a foundational component of GitOps[2] which is an emerging best practice for managing infrastructure. It was initially for Kubernetes deployments but has become recognized as being beneficial[3] for automating software CI/CD[4] and other workflows. I have actually been developing GitOps pipelines for my current client since February. If you are unfamiliar with GitOps you might consider reading about from the links below? ---------------- Also, I just googled and found these, so I cannot endorse them having never used them, but they apparently show what can be done with GitHub PR and Merge Automation: — Bulldozer is an auto-merge bot: https://github.com/palantir/bulldozer <https://github.com/palantir/bulldozer> — BorsNG is a merge bot for GitHub pull requests https://bors.tech/ — Policy-bot evidentially allows merge rules to be declaratively specified, a real plus because then everyone who needs to know could see how the approval process works and who has access, at least by group: https://github.com/palantir/policy-bot <https://github.com/palantir/policy-bot> — Heres a simply article showing how to automate with Javascript and Probot: https://freeletics.engineering/2019/09/09/automating-your-github-routine.html <https://freeletics.engineering/2019/09/09/automating-your-github-routine.html> Hope this helps. -Mike [1] https://docs.github.com/en/github/administering-a-repository/managing-a-branch-protection-rule [2] https://www.weave.works/technologies/gitops/ <https://www.weave.works/technologies/gitops/> [3] https://www.gitops.tech/ <https://www.gitops.tech/> [4] https://harness.io/blog/devops/what-is-gitops/ <https://harness.io/blog/devops/what-is-gitops/> > > It sounds like an annoying hurdle. > > cheers, > Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
