[sr-dev] travis-ci error messages to the list related to coverity_scan

[Daniel-Constantin Mierla]

On 18.12.17 12:57, Victor Seva wrote:
> 2017-12-18 11:39 GMT+01:00 Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>:
>
>     It would be good to have a way that more developers can trigger a
>     coverity scan, but the results are only visible to the developers
>     that registered to coverity site, therefore I do not think
>     alerts/notifications to public sr-dev mailing list are useful for
>     the vast majority of members. Those devs associated in the
>     coverity project get a notification when a new scan is uploaded.
>
>
> The alerts/notifications where only due to my failing tests. Travis
> will notify only if build fails, nothing related to the coverity scan
> itself now that I figure out how to integrate the build.
Can a coverity scan build fail if usual compilation with gcc/clang is
ok? When would be useful to know that such build failed, does it
indicate something that a developer can fix on kamailio code?

>  
>
>     Another aspect is that I consider automatic scans to be
>     inconvenient in this case, in many cases I upload scans myself and
>     want to keep that scan until I solve some reported issues -- an
>     automatic scan can overwrite the state of an ongoing analyzis. So
>     a new scan should be triggered and uploaded only a specific
>     developer wants to do analyzis and eventually after sync'ing with
>     the other devs not to have a conflict.
>
>
> Not really sure what you mean about ongoing analysis, AFAIK every
> reported issue has a CID. And it should be unique between reports is
> that right? I see that info at "Detection History". I'm assuming that
> new reports will detect fixed and new issues. Am I wrong?

When a new scan build is uploaded, the first set of issues I look at is
those newly detected. It shows what went wrong from the previous build.
I try to make sure that any new report on core and most important
modules are fixed asap. Subsequent builds are overwriting them, getting
lost in the old ones, which were reviewed but a solution was not found
(e.g., they look like false positives).

Just uploading builds without anyone reviewing the results are useless
and can end up later in using more time to look again over the entire list.

>  
>
>     Should anyone have different opinions and see other benefits by
>     doing it in another way, I am more than open to have the proposals
>     discussed here.
>
>
> The rationale behind this change was to unify how We build and send
> the report to the service, so anyone with the required perms ( even an
> automated  process ) can do it easily without the need of having a
> special environment or process. The code would be in the repository to
> review, improve or fix it and it would be always the same ( using the
> same options and environment )
>
My coverity builds are sometimes with system malloc instead of the
internal pkg, based on what needs to be troubleshooted. I said that
having an way to trigger the scan build by others can be useful, but
automatic and periodic builds are not useful at all, there must be a
developer that has interest to see the results at that moment.

Based on current proposal, I am not that confident that using a
dedicated branch is convenient. I would rather have a way to trigger the
scan build from master, upon a developer request/whatever action... not
sure if that works somehow, but it would be more useful in my opinion.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-dev/attachments/20171218/2443385e/attachment-0001.html>