Francois-Xavier Le Bail
2014-04-11 16:00:00 UTC
Hi,
I submit regularly Coverity build (manually).
I am working on GitHub-Travis-Coverity integration.
The idea is to have a branch say 'coverity_scan' and push commit(s) to it to trigger analysis.
The standard Travis-Coverity process has a limit:
It run as many build analysis than matrix cases (gcc, clang) x (with IPv6, without IPv6).
Thus we shall reach very quickly the limit of seven builds by week.
The usual workaround is to have a modified .travis.yml in the 'coverity_scan' branch.
This solution does not seem to me very functional.
Another workaround is to patch the standard Coverity build script with a new 'running condition', so we can run Coverity only if e.g. '"$CC" = gcc -a "$BUILD_IPV6" = true'.
I tested such a patch and the necessary update to .travis.yml.
I propose to commit:
1) the original script + the patch
2) the patched .travis.yml
For testing reasons, two steps are needed.
Thanks
I submit regularly Coverity build (manually).
I am working on GitHub-Travis-Coverity integration.
The idea is to have a branch say 'coverity_scan' and push commit(s) to it to trigger analysis.
The standard Travis-Coverity process has a limit:
It run as many build analysis than matrix cases (gcc, clang) x (with IPv6, without IPv6).
Thus we shall reach very quickly the limit of seven builds by week.
The usual workaround is to have a modified .travis.yml in the 'coverity_scan' branch.
This solution does not seem to me very functional.
Another workaround is to patch the standard Coverity build script with a new 'running condition', so we can run Coverity only if e.g. '"$CC" = gcc -a "$BUILD_IPV6" = true'.
I tested such a patch and the necessary update to .travis.yml.
I propose to commit:
1) the original script + the patch
2) the patched .travis.yml
For testing reasons, two steps are needed.
Thanks