Uploaded new 10.0, done a pass over all Impact=High defects.

So this triggers a coverity build when a commit is made to a branch named coverity_scan-* (allowing for coverity_scan-5.5, coverity_scan-10.0 ...). This is as there is a limited number of coverity builds and every commit would be excessive.

Main question is where do you want the email results sent to?

The plugin is documented: http://docs.travis-ci.com/user/coverity-scan/.

On travis in general, the connector team has this done in CONJ-162. As per feedback from otto, I'm going to put the debian build on its own instance. Travis support are quite open to extending the maximum allowed build time (default 50mins) and since the debian build runs the test suite (soon to be with multiple workers) this will probably be required.

I've configured the build to upload build failures to the ftp server only on the main branches, just in case a failure gets detected here and not on the existing build bots.

Is saving of compile/test failures of pull requests desirable? if so where can they be put? Like the example it is possible to secure this so it doesn't become a public upload server.

Is the saving of built packages desirable? There's a low number of pull request currently so it probably wouldn't be that much overhead to save for a few builds (like hasky).

Code coverage using coveralls.io is possible but and as elenst pointed out, only test coverage is important. The lines of code covered and how that changes per pull request is there as is the ability to examine if the added code was tested.

Patch: https://github.com/MariaDB/server/pull/84

Now that travis builds are container based with more memory they can occur fairly reliably: https://travis-ci.org/openquery/mariadb-server

Uncommenting the coverity_scan addon in .travis.yml and adding the documented variables into the travis-ci web interface will run these scans on branches coverity_scan-.* allowing a flexible merge point for each major release.

I thought that people with commit access can do that already, can they not?

Seems so. I thought I was seeing a lot of pull requests closed by their originators, which was true, but most targeted a different branch to what was fixed, admitted to their own error, or it was patched differently or more completely.

Progress report on travis-ci builds - going ok except for fairly frequent internal compile errors on ubuntu packaged gcc/g++ (4.9 and 5.1). e.g. https://travis-ci.org/openquery/mariadb-server/jobs/60365586 . I'll try to extract something meaningful to submit to the ubuntu toolchain team. Couple of other small issues however overall it seems a good way to get pull requests run though the test suite (with --big-tests), tested on gcc and clang, and if I can resolve the gcc/lcov compatibilty - code coverage on the service https://coveralls.io/r/openquery/mariadb-server . Feedback/questions welcome if you have time https://github.com/openquery/mariadb-server/blob/travis-ci-10.0/.travis.yml .

I thought that people with commit access can do that already, can they not?

currently waiting on https://github.com/travis-ci/travis-ci/issues/3729 / https://github.com/travis-ci/travis-ci/issues/3730

After that adding a .travis.yml will get automated builds from build bot (need to login to travis-ci with the github login to enable this http://docs.travis-ci.com/user/getting-started/). The follow these instructions - https://scan.coverity.com/travis_ci for the CI part.

As a bonus the github request that accumulate will have a run though the test suite before you think about looking at them.

I'd suggest giving people with commit access some additional developer privs on the github account so they can close PRs or even merge simple changes directly.

Seems to be possible if you do a travis_ci build https://scan.coverity.com/travis_ci

Work in progress: https://github.com/openquery/mariadb-server/blob/travis-ci/.travis.yml

build failures (that will hopefully turn successful) https://travis-ci.org/openquery/mariadb-server