ifc icon indicating copy to clipboard operation
ifc copied to clipboard

Static analysis in CI

Open friendlyanon opened this issue 2 years ago • 3 comments

The contributing document suggests that contributors ought to format the code before submission, however there is no enforcement in CI. I would like to add it to the CI, however it's not stated which version of clang-format should be used. Different versions of clang-format may format some code differently, so it's important to specify the version.

On the same note, I'd like to also know your opinions on other forms of static analysis, such as spell checking. I have been using codespell personally. If you find it satisfactory, I'd also like to add that in the same PR.

To make efficient use of CI resources, I would like to structure CI as a single file with such job and matrix configuration:

flowchart
    A["clang-format
    codespell"]
    B["CMake (Windows)
    CMake (Ubuntu)"]
    C["CodeQL (Windows)
    CodeQL (Ubuntu)"]
    A --> B
    A --> C

You can see this example, where nothing else is done until the lint job is done.

Making this chart also makes me question whether the separate CMake jobs are necessary with CodeQL jobs being a thing.

friendlyanon avatar Oct 09 '23 13:10 friendlyanon

Thanks for writing this up. The team is still discussing it. Given resources constraints, CodeQL will take precedence over spell checking and clang formatting. As you correctly observe, clang-formatting really is version-dependent and we are reluctant to cause or require churns just for that. We are relying on ClangFormat primarily as a way to reduce review traffics that are solely formatting related. For now, there is hesitancy to make it a check-in gate, unless we start seeing deviations in submitted PRs that go beyond reasonable.

GabrielDosReis avatar Oct 10 '23 20:10 GabrielDosReis

Understandable. Would it be an issue even if the diagnostics were just informative? clang-format and codespell run pretty fast when using an Ubuntu runner.

How about combining the existing cmake.yml with codeql.yml? At present, the overlap in their functionality is significant.

friendlyanon avatar Oct 11 '23 12:10 friendlyanon

How about combining the existing cmake.yml with codeql.yml? At present, the overlap in their functionality is significant.

Whatever is done, we need the CodeQL workflow as a separate workflow because it is needed by organizational policies. So, even if cmake.yml and codeql.yml is combined, we would still need codeql.yml; so that leads to some form of duplication.

Could you tell me more about the "optimization" goal here and what are the alternatives available?

GabrielDosReis avatar Oct 22 '23 02:10 GabrielDosReis