18 Dec
2017
18 Dec
'17
6:57 a.m.
2017-12-18 11:39 GMT+01:00 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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.
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?
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 )
Cheers,
Victor Seva