It would only work If you want "All" your PRs to be "approved". => It would only work If you want "All" your PRs to be "approved" by the GH Actions.
On Tue, Feb 8, 2022 at 4:00 PM Jarek Potiuk <ja...@potiuk.com> wrote: > 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 >> >>>>>> >> >> >> >>
