18 Dec
2017
18 Dec
'17
11:52 a.m.
On 18.12.17 12:57, Victor Seva wrote:
2017-12-18 11:39 GMT+01:00 Daniel-Constantin Mierla
<miconda(a)gmail.com
<mailto:miconda@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