Re: [xml] Continuous integration for libxml2?

[David Drysdale <drysdale google com>]

On Wed, Oct 21, 2015 at 11:03 AM, Daniel Veillard <veillard redhat com> wrote:
> On Wed, Oct 21, 2015 at 08:11:47AM +0100, David Drysdale wrote:
> > On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard <veillard redhat com> wrote:
> > > On Fri, Oct 16, 2015 at 02:06:30PM +0100, David Drysdale wrote:
> > > > Hi folks,
> > >
> > >   Hi David,
> > >
> > > > Does libxml2 have a continuous integration system running over it somewhere?
> > >
> > >  Not that I know of :)
> > > TBH the rate of changes is fairly slow, i.e. the code is mature (some
> > > will call it overripe even !) and while there is bugs, compared to the
> > > size of the system it's relatively small.
> > >
> > > > I've recently been exploring continuous integration systems and I used
> > > > libxml2 as a guinea pig for getting various tools working in
> > > > combination.  Specifically, I've got a GitHub clone [1] of the repo
> > > > that links in with Travis [2]; once I added a few small local fixes
> > > > [3], I got the tests running on {gcc,clang} x {linux,osx} plus ASAN,
> > > > UBSAN and coverage [4] runs.
> > >
> > >   The biggest issue I have is non-linux, I never use Windows or Macs
> > > and I have zero clue that a change there could break the build or else.
> > > There are mingw builds of libxml2 done within Red Hat but that's not
> > > real Windows tests.
> >
> > The Travis builds do at least add OSX testing, which was fairly
> > straightforward to set up (I disabled the EBCDIC test file because
> > the iconv() on OSX doesn't include EBCDIC support).
>
>   Okay
>
> > I imagine a Windows build would a lot more effort to get automated,
> > if/when Travis add support for it...
>
>   as suggested you could tru to build with mingw, but for the actual
> regression testing, that's another story indeed
>
> > > > Looking at recent bugs, it seems like a couple of other people (Hugh
> > > > Davenport [5], Hanno Boeck [6]) have also been looking at
> > > > sanitizer-related things.
> > >
> > >   Yes, I also get Coverity Scan reports about it.
> > >
> > > > So I wondered if the master libxml2 repo already has a continuous
> > > > build pointed at it (the Gnome continuous build system [7], maybe?),
> > >
> > >   No not that know of
> > >
> > > > and, if so, whether it might be a good idea to turn on various
> > > > analysis tools to help catch future problems.
> > > >
> > > > Thoughts?
> > >
> > >   Sure, the rate of changes is fairly slow though:
> > >     https://git.gnome.org/browse/libxml2/
> > >
> > > But getting a report if something breaks on commit there would be appreciated
> > > as long as there is some logic to avoid pestering the list repeatedly with
> > > the same issue. That was a very painful experience on the very early versions
> > > of Coverity for example,
> >
> > I believe the default Travis behaviour is to send email
> >  - to the commit author and committer
> >  - when a commit arrives for which the build is broken
> >  - and when a commit fixes a previously-broken build.
> > (http://docs.travis-ci.com/user/notifications/)
> >
> > As the whole process is commit-triggered, there shouldn't be too many
> > notifications (given that the rate of changes is low) -- but it does continue
> > to pester on each commit until a build break gets fixed.
> >
> > How about I set up (for the time being) a cron job to do the following:
> >  - fetch from the master repo
> >  - merge into my testing branch
> >  - push to GitHub...
> >  - triggering a Travis build.
> >
> > I *think* that should result in any email notifications from Travis going
> > to me, because I'll be the committer for the merge commit -- but please
> > let me know if the process inadvertently spams anyone!
>
>   may be I should get the SPAM. I wonder if there is a fedmsg backend for travis
> as getting those message over IRC might be a nice solution rather than mail
>
>   http://www.fedmsg.com/en/latest/

Simpler than that, it looks like Travis have direct IRC integration:
  http://docs.travis-ci.com/user/notifications/#IRC-notification

> > If that goes well and is helpful, we can then talk later about whether/how
> > to migrate to the master repo.
> >
> > Sound OK?
>
>
>    yes,
>
>     thanks !
>
> Daniel
>
> > Thanks,
> > David
> >
> > > Daniel
> > >
> > > > Thanks,
> > > > David
> > > >
> > > > [1] https://github.com/daviddrysdale/libxml2
> > > > [2] https://travis-ci.org/daviddrysdale/libxml2
> > > > [3] https://github.com/daviddrysdale/libxml2/commits/test
> > > > [4] https://coveralls.io/github/daviddrysdale/libxml2
> > > > [5] https://bugzilla.gnome.org/show_bug.cgi?id=756372
> > > > [6] https://bugzilla.gnome.org/show_bug.cgi?id=752191
> > > > [7] http://build.gnome.org/
> > > > _______________________________________________
> > > > xml mailing list, project page  http://xmlsoft.org/
> > > > xml gnome org
> > > > https://mail.gnome.org/mailman/listinfo/xml
> > >
> > > --
> > > Daniel Veillard      | Open Source and Standards, Red Hat
> > > veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
> > > http://veillard.com/ | virtualization library  http://libvirt.org/
>
> --
> Daniel Veillard      | Open Source and Standards, Red Hat
> veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
> http://veillard.com/ | virtualization library  http://libvirt.org/