Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Currently there are—— rhs-vm-112.gdev.lab.eng.bos.redhat.com (supercedes rhs-vm-12), Debian wheezy/7 rhs-vm-113.gdev.lab.eng.bos.redhat.com (supercedes rhs-vm-13), Debian jessie/8 rhs-vm-116.gdev.lab.eng.bos.redhat.com (supercedes rhs-vm-16), Debian stretch/9 The above are used for Debian builds for d.g.o. Builds are run by glusterpackager in ~glusterpackager following the recipe ~/glusterpackager/HOWTO rhs-vm-17.gdev.lab.eng.bos.redhat.com, an Ubuntu box for creating .source.changes files to submit to Launchpad. rhs-vm-18.gdev.lab.eng.bos.redhat.com, a Fedora box for signing Fedora RPMs before uploading to d.g.o. rhs-vm-111.gdev.lab.eng.bos.redhat.com (supercedes rhs-vm-11), Fedora 25. This is where clang (compile, analyze) and cppcheck are run. Also a coverity analysis which is separate from the coverity analysis run by the coverity group in Brno. Note that as of 19 Dec 2016 everything is still running on rhs-vm-11.
First set of changes to run the staticanalysis builds on the cage infrastructure: https://github.com/gluster/gluster.org_ansible_configuration/pull/14 I've got a job to run cppcheck on a nightly basis for master at the moment: https://build.gluster.org/job/cppcheck/ Step 1: Get a Jenkins job for everything. Step 2: Step up analysis.rht.gluster.org ready for serving the static files. Step 3: Use Jenkins-based automation to move the logs into staticanalysis.rht.gluster.org That's stage 1, so we're using the current workflow but automated with jenkins. We'll figure out what stage 2 looks like in the future when things settle down, whether it's double compilation or analyzing increase vs decrease of the number.
We now have all the static analysis jobs expect for Coverity running on Jenkins. We're in a process of setting up a new server for staticanalysis so that we don't push those onto downloads.gluster.org.
Coverity now runs on Jenkins too. This bug can now be completely closed.