Re: [xml] Continuous integration for libxml2?

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

I imagine a Windows build would a lot more effort to get automated,
if/when Travis add support for it...

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.


  Sure, the rate of changes is fairly slow though:

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.

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!

If that goes well and is helpful, we can then talk later about whether/how
to migrate to the master repo.

Sound OK?




xml mailing list, project page
xml gnome org

Daniel Veillard      | Open Source and Standards, Red Hat
veillard redhat com  | libxml Gnome XML XSLT toolkit | virtualization library

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]