docs: more robust approach

[mds1]

The existing docs require that slither never exits with an error if you want the code scanning integration. However, you can tell a GitHub Actions step to run regardless of previous steps' status as shown in this PR. Tested this out in https://github.com/ScopeLift/foundry-template/pull/1 and it seems to work as expected

[mds1]

Actually, I don't like this approach, so I'll probably close this PR 😅

It seems you can set this action up two ways:

1. Have both CI steps marked as successful, with code scanning results shown in the PR but not make resolving/dismissing them a blocker for merge (current README approach).
2. Have the actual slither step fail if it finds something, with code scanning results shown in the PR (this PR's approach). The downside here is that when you dismiss an alert in code-scanning UI, it's no reflected in the slither step (which makes sense), so you're stuck with a failing CI step even though there's no issue

I think the ideal approach is to have the slither step always pass, and have the code scanning step fail if there's new findings, OR findings which have not been dismissed in the code scanning UI, but I haven't figured out a way to do this yet

[elopez]

@mds1 I haven't looked into it much, but maybe this feature from Github can be useful: https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/configuring-code-scanning#defining-the-severities-causing-pull-request-check-failure

[mds1]

Heh was literally just reading that page now, thank you!

[mds1]

For posterity, that is exactly the section to use. For testing I set it to All which you can see causes the CI failure in code scanning