adacore git-hooks - daemon-mode email vs. systemd-logind linger

adacore git-hooks - daemon-mode email vs. systemd-logind linger

[Frank Ch. Eigler]

Hi, Joel -

As a part of more security review on sourceware, I had recently
experimented with systemd logind's KillUserProcesses=yes option.  It
turns out that this nuked one aspect adacore hooks' post-receive
processing, which create a background process to slowly dribble out
emails.

I restored KilledUserProcesses=no for now, but I'd really like to set
that back.  That means the hooks would have to change.  Here are a
couple of options:

- just send the emails immediately, without the daemon stuff; if the
  delays are there to try to sequentialize them, consider instead
  getting the hooks to emit Message-Id:/In-Reply-To:/Date: headers to
  let MUA's sort properly at reception
  
- invoke the email sending wrapped in a "systemd-run --user"
  deferred execution gadget, including a "sleep XXX" if you must
  keep time-hope-based sequencing

- move email stuff entirely out of the hooks; these repos are "public
  property" anyhow, and we can put cron jobs in place elsewhere to
  trigger email notifications about commits; heck, they could run the
  hook code itself later, just feed it retrospective git-hook lines

- FChE

Re: adacore git-hooks - daemon-mode email vs. systemd-logind linger

[Joel Brobecker]

Hi Frank,

> - just send the emails immediately, without the daemon stuff; if the
>   delays are there to try to sequentialize them, consider instead
>   getting the hooks to emit Message-Id:/In-Reply-To:/Date: headers to
>   let MUA's sort properly at reception

We can certainly add a non-daemon mode to the hooks. I don't know
when I'd have time to work on this enhancement, unfortunately.

> - invoke the email sending wrapped in a "systemd-run --user"
>   deferred execution gadget, including a "sleep XXX" if you must
>   keep time-hope-based sequencing
> 
> - move email stuff entirely out of the hooks; these repos are "public
>   property" anyhow, and we can put cron jobs in place elsewhere to
>   trigger email notifications about commits; heck, they could run the
>   hook code itself later, just feed it retrospective git-hook lines

You can configure the hooks to turn emailing off completely. From
memory, this triggers a warning message on the user end when they do
the push, just to let them know to not expect emails.

The downside of going this way, other than the minor annoyance above,
is that you lose track of who did the push. Right now, the emails
allows you to derive the information from the emails' from field.

Thinking more long term, I think there are talks about using a more
comprehensive system for source and contribution management, similar
to products such as GitLab or GitHub. Those will likely come with
they own set of tooling for things such as alerting, pre-commit
checks, keeping track of who submitted, who reviewed and approved,
and who pushed. That's why I tend to think that, for the moment,
I'd go the simplest route overall: In this case, I think the simplest
is to just have a way to disable the daemon mode, and just have
the users wait. In the vast majority of cases, the wait will be
a few seconds. Even with a patch-series of a 100 patches, it would
mean a 1min40s wait. Very bearable.

If you agree, we can create an issue for it on the git-hooks repoisitory
on GitHub.

-- 
Joel

Re: adacore git-hooks - daemon-mode email vs. systemd-logind linger

[Frank Ch. Eigler]

Hi, Joel -

> [...]  Thinking more long term, I think there are talks about using
> a more comprehensive system for source and contribution management,
> similar to products such as GitLab or GitHub. [...]

(Yeah, but I wouldn't count on any of that in the medium term.)


> [...] That's why I tend to think that, for the moment,
> I'd go the simplest route overall: In this case, I think the simplest
> is to just have a way to disable the daemon mode, and just have
> the users wait. In the vast majority of cases, the wait will be
> a few seconds. Even with a patch-series of a 100 patches, it would
> mean a 1min40s wait. Very bearable.

Right. the EMAIL_DELAY_IN_SECONDS time of 5s could be reduced to 1s,
or even 0.


- FChE