Re: [xml] Continuous integration for libxml2?
On Wed, Oct 21, 2015 at 7:31 PM, Nick Wellnhofer wrote: > On 21/10/2015 09:11, David Drysdale wrote: > >> On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard >> wrote: >> >>>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... >> > > The Windows build could be tested with Appveyor. They offer free CI > services for open-source projects. Setup is similar to Travis. > Thanks for the pointer -- I've added an AppVeyor build to my clone of the repo: https://ci.appveyor.com/project/daviddrysdale/libxml2 > Nick > > > ___ > xml mailing list, project page http://xmlsoft.org/ > xml@gnome.org > https://mail.gnome.org/mailman/listinfo/xml > ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Continuous integration for libxml2?
On 21/10/2015 09:11, David Drysdale wrote: On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard wrote: 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... The Windows build could be tested with Appveyor. They offer free CI services for open-source projects. Setup is similar to Travis. Nick ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Continuous integration for libxml2?
On Wed, Oct 21, 2015 at 12:13:43PM +0100, David Drysdale wrote: > On Wed, Oct 21, 2015 at 11:03 AM, Daniel Veillard 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 > >> 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 Then I think you can easilly pester the #xml channel on irc.gnome.org or DV (my nick) on irc.gnome.org thanks, Daniel > >> 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://bu
Re: [xml] Continuous integration for libxml2?
On Wed, Oct 21, 2015 at 11:03 AM, Daniel Veillard 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 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 >> > veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ >> > http://veillard.com/ | virtualization library http://libvirt.org/ > > -- > Daniel Veillard
Re: [xml] Continuous integration for libxml2?
On Wed, Oct 21, 2015 at 08:11:47AM +0100, David Drysdale wrote: > On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard 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/ > 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 > > veill...@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 veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/lis
Re: [xml] Continuous integration for libxml2?
On Fri, Oct 16, 2015 at 2:41 PM, Daniel Veillard 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. >> >> 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! If that goes well and is helpful, we can then talk later about whether/how to migrate to the master repo. Sound OK? 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 > veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ > http://veillard.com/ | virtualization library http://libvirt.org/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
Re: [xml] Continuous integration for libxml2?
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. > 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, 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 veill...@redhat.com | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | virtualization library http://libvirt.org/ ___ xml mailing list, project page http://xmlsoft.org/ xml@gnome.org https://mail.gnome.org/mailman/listinfo/xml
[xml] Continuous integration for libxml2?
Hi folks, Does libxml2 have a continuous integration system running over it somewhere? 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. 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. So I wondered if the master libxml2 repo already has a continuous build pointed at it (the Gnome continuous build system [7], maybe?), and, if so, whether it might be a good idea to turn on various analysis tools to help catch future problems. Thoughts? 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