Email list hosting service & mailing list manager

Continuous Integration, markdown and Makefile Amirouche Boubekki (20 Apr 2019 11:52 UTC)
Re: Continuous Integration, markdown and Makefile Marc Nieper-Wi├čkirchen (20 Apr 2019 12:10 UTC)
Re: Continuous Integration, markdown and Makefile Amirouche Boubekki (20 Apr 2019 12:18 UTC)
Re: Continuous Integration, markdown and Makefile Lassi Kortela (20 Apr 2019 12:38 UTC)
Re: Continuous Integration, markdown and Makefile Amirouche Boubekki (20 Apr 2019 12:51 UTC)
Re: Continuous Integration, markdown and Makefile Lassi Kortela (20 Apr 2019 13:05 UTC)
Re: Continuous Integration, markdown and Makefile Amirouche Boubekki (20 Apr 2019 13:16 UTC)
Re: Continuous Integration, markdown and Makefile Lassi Kortela (20 Apr 2019 12:28 UTC)
Re: Continuous Integration, markdown and Makefile Arthur A. Gleckler (20 Apr 2019 23:07 UTC)
Re: Continuous Integration, markdown and Makefile Lassi Kortela (21 Apr 2019 06:25 UTC)
Re: Continuous Integration, markdown and Makefile Frank Ruben (21 Apr 2019 04:35 UTC)
Re: Continuous Integration, markdown and Makefile Lassi Kortela (21 Apr 2019 06:21 UTC)

Re: Continuous Integration, markdown and Makefile Lassi Kortela 21 Apr 2019 06:25 UTC

> tell me what you think of this idea: whenever I add or update an SRFI,
> I'll run a command that will do an HTTP GET from a URL of your choice.
> That URL will encode the SRFI number.  Your code could then sync with
> the Git repository and do whatever you wanted it to do.  Would that be
> enough of a trigger to start whatever remote job you want to start?  The
> command could fetch from several such URLs so that independent systems
> on differentn hosts could be triggered.

This is more or less exactly what the experimental SRFI CI server does.
The GitHub organization-wide webhook makes this incredibly easy (most of
the complexity in the experimental server is related to other things
entirely - in particular, no SQL database is needed to deal with the
GitHub webhook). If we do anything like this, I would just suggest
hooking into that. I imagine GitLab and others have a similar hook.

The hook sends a HTTP POST with JSON about every event that happens to
any repository under the organization. The server then has very simple
code to filter out the events we don't care about.