[Clfs-dev] Travis-CI?

[William Harrington]

On Mon, 22 Apr 2019 08:01:44 -0400
Andrew Bradford <bradfa at gmail.com> wrote:

> 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.
> 

Hello Andrew,

Okay, I get a better view of it then. We can give it a whirl see how things go. This isn't one of them things where
if it isn't broke, don't fix it.

Sincerely,

Wiliam Harrington
-- 
Berzerkula <kb0iic at berzerkula.org>