Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113861
Message-ID: <A7687BC9-9457-4E54-93CC-289F95F30EF6@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_BACC223F-A2DB-450E-B207-AC4449D886AC"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Tue, 30 Mar 2021 07:46:48 -0400
In-Reply-To: <E344AED6-17BA-4FC9-9173-17F524C40766@php.net>
Cc: PHP Internals <internals@lists.php.net>
To: Derick Rethans <derick@php.net>
References: <CAF+90c9A6zG-nYzc3NNtWGjN7y5FmwqnYzjq6GSFC5NtRsOT0w@mail.gmail.com>
 <CAGgaK7JywM+aU4YTK3tUr3xjN5746LDoda4SC_=A+msGdWhNyg@mail.gmail.com>
 <6c3d7c13-d7cd-c1cc-5876-2b8c200a017c@gmail.com>
 <CAGgaK7JxmLexnkrt+kLfV47wi=KoeqhnzGjTyrcAQtxemKoSKQ@mail.gmail.com>
 <E344AED6-17BA-4FC9-9173-17F524C40766@php.net>
Subject: Re: [PHP-DEV] Changes to Git commit workflow
From: mike@newclarity.net (Mike Schinkel)

--Apple-Mail=_BACC223F-A2DB-450E-B207-AC4449D886AC
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Mar 30, 2021, at 5:51 AM, Derick Rethans <derick@php.net> wrote:
>=20
> 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:
>>=20
>>> Hi!
>>>=20
>>> 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:
>>>=20
>>> 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:
>>>=20
>>> 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.
>>>=20
>>> None of these are critical, and we could start small and build it
>>> incrementally, of course.
>>>=20
>>=20
>> We don't even have to use bots - GitHub allows you to require passing
>> CI
>> and/or approving reviews to merge.
>=20
> 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?
>=20
> Or for things like new timezone definitions, which is now automated, =
and would then require a pointless PR?=20

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?
=20
----------------

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:

=E2=80=94 Bulldozer is an auto-merge bot:
https://github.com/palantir/bulldozer =
<https://github.com/palantir/bulldozer>=20

=E2=80=94 BorsNG is a merge bot for GitHub pull requests
https://bors.tech/

=E2=80=94 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>

=E2=80=94 Heres a simply article showing how to automate with Javascript =
and Probot:
=
https://freeletics.engineering/2019/09/09/automating-your-github-routine.h=
tml =
<https://freeletics.engineering/2019/09/09/automating-your-github-routine.=
html>=20

Hope this helps.

-Mike

[1] =
https://docs.github.com/en/github/administering-a-repository/managing-a-br=
anch-protection-rule
[2] https://www.weave.works/technologies/gitops/ =
<https://www.weave.works/technologies/gitops/>
[3] https://www.gitops.tech/ <https://www.gitops.tech/>=20
[4] https://harness.io/blog/devops/what-is-gitops/ =
<https://harness.io/blog/devops/what-is-gitops/>


>=20
> It sounds like an annoying hurdle.
>=20
> cheers,
> Derick
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20


--Apple-Mail=_BACC223F-A2DB-450E-B207-AC4449D886AC--