On 21 May 2024, at 0:03, Ilya Maximets wrote:
> On 5/1/24 14:33, Eelco Chaudron wrote: >> >> >> On 29 Apr 2024, at 14:59, Ilya Maximets wrote: >> >>> On 4/16/24 09:44, Eelco Chaudron wrote: >>>> This patch adds a daily Coverity run for the OVS main branch >>>> to the GitHub actions. The result of the runs can be found here: >>>> >>>> https://scan.coverity.com/projects/openvswitch >>>> >>>> Before applying, we need to add the following two actions secrets >>>> to the GitHub openvswitch project: >>>> >>>> - COVERITY_SCAN_TOKEN; The secret token from the project page >>>> - COVERITY_SCAN_EMAIL; The maintainer's email alias >>>> >>>> Signed-off-by: Eelco Chaudron <echau...@redhat.com> >>>> --- >>>> .github/workflows/coverity.yml | 131 +++++++++++++++++++++++++++++++++ >>>> Makefile.am | 1 + >>>> README.rst | 2 + >>>> 3 files changed, 134 insertions(+) >>>> create mode 100644 .github/workflows/coverity.yml >>> >>> Thanks, Eelco for bringing this up. Though, continuing the >>> offline discussion, I'm not sure having coverity scans as >>> a GitHub action has any benefits for OVS community. >>> >>> A few issues: >>> >>> 1. Reports are not available to people outside of the OVS >>> Coverity project. Adding everyone there doesn't seem >>> reasonable. Also a potential security concern. >> >> I do not see a security concern, as anyone can set up the coverity scan >> on his fork of the project and has all the insights. I do agree that we >> should not try to add everybody to the Coverity project, and this might >> be more for maintainers (who can opt-in to get emails on new issues). > > Fair, not a security concern indeed. But it's still not nice that > reports are not publicly available. > >> >>> 2. Workflow cannot be used in forks due to organization secrets. >>> (IIUC, current implementation will just fail once a day >>> annoying people who didn't disable that workflow.) >> >> I guess this can be fixed, we could check for the variables. This way if >> someone wants to add Coverity scans to his fork, all they need to do is >> add the secrets. >> >>> 3. Necessity to have secrets in the organization. We currently >>> don't have any, and from a security standpoint not having >>> any secrets is always better. >> >> Is having the secrets in a 3rd party located robot more secure? > > It's not more secure per se, but it makes security concerns someone > else's problem. :) GitHub been leaking secrets multiple times in the > past few years. And robot likely has lower attack surface. At least > we don't need to care about executing binary blobs downloaded from the > internet in the context of the main OVS organization - robot can be > better isolated. Also, using non-official actions from some random > person is a bit sketchy. > >> >>> 4. A decent amount of code duplication for this workflow. >>> (Reusable workflows maybe?) >> >> Yes, I can take a look at composition in GitHub actions, as there is >> no real ‘include’ like feature. > > There are 'reusable workflows', but they are a not very intuitive. > >> >>> In its current form, I think, the same functionality can be >>> provided by the 0-day robot that could submit sources once >>> a day for the scan. And it could also send some emails with >>> build details if necessary (again, there may be some security >>> concerns in case coverity discovers a genuine security issue). >> >> Guess results are only available in the GUI and through an email, >> don’t think you can query new items through an API. >> >> @Aaron do you know how this is handled for DPDK? >> >>> With the total amount of code in the project, IIUC, we could >>> submit up to 21 builds a week with no more than 3 per day >>> (Coverity claims that it checked just under 300K lines in OVS). >>> So, technically, we could create a bit more complex logic >>> for 0-day bot to run a check per patch set (probably, not per >>> patch though). In most cases we would fit within the limit >>> with the current patch rate. Maybe reserving one run a week >>> for the main branch. Such logic would be harder to implement >>> with GHA. >>> >>> All in all, using GHA just for scheduling of a job that wider >>> community can't take advantage of seems a little unjustified. >>> >>> Thoughts? >> >> I think it would benefit the maintainers to start with, and if implemented >> right people who fork should not see any side effects. > > There will be no difference in this aspect if implemented as part > of the 0day robot. Aaron/Michael how easy will it be to integrate this into the zero-day robot? I can probably create a shell script to do the build and upload the results, but not sure if that is what you need. //Eelco >> In addition, it also >> enables them to integrate Coverity for their own fork if they want to. >> >> Others? >> >> //Eelco >> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
