[Clfs-dev] Travis-CI?

[Andrew Bradford]

Hi William,

On Sun, Apr 21, 2019 at 8:30 PM William Harrington
<kb0iic at berzerkula.org> wrote:
> On Sun, 21 Apr 2019 09:49:52 -0400
> Andrew Bradford <bradfa at gmail.com> wrote:
> > On Sat, Apr 20, 2019 at 7:01 PM William Harrington
> > <kb0iic at berzerkula.org> wrote:
> > > > On Apr 19, 2019, at 14:29, Andrew Bradford <bradfa at gmail.com> wrote:
> > > >> On Tue, Apr 16, 2019 at 11:02 AM Andrew Bradford <bradfa at gmail.com> wrote:
> > > >> I'd like to integrate the Travis-CI continuous build solution into at
> > > >> least the embedded CLFS book.  The goal is that any pull requests
> > > >> would at least get the book to be built by Travis first before
> > > >> allowing to be merged.  This should prevent any merges from happening
> > > >> where building the book breaks (we've had some issues with this in the
> > > >> past).  Travis seems to have decent integration with Github and I've
> > > >> observed other projects use Github+Travis together like this.
> > > >
> > > > I've gone ahead and implemented this for the Embedded book.
> > >  Not a good move. We are a guide, not a product to deploy to prod.
> > > Take your CI CD CT mentality elsewhere. Won’t work here. Think about it.
> >
> > OK.  I'm sorry, I didn't mean to get anyone riled up.  I know that we
> > have existing mechanisms for building the book but thought it might be
> > valuable to look at other solutions, too.  If this is not desired by
> > core contributors to the book then that's OK.
> I was a bit hasty. Before commiting any changes, we do a local build to make sure nothing is broke.
> Of course, the git hook will build the book on the server, too. I'm not sure the value of Travis-CI for the book itself.
> Maybe some others will chime in.

The core value that I see in something like Travis CI is to ensure
that if someone finds an issue with the book and wants to contribute a
change that we make it as easy as possible for them to do so.  With
Travis checking every pull request to ensure that the book builds
correctly, it makes it easier (in my opinion) for new contributors to
get their pull request merged.  The feedback loop with Travis isn't
instant, but it's decently fast and reasonably friction free for the
contributor as no maintainer of the book needs to be bothered by
looking at broken pull requests.  The contributor can easily see that
if their change broke the book that it probably won't be merged.

Travis can be used for many things, my intention was to use it in its
most simple format of checking pull requests so as to help
contributors to more easily get their changes integrated into the book
by providing quicker feedback when their edits break the book.

Thanks,
Andrew