From patchwork Tue Jun 13 15:54:47 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Maydell X-Patchwork-Id: 105376 Delivered-To: patches@linaro.org Received: by 10.140.91.77 with SMTP id y71csp476055qgd; Tue, 13 Jun 2017 08:54:53 -0700 (PDT) X-Received: by 10.223.133.4 with SMTP id 4mr3885755wrh.30.1497369293863; Tue, 13 Jun 2017 08:54:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1497369293; cv=none; d=google.com; s=arc-20160816; b=ymuQ0vc6Y9zaka8F0aR19nLvlewXhntqV7gDZ1S2qCksC5GExN2ODZ1tuOLA4vnfA8 xgikqsX6g1uazcOpnbR3Zd4VbOu0mpFNOHaPUdUn5Y2M3l34woeoF1oZB6UW5RWN9TfB cm3+9MkQafjHPfrBpPD27cXTmujTCLZZJhDFEzcaSgodZr4pvU7hn8i20jfJxYcigwtG hRUy5Wja4J46x1jTZSzUb0MMQd6fffuya0MhWkb0tv166YMQdxG1MUO1JRoQaSBged/y E5vK2A1WziZmJUbXuSTeR/hEHw/dd63mm7SfNVg16qc+63Kp1JvOofOgHbbUhQ8ObtQ/ xJEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from:arc-authentication-results; bh=M1CfhNdU30fG5p+91mULYZS6M7nRX/OD3iJF79r0JS0=; b=iuDoUDOcNqn3RK+d7okr+gJ9HhycfTBjPB3gd4ExZ78S9pbVr2dVFC/gZrzQHbTCyq H3aN1rIcOEmQZJ3ouOPx07HSvDITxiP2VOOgwHP3J6JmbJ4YVHOOu8hWgY+bNLIABkEH 3+k1FwB0jvywD1w0gV/v62wM09ql2Jz79sLE+XS4Ogem4aHr23RRNSSLVUTkDGon2ow6 RoLtEZuRM5xmzxW7TNuv2n0xGzoXju89WNq6Mi3fgCJst9LqDWsk2fKOUzL5uZ0Dgnca lymgF2q363lIbjr/QyVDrMnhivXiQUKUWAnHf7fwUrUNezz26riO0cKeYmEB5bctYb7r ffoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of pm215@archaic.org.uk designates 2001:8b0:1d0::2 as permitted sender) smtp.mailfrom=pm215@archaic.org.uk; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from orth.archaic.org.uk (orth.archaic.org.uk. [2001:8b0:1d0::2]) by mx.google.com with ESMTPS id p59si205636wrc.257.2017.06.13.08.54.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Jun 2017 08:54:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of pm215@archaic.org.uk designates 2001:8b0:1d0::2 as permitted sender) client-ip=2001:8b0:1d0::2; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of pm215@archaic.org.uk designates 2001:8b0:1d0::2 as permitted sender) smtp.mailfrom=pm215@archaic.org.uk; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from pm215 by orth.archaic.org.uk with local (Exim 4.84_2) (envelope-from ) id 1dKo9b-0001AD-6g; Tue, 13 Jun 2017 16:54:51 +0100 From: Peter Maydell To: qemu-devel@nongnu.org Cc: patches@linaro.org, =?utf-8?q?Alex_Benn=C3=A9e?= , Paolo Bonzini , Markus Armbruster Subject: [PATCH 0/3] Automate coverity scan uploads via Travis Date: Tue, 13 Jun 2017 16:54:47 +0100 Message-Id: <1497369290-20401-1-git-send-email-peter.maydell@linaro.org> X-Mailer: git-send-email 2.7.4 This patchset automates our uploads to the coverity scan service by making them a travis build job. I wrote this code because I kept finding that our Coverity build was days or weeks behind master, so it seemed worth automating. We could do this via something other than Travis (some of the notes below discuss issues with doing it this way) but I do think we should be doing this automatically rather than ad-hoc, and patch 2 at least is probably a useful part of any automation we want to do. Patch 1 is a preliminary that improves the set of code that Travis builds by adding some -dev packages to the set of installs. (There's a limit to the improvement possible because the base machine is Ubuntu Precise or Trusty, and some of our dependencies need versions that are closer to the bleeding edge than those distros provide.) Patch 2 is a shell script which automates the process of downloading the coverity build tools, running the local build and uploading it to the scan server. To be able to run the script and upload a build you need a secret token which only people with coverity scan project admin access have. Patch 3 changes the travis config to run the script. We use Travis's ability to have encrypted config to pass the secret token to the script without exposing it to the world. Notes: (1) There is an official Coverity/Travis integration, but I haven't used it, because it's awkwardly inflexible (no option for "don't actually upload" to use when debugging, for instance) and no use if you want to do a local Coverity build. The official integration does basically the same thing that this local script does, but in a weird two part way with some code in a Travis "addon" https://github.com/travis-ci/travis-build/blob/master/lib/travis/build/addons/coverity_scan.rb which downloads a shell script: https://scan.coverity.com/scripts/travisci_build_coverity_scan.sh which does the work. (2) The job is quite close to the travis 50 minute timeout limit :-( This might just be Travis running slow today, though -- one of our normal builds hit the same timeout just now. (3) There is an upload limit on the server side of one build a day. The travis changes here make no attempt to rate limit, but rely on the server side doing it. (If the server says "no upload permitted" then we don't attempt to do the build phase.) We see if we can do an upload for every commit to master. This seems fine to me, but if the server changes its limits we might want to rethink. The simplest way to impose a travis-side rate limit seems to be to have the travis integration only run on a particular branch name (eg "coverity-scan") and have a cron job push master to that branch periodically. (4) Because Travis worker hosts are running Ubuntu Trusty some of the code we were previously scanning is no longer scanned because configure won't build it due to too-old dependencies. Notable casualties are iscsi, gluster, rdma and qxl. One way to work around this might be to have a docker container set up with the desired config for running the scan, and then have Travis use that docker container. (Wanting to possibly do something like this is another reason to roll our own script rather than using the official travis/coverity integration.) (5) We could in theory run the builds on something other than travis but it wasn't clear to me that we had any suitable machines set up in the project currently. Travis has the advantage that somebody else is doing the admin and providing the hardware :-) (6) It would be nice to be able to automatically update the Coverity Scan server's model file and the regexes defining components, but that doesn't seem to be conveniently doable. thanks -- PMM Peter Maydell (3): travis: install more library dependencies scripts/run-coverity-scan: Script to run Coverity Scan build travis: Add config to do a Coverity Scan upload .travis.yml | 42 ++++++++++++ scripts/run-coverity-scan | 170 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 212 insertions(+) create mode 100755 scripts/run-coverity-scan -- 2.7.4