feat(ci): run slither in main workflow

[sripwoud]

Integrate slither via its GH action into the main.yml workflow:

• write a comment in the PR informing the results will be available in the repo's security section
• upload SARIF report to GH (code scanning support)
• worklfow optimizations (sorry, this should have deserved its own PR ^^)
  • build deps in parallel and share node_modules between jobs
  • tests and slither jobs run in parallel
  • tests will only run for the impacted packages
  • slither will only run for the impacted packages
  • compilation happens in a parallel job and the compilation results are shared with the other jobs using the actions/upload-artifact and actions/download-artifact
    
    

Closes #7 ?

Notes

As this PR does not change any files that trigger the slither workflow, I tested it in another branch, see #9

[github-advanced-security]

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation.

[sripwoud]

I invite the contracts authors to check the slither alerts in the code scanning section:
https://github.com/privacy-scaling-explorations/zk-kit.solidity/security/code-scanning?query=pr%3A8

@0xjei @cedoor @vimwitch @LCamel @vplasencia

[cedoor]

How does this job work exactly?

Looks like the workflow doesn't install dependencies until there's some change in the yarn.lock file right?

So, I imagine the other jobs like tests, style and compile should be quite faster right?

[sripwoud]

My understanding is that job contexts are isolated.
So when you do e.g

job:
  steps:
    - uses: actions/setup-node@v4
      with:
        cache: yarn

It only caches deps in this particular job.
As the workflow is running several jobs that depends on the same lock file (we are in a monorepo), I thought it is redundant to run yarn in all jobs and was looking for a way to share the node_modules content between jobs.
One solution is to use directly actions/cache (actions/setup-node cache feature uses it under the hood).
It should speed up the whole workflow but I haven't measured it.

[cedoor]

I see! Looks great and we should definitely re-use it in the other repos imo.

[cedoor]

This is not clear. Were you trying to re-use the already generated artifacts here?

[sripwoud]

I thought I could reuse the artifacts generated from the compile job yes.
Like I am successfully doing in the tests job. see your previous question
#8 (comment)

But somehow I had errors with slither if using actions/dowload-artifact to get the contracts compilation artifacts. So I am compiling again here (not a big deal, just less efficient/ slower).
I can't find an example failing workflow. So let me test again.

[cedoor]

I see! If it doesn't work it's still fine agree.

[cedoor]

Great work @sripwoud

I think some optimizations can be re-implemented in the other repos 👍🏽