2017-12-18 11:39 GMT+01:00 Daniel-Constantin Mierla <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.

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