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 Arthur A. Gleckler 20 Apr 2019 23:07 UTC

Amirouche Boubekki <xxxxxx@gmail.com> writes:

| 1 Is it possible to setup Continuous Integration at
http://travis-ci.com/ for SRFI repositories or another service
that possibly support windows and other platforms. As far as know
there is no service offering free CI for windows platform. I read
there is an experimental CI server at
https://github.com/srfi-explorations/srfi-server maybe we can use
that already?

Lassi asked me about that earlier, but I was skeptical.  The
reason is that the SRFIs don't change often, and it seemed easy
enough for me to run a command whenever I made a change,
e.g. accepted a pull request or published a new SRFI.  The extra
infrastructure and attendant maintenance work of setting up
something more complicated just didn't seem worth the trouble.

However, you're the second person who has asked for Travis
support, and I don't want to be the person who makes it hard for
us to try new ideas, so 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.

| 2 Is it possible to include a markdown file in the SRFI
repository that will be translated to html by pandoc

According to the official SRFI process, SRFI authors must submit
their documents in HTML format:

  <https://srfi.schemers.org/srfi-process.html#Structure>

Of course, authors often write their documents in formats like
Markdown and use Pandoc or other tools to convert them.
Sometimes, we even include the original file in the Git
repository, although I make no promise to update them when I make
editorial updates to the corresponding HTML file.

But did you mean something other than the SRFI documents
themselves?

| 3 Is it possible to include a simple Makefile that will allow:
|
|  * Translate markdown to html via pandoc
|  * Run SRFI tests against various scheme implementations

I don't want to be responsible for maintaining the infrastructure
for running tests on different Scheme implementations, but I would
be eternally grateful if someone else were to set that up.  And
the HTTP trigger I described above would be fine for starting a
test run, wouldn't it?

One thing I'm sensitive to is making the official SRFI processes
dependent on third-party infrastructure, especially any that might
lock us into a particular work flow.  I want us to have the
flexibility to change in response to our own changing needs or to
changes in, or the demise of, any of our infrastructure providers,
e.g. Github.

Also, some people in the SRFI community care deeply about using
only free software (as opposed to open-source software), and I
want to be supportive of them.  But as long as people can write
SRFIs, participate in our discussions, and get access to SRFIs and
sample implementations without having to use non-free software,
I'm happy.  If you or someone else sets up a Travis server that
runs all the tests whenever a SRFI is added or updated, or that
extracts all the signatures and documentation, or that does
something else, that won't require using non-free software for the
core SRFI process.

Thanks for understanding of this balancing act.