On 2022-12-08 at 15:20-05:00, Stefan Monnier wrote:
> How can I configure sr.ht so that it sends an email (ideally containing> the diffs in an attachment) for every push to my repository?
What is your purpose? If it's only to track the latest commit,
subscribing to the branch's RSS feed might be a better idea.
FWIW builds.sr.ht support emailing result, but it'd cost
spawning up a VM every push if you have no other use for CI:
https://man.sr.ht/builds.sr.ht/triggers.md
Nguyễn Gia Phong [2022-12-09 06:12:00] wrote:
> On 2022-12-08 at 15:20-05:00, Stefan Monnier wrote:>> How can I configure sr.ht so that it sends an email (ideally containing>> the diffs in an attachment) for every push to my repository?> What is your purpose?
To see all the changes installed in the repository.
> If it's only to track the latest commit,> subscribing to the branch's RSS feed might be a better idea.
[ My repository is private. Not sure if I can easily get an RSS viewer
that can handle sr.ht's authentication. ]
I haven't found an RSS reader that's quite as convenient as a MUA, and
I'd much prefer to get the diffs themselves directly in the message so
I can read them regardless of my current Internet connectivity.
[ Another reason I'm interested is that I'm playing with sr.ht to see
a bit how it would work for Emacs development, and currently we send
such email notifications to a public mailing list and we'd like to
keep that functionality. ]
> FWIW builds.sr.ht support emailing result, but it'd cost> spawning up a VM every push if you have no other use for CI:> https://man.sr.ht/builds.sr.ht/triggers.md
Hmm... that's a possibility, but it does sound both overkill and
inconvenient, indeed :-(
Stefan
Simon Ser [2022-12-08 21:46:50] wrote:
> The best way to achieve this would be to have a third-party program> install a sr.ht webhook and send emails.
IIUC you're saying that I need to maintain a separate server running
24/7, write a program to run there as a web server that will receive
those webhook notifications and turn them into email, which means that
server needs to keep a local clone of the repository (which in turn
means it needs to be allowed to fetch from the upstream Git), and also
it means it needs to be able to send email legitimately (which nowadays
is becoming non-trivial).
It seems like it would be a lot easier for sr.ht to offer the
possibility to activate something like git-multimail in a post-receive
hook (typically sending to a sr.ht mailing-list).
At least using builds.sr.ht would let me (re)use sr.ht's servers rather
than having to maintain my own (tho I'm not sure how the builds.sr.ht
job would find out what was "the last seen state" so as to know what
diff to send).
Stefan
On Thursday, December 8th, 2022 at 23:30, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> Simon Ser [2022-12-08 21:46:50] wrote:> > > The best way to achieve this would be to have a third-party program> > install a sr.ht webhook and send emails.> > IIUC you're saying that I need to maintain a separate server running> 24/7, write a program to run there as a web server that will receive> those webhook notifications and turn them into email, which means that> server needs to keep a local clone of the repository (which in turn> means it needs to be allowed to fetch from the upstream Git), and also> it means it needs to be able to send email legitimately (which nowadays> is becoming non-trivial).
Yes, in the general case, that's right. sr.ht cannot accommodate for
all possible use-cases. Some people want NNTP, some people want IRC
or Matrix notifications, some people want emails for only Git tags and
nothing else, etc etc.
(I don't believe you'd need a local clone, though.)
>[ Another reason I'm interested is that I'm playing with sr.ht to see> a bit how it would work for Emacs development, and currently we send> such email notifications to a public mailing list and we'd like to> keep that functionality. ]>
For the Emacs case, if you host your own sr.ht instance you could add any git hooks you want to your service. It's not as convenient as getting the hosted service publicly.
>> FWIW builds.sr.ht support emailing result, but it'd cost>> spawning up a VM every push if you have no other use for CI:>> https://man.sr.ht/builds.sr.ht/triggers.md>>Hmm... that's a possibility, but it does sound both overkill and>inconvenient, indeed :-(>
I see it incon\enient if there is no CI indeed. Wouldn't Emacs benefit from some CI for every installed change? That way you could also receive a second email if the change caused a regression.
Regards,
Miguel
>>[ Another reason I'm interested is that I'm playing with sr.ht to see>> a bit how it would work for Emacs development, and currently we send>> such email notifications to a public mailing list and we'd like to>> keep that functionality. ]> For the Emacs case, if you host your own sr.ht instance you could add any> git hooks you want to your service.
Good point. Doesn't help for my own personal use-case, OTOH.
> It's not as convenient as getting the hosted service publicly.
[ My impression is that hosting sr.ht is a fair bit of work, so I'm not
completely sure how that will work: we'd need someone to volunteer to
set it up and maintain it, but I haven't heard anyone step up yet. ]
>>> FWIW builds.sr.ht support emailing result, but it'd cost>>> spawning up a VM every push if you have no other use for CI:>>> https://man.sr.ht/builds.sr.ht/triggers.md>>Hmm... that's a possibility, but it does sound both overkill and>>inconvenient, indeed :-(> I see it inconvenient if there is no CI indeed.
Inconvenient no only in the "extra" work but also in the sense that
AFAICT we don't have enough control to send "nice" email (e.g. I don't
think the diffs could be put in a MIME attachment).
[ Although maybe it's just lack of documentation? ]
> Wouldn't Emacs benefit from some CI for every installed change?
For Emacs, yes. For many of my own repos, no (e.g. ones used to host
research papers).
Stefan
On 2022-12-10 at 10:22-05:00, Stefan Monnier wrote:
> > Wouldn't Emacs benefit from [CI email hook]> > for every installed change?>> For Emacs, yes. For many of my own repos,> no (e.g. ones used to host research papers).
I wonder for private repos like these, if it'd be better to have a
client pre-push hook that formats patches between local and remote
and sends them to collaborators.
Nguyễn Gia Phong [2022-12-11 01:24:53] wrote:
> On 2022-12-10 at 10:22-05:00, Stefan Monnier wrote:>> > Wouldn't Emacs benefit from [CI email hook]>> > for every installed change?>> For Emacs, yes. For many of my own repos,>> no (e.g. ones used to host research papers).> I wonder for private repos like these, if it'd be better to have a> client pre-push hook that formats patches between local and remote> and sends them to collaborators.
I suspect nowadays most people have an email setup which does not allow
a batch script to send email (because of the need for SMTP AUTH).
Stefan