Commits


expose authenticated gotd user account in HTTP notifications ok op@


fix an fd leak in gotd's notify process This leak resulted in the gotd notify process spinning on CPU in an imsg_read() -> EAGAIN loop once it ran out of file descriptors.


revert part of previous commit; the parent process is not ephemeral pointed out by op@


prevent gotd notification process from exiting due to EPIPE Ephermeral processes on the other end of a pipe might decide to exit which results in EPIPE when writing. This is not a fatal error but is somewhat expected during normal operation (at least until we improve the inter-process communication about notifications).


got-notify-http: use a UNIX timestamp for the date Was suggested by Lucas some time ago. ok stsp@ with a tweak in the manual.


got-notify-http: implement basic authentication ok stsp


got-notify-http: add the repository name in the json ok stsp


add got-notify-http ok stsp@


fmt


display process title in syslog when a gotd child process exits


add initial support for commit notifications to gotd(8) At present only email notifications are implemented. Code for HTTP notifications is not yet finished, hence HTTP-related documentation remains hidden for now. This adds a new 'notify' process which has an "exec" pledge. It runs helper programs which implement the notification transport layer, such as got-notify-email which speaks SMTP. This design avoids having to link all of gotd with network libraries and related crypto libraries. Notification content is generated by the 'repo_write' process. Commit log messages and diffstats are written to a file which the 'notify' process will pass on to its helpers on stdin. The default output looks similar to 'got log -d'. If too many new commits are present the output looks similar to 'got log -s' instead. Tags always look like 'got tag -l'. The session process coordinates generation of notifications. It maintains a notification queue which holds one notification per updated reference, and passes notification requests from this queue to the 'repo_write' process for notification content creation and then to the 'notify' process for notification delivery. Only one notification can be in flight at a time to avoid file descriptor starvation if many references get updated in a single client session. ok op@