About `SonarSource/sonarcloud-github-c-cpp` action

[Geoffray (Geoffray Adde)]

Hello @LecrisUT

@LecrisUT

Firstly, the naming is misleading, the convention for those actions is setup-sonarcloud similar to setup-python, setup-github-cli, etc.

Aligning the names also allows for better visibility. It is a trade-off. I will report the suggestion to the teams.

@LecrisUT

The next issue is that the wrapper is obscuring a black-box command, but according to what is documented, the only purpose is to make a clean build environment. But in the context of cmake + github wotkflow, that is meaningless since it is always a clean environment. If it does any additional steps, then that should be clarified and documented.

This action aims to avoid boilerplates when using the Builld-Wrapper to configure the C and C++ analysis. It can also be used if you use a compilation database. It is still our recommended configuration. As you know, C and C++ tooling is very fragmented; multiplying documentation and actions for all combinations is not something we try to do even though we provide many examples with such combinations. Still, I acknowledge that cmake is the most widely used build system. However, C and C++ CIs also carry a wide variety and even if you use cmake for your build, there are many ways to do it. We have tried to come up with an action to analyze the code accounting for this variety. The current action is the best that could cope with it. About the documentation, can you please tell me what you feel is missing if you read the pointed SonarCloud C++ analysis documentation?

@LecrisUT

Thirdly, the wrapper restricts the usage of actions like lukka/run-cmake, that abstracts the calling of cmake. I am pushing to have that action also setup the parallelization, which is otherwise nontrivial for cross-platform.

This is a brilliant example of the variety of use cases I mentioned earlier.

@LecrisUT

The issue is with SonarCloud itself and/or documentation. Codecov allows to define flags to mark the coverage runs, so you can distinguish where the coverage comes from. The equivalent functionality in sonarcloud is unknown. With regards to the action, it is unclear how to split the static/dynamic analysis from the coverage so that we only do the upload coverage part with different flags, e.g. in this workflow

Please consider this a separate topic unrelated to the SonarCloud C/C++ GitHub action. We are aware of this limitation and of the constraint it puts on CI pipelines. The topic is under active consideration right now. Thanks for your patience. Feel free to follow the thread I mentioned.