I'm presupposing that the salt configuration management system is setup and configured to deploy the latest version from 'master' via a state called 'projects.blog'.
First we need to setup the webhook tool
Next we need to configure it to run our configuration management tool when certain events are reported by Gitea - this is done by modifying the /etc/webhook.conf file (replace 'SECRET_KEY_GOES_HERE' with the actual secret key): and restarting the service:
Finally we need to configure our repostory to trigger the webhook. The target URL should be "http://localhost:9000/hooks/deploy-blog" (unless you configured webhook to listen at a non-default place) and the Secret match what you put in the "value" for the "secret" parameter in the /etc/webhook.conf file:
Webhook runs as root by default on Debian, which feels like an unnecessary security risk however as the only things that it runs are explicitly configured (including all their arguments) then, with only allowing it to listen on private interfaces (loopback on the Gitea host and possibly a VPN interface, see below, for remote use) and the firewall in place, this feels like a managed risk even if there were a secuirty flaw in webhook itself.
All in all, this has been very straightforward - I think my next step will be to do the same to update the salt configuration on my 'salt master' when the 'master' branch of the salt configuration repository is modified. This should be straightforward again, as there is already a VPN connection between the web-server and that machine so I can add a new webhook instance listening on the VPN interface and Gitea can remotely use that webhook service on the salt master itself.
...and yes, this post was published via this method.