Hi Stefan, On Wed, 26 Apr 2017, Stefan Beller wrote:
> On Wed, Apr 26, 2017 at 1:19 PM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > I recently registered the git-for-windows fork with Coverity to ensure > > that even the Windows-specific patches get some static analysis love. > > YAY! How do you trigger the coverity scan? For starters, I did everything manually. But I already have the grand plan to use VSTS build (I do not want to advertise this system too blatantly, but I have to say that I really love working with that system, it is so much more powerful than Travis or AppVeyor, Jenkins comes closer but not by far). As you may have glimpsed in one of my mails, Git for Windows needs a very special and extensive build setup. I call it the "Git for Windows SDK", and what it is, in a nutshell, is a custom MSYS2 installation that has all the packages installed that are needed to build Git for Windows, its most important dependencies, and to bundle everything in an installer. Think of MSYS2 as something like Homebrew. But cozier, as it really lives inside its own directory tree, its /etc/ is not really visible to any other software, for example. This makes Continuous Testing a bit of a challenge, as you cannot hammer the package repository of MSYS2 with tons of fresh full installations all the time (that package repository is run by a volunteer, and it is sometimes unreachable, too). So after talking to a GitHub guy at the Developer Summit during GitMerge (Patrick asked a couple of questions and then said my plan was okay), I put two new repositories up that host the initialized Git for Windows SDKs (one for 32-bit, one for 64-bit). And of course there is a job to keep them up-to-date, run once every 24h. Almost all of the VSTS builds I maintain clone or update one or both of these repositories. And so will also the Coverity job. I still have to find the time to figure out one more detail: how to download and extract the Coverity tool (the .zip archive has a variable name for the top-level directory), and doing that only every once in a while, say, only when there is no previously unpacked tool, or it is already 4 weeks old. And then I should probably try to figure out a way how to delay subsequent runs of that job so that we run it at most once every twenty-four hours. Ciao, Dscho
