> On Mar 30, 2021, at 5:51 AM, Derick Rethans <derick@php.net> wrote:
>
> On 30 March 2021 10:43:41 BST, Max Semenik <maxsem.wiki@gmail.com> wrote:
>> On Tue, Mar 30, 2021 at 3:29 AM Stanislav Malyshev
>> <smalyshev@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
>