Hi Felix and Arun,

On 2023-11-28 00:24, Arun Isaac wrote:
> It's already possible to write the deploy-hook as a G-expression
> constructed script (using program-file) that invokes multiple hooks in
> succession. Something like:
> 
> (program-file "deploy-hook"
>   (with-imported-modules '((guix build utils))
>     #~(begin
>         (use-modules (guix build utils))
> 
>         (invoke "/some/hook")
>         (invoke "/some/other/hook"))))

Indeed, and for the record mine looks like this:

--8<---------------cut here---------------start------------->8---
(program-file "certbot-hook.scm"
  ;; source-module-closure not used here because at the time of writing
  ;; (gnu services herd) only uses Guile modules.
  (with-imported-modules '((gnu services herd))
    #~(begin
        (use-modules (gnu services herd))
        (with-shepherd-action 'nginx ('reload) result result)
        (restart-service 'dovecot)
        (restart-service 'smtpd))))
--8<---------------cut here---------------end--------------->8---

(that is, a single hook is responsible for various other shepherd
services)

> Here /some/hook and /some/other/hook can themselves be recursively
> constructed using program-file. So, do we really need a service that
> explicitly accepts multiple deploy hooks?

As Arun pointed out, I don't think multiple deploy hooks would be
adding value here.

What would be interesting though is adding service-extensions support
for certbot-service-type. Roughly speaking, two plausible ways to
achieve this would be:

* Single deploy-hook and ungexp-splicing, i.e.:

--8<---------------cut here---------------start------------->8---
;; service-extension-hooks: list of program-files
#$@(map (lambda (extension-hook)
          #~(invoke #$extension-hook))
        service-extension-hooks)
--8<---------------cut here---------------end--------------->8---

* Multiple --deploy-hook … behind the scenes (the deploy-hook
field in <certificate-configuration> still accepts only a single hook)

Important note, such service-extensions must account for the fact that
they are actually extensions to <certificate-configuration> objects,
i.e. they have to account for which domain(s) is the (deploy/
cleanup/authentication)-hook for.

-- 
Furthermore, I consider that nonfree software must be eradicated.

Cheers,
Bruno.