Depends on the scheme you choose. It would only work If you want "All" your PRs to be "approved".
But it makes little sense to use "approvals" for that because GitHub Actions have "Checks" which are handling this case (and which Can be done by GitHub Actions). See the difference here: https://pasteboard.co/RoaA64wv4NvH.png J. On Tue, Feb 8, 2022 at 3:42 PM Chesnay Schepler <ches...@apache.org> wrote: > If GA does not approve the PR wouldn't you not want to merge it in the > first place? > Requiring a second committer in that case doesn't sound like such a bad > idea. > > On 08/02/2022 15:29, Jarek Potiuk wrote: > > Yes it is. But you are not able to distinguish commiters vs. GA. So if > you > > set +2 you will need +2 approval from committers when GA does not approve > > it - which is pretty useless if you do not intend to have 2 approvals > from > > committers. > > > > On Tue, Feb 8, 2022 at 3:27 PM Chesnay Schepler <ches...@apache.org> > wrote: > > > >> Is it not possible to control the number of approvals that are required? > >> > >> So if a project has N github actions that verify stuff, then the project > >> configures this to N+1. > >> > >> Admittedly this would mean that every project has use this properly. > >> > >> On 08/02/2022 15:14, Jarek Potiuk wrote: > >>> In short - just to explain why: > >>> > >>> The "protected branches" feature is the way how to make sure that the > >> code > >>> is looked at and approved by at least 1 commiter in order to be merged. > >>> This is a strong protection - not only from UI but also prevents you > from > >>> fast-forward the "prtected branch" to the tip of the branch that has > not > >>> been approved. > >>> Currently, you could write a github workflow (like the one that Michael > >>> pointed at) where you have no human in the loop to approve such change. > >>> GitHub actions run acts as a "commiter" and approval counts as an > >> approval > >>> from committer. Once approved, merge can also happen using the > workflow. > >>> This means that even if you have "protected branch" you could have a > >>> workflow that allows to merge a code that no human looked at in the > >>> "protected branch". > >>> > >>> The settings mentioned by Gavin means that the workflow can still > perform > >>> the approval (this wil continue to work) but it will be equivalent to > >>> non-committer approval (which does not unblock the PR from merging). > >>> > >>> J. > >>> > >>> On Tue, Feb 8, 2022 at 2:40 PM Michael A. Smith <mich...@smith-li.com> > >>> wrote: > >>> > >>>> Not sure if you're asking for in-Apache examples, but GitHub has an > >> example > >>>> here: > >>>> > >>>> > >>>> > >> > https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/automating-dependabot-with-github-actions?learn=dependency_version_updates&learnProduct=code-security#approve-a-pull-request > >>>> > >>>> On Tue, Feb 8, 2022 at 07:34 Gary Gregory <garydgreg...@gmail.com> > >> wrote: > >>>>> Do you have an example of such a GH Action? > >>>>> > >>>>> Gary > >>>>> > >>>>> On Tue, Feb 8, 2022, 07:25 Gavin McDonald <gmcdon...@apache.org> > >> wrote: > >>>>>> Hi All, > >>>>>> > >>>>>> A recent feature pointed out by Jarek : > >>>>>> > >>>>>> > >>>>>> > >> > https://github.blog/changelog/2022-01-14-github-actions-prevent-github-actions-from-approving-pull-requests/ > >>>>>> is to be able to disable GH Actions from approving PRs. > >>>>>> > >>>>>> Infra intends to untick this box and disable this feature. > >>>>>> > >>>>>> Any concerns? > >>>>>> > >>>>>> Anyone uses this feature? If so why. > >>>>>> > >>>>>> -- > >>>>>> > >>>>>> *Gavin McDonald* > >>>>>> Systems Administrator > >>>>>> ASF Infrastructure Team > >>>>>> > >> > >
