<div dir="ltr"><div dir="ltr">On Thu, Aug 25, 2022 at 7:13 AM David Hurka <<a href="mailto:david.hurka@mailbox.org">david.hurka@mailbox.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wednesday, August 24, 2022 8:11:14 PM CEST Ben Cooksley wrote:<br>
> The limitation is aligned with the maximum number of new commits you are<br>
> allowed to introduce to a standard branch.<br>
> We have those limits because the commit hooks carry out processing on a per<br>
> commit basis for all new commits introduced to standard branches - and are<br>
> there to protect all the other systems downstream from Gitlab.<br>
<br>
Do I understand it correctly like this?<br>
<br>
Standard branches have a merge hook.<br>
The merge hook runs when commits are added to the branch.<br>
(It is assumed that standard branches are not force pushed.)<br>
The merge hook runs for every individual commit.<br>
There is a limit that only 100 commits can be added at once,<br>
to prevent system overloads caused by many merge hooks being ran at once.<br></blockquote><div><br></div><div>It is a little simpler than that.</div><div><br></div><div>For any push to a repository hosted on <a href="http://invent.kde.org">invent.kde.org</a>, a Git hook known as "pre-receive" is invoked by Git on the server.</div><div>This hook is provided by Gitlab itself and first carries out a number of checks needed for Gitlab itself to operate before it then invokes our pre-receive hook.</div><div><br></div><div>Our pre-receive hook as part of it's setup determines whether it is on a mainline or personal repository and what in the repository is being modified (release branch, work branch, tag, etc).</div><div>It checks the content of the push (an operation which is very streamlined) and then if necessary carries out the appropriate notification of our other systems. </div><div><br></div><div>The systems themselves can handle the load fine, however the humans in the spaces they communicate to cannot as:</div><div>a) Bugzilla receives an email for every single mention of BUG / CCBUG within every new commit (which notifies every person CCed on those bugs in turn)<br></div><div>b) An email is sent to <a href="mailto:kde-commits@kde.org">kde-commits@kde.org</a> for every new commit, which floods the list with excessive traffic</div><div>c) A notification is sent to what used to be #kde-commits and #commits on Libera for each new commit (as well as some other channels for certain repositories) so those respective IRC/Matrix channels get flooded and rendered unusable by our announce bots.</div><div><br></div><div>Further, as some email providers impose limits on the number of emails people can receive in short succession this can block delivery of email to people at certain providers (which affects all KDE.org mailing lists, as well as their personal KDE.org/KDEMail.net alias traffic). This essentially denies these people the ability to participate in the community for a period of time.</div><div><br></div><div>Our hook can be found at <a href="https://invent.kde.org/sysadmin/repo-management/-/blob/master/hooks/invent.pre-receive">https://invent.kde.org/sysadmin/repo-management/-/blob/master/hooks/invent.pre-receive</a> for those curious as to what it does.</div><div><br></div><div>Regards,</div><div>Ben</div></div></div>