Commits
- Commit:
8bffa12946bc31a810c9a0dc418fc23f0bd227b2
- From:
- Omar Polo <op@omarpolo.com>
- Date:
remove trailing whitespaces
- Commit:
09486e84b6094ffcb4dca9ecd2dea72a982a1fa9
- From:
- Omar Polo <op@omarpolo.com>
- Date:
got-notify-email: bufferize smtp parsing
instead of read(2)ing one byte at the time, use a temporary buffer.
Special care is needed for the regress where all the replies are
queued up-front instead of a real SMTP server where we'd get a reply
only after a command.
ok and improvements stsp@
- Commit:
39910b637a9a53cc48b0c63766da691dec0af593
- From:
- Omar Polo <op@omarpolo.com>
- Date:
got-notify-email: split dial() out of send_email()
This allows to reduce the set of pledge(2) promises needed at runtime
down to only "stdio" which will also help sandboxing -portable.
ok stsp
- Commit:
100d3e4bb875b64f537d67257b0876159b59b068
- From:
- Omar Polo <op@omarpolo.com>
- Date:
mark smtp_timeout as static
- Commit:
dfa6ae4cb7d2e0474c8458b5622eca0385470c01
- From:
- Omar Polo <op@omarpolo.com>
- Date:
fmt
- Commit:
ba97b2d7ec97e54a025a39e04c0fd59fdd54a57b
- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
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@