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 20 Apr 2019 12:38 UTC

> FWIW, nowdays my go to solution for git hosting is https://man.sr.ht
> it has a Continuous Integration that is modern (unlike travis that is stuck
> with ubuntu 16.04) and is also free software.

That's interesting. I hear GitLab also has built-in CI of some kind.
GitHub doesn't have one AFAIK. Have you used one of those built-in CI
solutions - how easy is it to set up for a new repo?

Easiest would be if we can just put a file like `.travis.yml` in the
repo and then it would perform CI automatically (or push a button in the
repo settings - something like that).

The problem with Travis is, we'd first have to make each SRFI repo in
GitHub as we now do, and _also_ separately add that repo in the Travis
control panel. Travis doesn't automatically fetch new repos from GitHub.
There may be APIs or settings to do this stuff, I don't know.

I also don't know how committed we are to GitHub in the near future.
Arthur has the final say and the best background to answer that.