git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Lars Schneider <larsxschneider@gmail.com>
To: Siddhartha Mishra <sidm1999@gmail.com>
Cc: Git List <git@vger.kernel.org>, Johannes Schindelin <johannes.schindelin@gmx.de>
Subject: Re: [GSoC] [PATCH] travis-ci: added clang static analysis
Date: Sun, 1 Apr 2018 16:39:52 +0200
Message-ID: <74BBE628-B8FC-4699-9A23-F774D4908011@gmail.com> (raw)
In-Reply-To: <CAMOtk6Df_7Jb9bX=8PfB9e4-5rRi8QSmXEK7=DmZui6LNBMSLQ@mail.gmail.com>


> On 13 Mar 2018, at 18:45, Siddhartha Mishra <sidm1999@gmail.com> wrote:
> 
> On Mon, Mar 12, 2018 at 3:49 PM, Lars Schneider
> <larsxschneider@gmail.com> wrote:
>> Hi,
>> 
>> That looks interesting but I agree with Dscho that we should not limit
>> this to master/maint.
>> 
>> I assume you did run this on TravisCI already? Can you share a link?
>> I assume you did find errors? Can we fix them or are there too many?
>> If there are existing errors, how do we define a "successful" build?
>> 
>> Thanks for working on this,
>> Lars
>> 
> 
> Thanks for the reply,
> 
> I assume there will be false positives in the code which we can't fix
> by making small modifications to the code as recommended in the FAQ
> (https://clang-analyzer.llvm.org/faq.html). According to the FAQ,
> there is no solid mechanism for suppressing a specific warning, so are
> options are limited. Some of the things which might help reduce the
> noise are:
> 
> 1) To add specific tags in our source code to tell the analyzer to
> ignore the code. This is probably a bad idea since it is intrusive and
> forces changes to the actual source code which only affect one task.
> 
> 2) Count the number of bugs in the previous pushed build and fail the
> build if the number of bugs increases. It doesn't help remove the
> noise from the error log but it does tell you if you've added more
> bugs. However if you add a bug and remove one, it'll pass the job and
> might mislead you into thinking that the code is correct.
> 
> 3) Write a script to check the diff of the error log from that of the
> previous pushed build(ignoring the line numbers). I haven't thought
> about how exactly it would be implemented so I'm not commenting on it.
> 
> Is there a better solution that I'm missing or should I try coming up
> with a script to come up the diff?

That's a good summary and I don't see a better solution. While (3)
sounds nice, I think (2) is the fastest/most pragmatic solution.

We already use the Travis cache [1]. You could use that mechanism to 
store a file with the latest number of bugs in the cache directory 
$HOME/travis-cache

If the "number of bugs" file does not exist, then create it and don't
complain. If the file exists and the previous number of bugs is higher
or equal, then don't complain either. If the file exists and the previous
number of bugs is lower, then let the build fail.

Do you think that could work?

Cheers,
Lars 

[1] https://docs.travis-ci.com/user/caching/


> 
> Thanks for the time,
> Siddhartha
> 
> On Mon, Mar 12, 2018 at 3:49 PM, Lars Schneider
> <larsxschneider@gmail.com> wrote:
>> Hi,
>> 
>> That looks interesting but I agree with Dscho that we should not limit
>> this to master/maint.
>> 
>> I assume you did run this on TravisCI already? Can you share a link?
>> I assume you did find errors? Can we fix them or are there too many?
>> If there are existing errors, how do we define a "successful" build?
>> 
>> Thanks for working on this,
>> Lars
>> 
>>> On 05 Mar 2018, at 21:04, SiddharthaMishra <sidm1999@gmail.com> wrote:
>>> 
>>> Added a job to run clang static code analysis on the master and maint branch
>>> 
>>> Signed-off-by: SiddharthaMishra <sidm1999@gmail.com>
>>> ---
>>> .travis.yml               | 17 ++++++++++++++++-
>>> ci/run-static-analysis.sh |  9 ++++++++-
>>> 2 files changed, 24 insertions(+), 2 deletions(-)
>>> 
>>> diff --git a/.travis.yml b/.travis.yml
>>> index 4684b3f4f..9b891d182 100644
>>> --- a/.travis.yml
>>> +++ b/.travis.yml
>>> @@ -48,7 +48,7 @@ matrix:
>>>      before_install:
>>>      before_script:
>>>      script: ci/run-linux32-docker.sh
>>> -    - env: jobname=StaticAnalysis
>>> +    - env: jobname=CocciStaticAnalysis
>>>      os: linux
>>>      compiler:
>>>      addons:
>>> @@ -59,6 +59,21 @@ matrix:
>>>      before_script:
>>>      script: ci/run-static-analysis.sh
>>>      after_failure:
>>> +    - if: branch IN (master, maint)
>>> +      env: jobname=ClangStaticAnalysis
>>> +      os: linux
>>> +      compiler:
>>> +      add_ons:
>>> +        apt:
>>> +          sources:
>>> +          - ubuntu-toolchain-r-test
>>> +          - llvm-toolchain-trusty
>>> +          packages:
>>> +          - clang
>>> +      before_install:
>>> +      before_script:
>>> +      script: ci/run-static-analysis.sh
>>> +      after_failure:
>>>    - env: jobname=Documentation
>>>      os: linux
>>>      compiler:
>>> diff --git a/ci/run-static-analysis.sh b/ci/run-static-analysis.sh
>>> index fe4ee4e06..6ae032f54 100755
>>> --- a/ci/run-static-analysis.sh
>>> +++ b/ci/run-static-analysis.sh
>>> @@ -5,6 +5,13 @@
>>> 
>>> . ${0%/*}/lib-travisci.sh
>>> 
>>> -make coccicheck
>>> +case "$jobname" in
>>> +ClangStaticAnalysis)
>>> +     scan-build -analyze-headers --status-bugs make
>>> +     ;;
>>> +CocciStaticAnalysis)
>>> +     make coccicheck
>>> +     ;;
>>> +esac
>>> 
>>> save_good_tree
>>> --
>>> 2.16.2.248.ge2408a6f7.dirty
>>> 
>> 


  parent reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 20:04 SiddharthaMishra
2018-03-06  1:27 ` Junio C Hamano
2018-03-06  8:34   ` Siddhartha Mishra
2018-03-07 13:16     ` Johannes Schindelin
2018-03-12 10:19 ` Lars Schneider
2018-03-13 17:45   ` Siddhartha Mishra
2018-03-13 17:52     ` Siddhartha Mishra
2018-04-01 14:39     ` Lars Schneider [this message]
2018-04-02 20:08       ` Siddhartha Mishra

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=74BBE628-B8FC-4699-9A23-F774D4908011@gmail.com \
    --to=larsxschneider@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=sidm1999@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox