[ovs-dev] [PATCH] build: Add travis continuous integration support

[Thomas Graf]

On 08/25/14 at 09:01am, Ben Pfaff wrote:
> On Mon, Aug 25, 2014 at 05:58:09PM +0200, Thomas Graf wrote:
> > On 08/25/14 at 08:50am, Ben Pfaff wrote:
> > > Is there a way to get emailed build success/failure reports?
> > 
> > Yes:
> > 
> > 1. You can connect the main ovs git repo to travis-ci. This will
> >    result in a email to both the author and commiter if a new
> >    commit to any branch breaks the build. It will keep emailing
> >    respectively nagging you for any additional commit with the
> >    build still broken.
> 
> I wouldn't mind this personally--I'm good at dealing with/ignoring
> email--but I suspect that it's not generally a socially acceptable thing
> to do.

The documentation on this can be found here:
http://docs.travis-ci.com/user/notifications/#Email-notifications

After reading more closely, (1) seems not like a good option anyway
because it would only send out an email to githubs ids registered
with travis-ci which will not be a given for all contributors.

> > 2. We can set a notification email (new list?) to extend the
> >    notification to not only author/committer. We should not encode
> >    this into .travis.yml though because any commit to a fork would
> >    trigger such an email as well. There is a way to retrieve
> >    github repo settings in .travis.yml which we could use to avoid
> >    that, if you find this useful I can look into that.
> 
> This sounds nice to me.  I'd subscribe to that list.
> 
> What do we have to do to get this set up?

I'll work out the travis.yml details, looks like extending it
with something like below should do:

notifications:
  email:
    recipients:
      - $BUILD_CI_LIST

Can you setup a mailing list for the reports on openvswitch.org
and set an environment variable in the github settings to contain
the address of the list? [1]

[1] http://docs.travis-ci.com/user/environment-variables/#Using-Settings

I guess this will disable standard author/comitter emails on forks
which I would like to preserve as it's really useful for development
in branches. I'll try to figure something out to accommodate both.
Worst case a github fork would need to set BUILD_CI_LIST env var to
some email address in their github settings.

> > 3. Same as (2) but with an IRC channel as target.
> 
> I'd find that less useful because I'm not in the channel all the time,
> but if others would find it useful then it makes sense too.

OK, let's do the mailing list first.