Re: Core Toolchain Infrastructure - Services for glibc

[Jeff Law <jeffreyalaw@gmail.com>]

On 7/18/23 06:26, Jakub Jelinek via Libc-alpha wrote:
> On Tue, Jul 18, 2023 at 07:47:37AM -0400, Siddhesh Poyarekar wrote:
>> On 2023-07-14 11:34, Konstantin Ryabitsev via Libc-alpha wrote:
>>>> Can we keep using the AdaCore hooks?  Or would they have to run on the
>>>> side somehow?  Who is going to implement changes to the AdaCore scripts?
>>>
>>> This is the main point of contemplation -- we do not currently support custom
>>> hooks on the server side:
>>>
>>> - they tend to significantly slow down pushes
>>> - they run extensive codebases with the same permissions as the owner of the
>>>     repositories, significantly increasing security risks
>>>
>>> Our recommendation was to move all CI tasks to a system that is better suited
>>> for it. For example, CI can run on a patchwork system and the pre-commit hook
>>> can then check that each commit matches a patchwork entry that passed CI.
>>
>> This would mean porting AdaCore hooks to a patchwork trybot.  This would be
>> an acceptable solution for glibc, but I'm not sure how useful this would be
>> on the whole since gcc doesn't use patchwork as extensively at the moment.
>> Also, we need to figure out who's going to do this.
> 
> It is definitely not acceptable for gcc, we strongly rely on server side
> pre-commit hooks for various different tasks.
BUt the key (I think) is they're not trybot/CI style hooks.  They're 
doing things like wiring up commits to the lists/bugzilla, verifying 
ChangeLog bits and the like.

I think the point is that any hooks need serious thought about what they 
do and the attack surface they represent.  So for example firing off 
pre-commit CI, not advisable.  Having a hook that queries another system 
for the state of pre-commit CI may be reasonable.

I would think that verifying ChangeLog format might fall into the 
reasonable space.  Not sure about lists/bz integration hooks.

jeff