Closed d-winsor closed 3 years ago
In terms of determining the ruleset I think the best course of action is to check-in a custom ruleset that disables all warnings, effectively creating a baseline of nothing. Once merged I will create a follow-up PR and then all users will be able to see the warnings in the PR. If we go down this route we can also ignore the second TODO and stay on the feature branch for now.
Let's keep this PR focused on the workflow changes as I have already tested the msvc-code-analysis-action
works in my personal fork of IPR.
Added Microsoft C++ Code Analysis action to enable warnings to be visible via GitHub Code Scanning Alerts. This will include annotating the changes of a PR with any warnings that were introduced.
Alerts will only be visible to users with write permissions to the repo until this PR is merged. A baseline on the master branch is needed before the creation of a PR delta which can be viewed by any users.
Also:
TODO before merging PR:Decide on a ruleset to use. Currently every warning is enabled which is too verbose.Switch to main branch for themsvc-code-analysis-action
once changes are merged (this repo is a testing ground).