ci: Integrate SonarCloud

[rettichschnidi]

This will give us details coverage and static and static code analysis on every code push, which includes the most recent commit in master. It also allows us to enforce certain code quality attributes.

Example analysis of the current master:

• https://sonarcloud.io/dashboard?id=eclipse_wakaama

Please note:

• If/when this PR got merged...
  • we should have a look at all findings
  • we could add shiny badges in the top-level readme :)
• In a follow up commit I intend to implement a way of running the scans on PRs from committers and, if possible in a secure fashion, to allow running the analysis on 3rd-party PRs too (as described in Keeping your GitHub Actions and workflows secure: Preventing pwn requests for inputs).

To enable the integration for your own fork, take the following steps:

• Log in to https://sonarcloud.io/ using your GitHub account
• Visit https://sonarcloud.io/projects/create, add Wakaama (fairly self-explanatory)
• Create a PR in your repository to verify the integration

[rettichschnidi]

@qleisan @mlasch @sbernard31 @sbertin-telular Would like to hear your opinions on this.

[sbernard31]

The checks can only work if/when @sbernard31 enables SonarQube as mentioned above

I never did that but if we want to I guess I need to ask for permission to eclipse webmaster ( see https://bugs.eclipse.org/bugs/show_bug.cgi?id=572407)

Would like to hear your opinions on this.

No strong opinion on it. I didn't play so much with sonar, so I guess I can not give you relevant feedback.
I contributed to few projects where it was used and some time feedback returned was annoying but I guess this is more setting issue. So maybe the question could be : is it no too much time consuming to set it to report really useful feedback ?

[rettichschnidi]

I contributed to few projects where it was used and some time feedback returned was annoying but I guess this is more setting issue. So maybe the question could be : is it no too much time consuming to set it to report really useful feedback ?

I think there are two aspects:

1. Code coverage: Very easy to set up and maintain - just specify the code coverage level needed to allow a PR to be merged. Proposing to get this integrated in the merge workflow soon-ish.
2. Static code analysis: More work to set up initially, will have some maintenance cost for reviewing the findings. In my opinion the benefits of having this analysis nevertheless outweigh the efforts needed and I am willing to take care of it (initially and later on). However, I am not a committer, therefore I can not do this due to the lack of access. We could still have the analysis enabled but not enforcing it on PRs though.

[rettichschnidi]

I just rebased the branch. Now that I have committer permission, I think I am able to open the relevant issues in the Eclipse Bugzilla myself.

@sbernard31 Given I am taking care of the initial (just me) and ongoing maintenance (adjusting rules, help with findings in PRs, etc.) would you be OK with moving forward?

[sbernard31]

Now that I have committer permission

🎉

@rettichschnidi should you get feedback from other members of the team before to open bugzilla ?

[rettichschnidi]

@rettichschnidi should you get feedback from other members of the team before to open bugzilla ?
👍

@qleisan @mlasch @sbernard31 @sbertin-telular Any feedback regarding my proposal?

[qleisan]

To enable the integration for your own fork, take the following steps:
Log in to https://sonarcloud.io/ using your GitHub account
Visit https://sonarcloud.io/projects/create, add Wakaama (fairly
self-explanatory)
Create a PR in your repository to verify the integration

Pushed this branch to my wakaama fork repo and got sonarcloud to execute (after setup)
Check out the result here

SonarCloud Quality Gate failed.

Bug C 3 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

99.8% 99.8% Coverage
0.0% 0.0% Duplication

[rettichschnidi]

The findings do already exist in the master code, but since master never got scanned, those show up now for the first time, causing the PR to get rejected.

Looking good (as expected) to me.

I intend to triage those findings in the master branch (in SonarCloud), but can do so only once this PR got merged.

[qleisan]

LGTM. I'm in favor of using sonarcloud

[mlasch]

Looks very promising 👍

[rettichschnidi]

@sbernard31 We are facing some issues with the setup of SonarCloud. Can I please get your +1 so that I can get admin temporary permissions on this repository to debug/fix the issue?

[sbernard31]

@rettichschnidi, done.

Sorry for the delay but I was out of office yesterday. By the way this will probably happen often during april/may because I will work something like 3 days by week during this period. (too many day off accumulated 😬 )

[rettichschnidi]

Sorry for the delay but I was out of office yesterday. By the way this will probably happen often during april/may because I will work something like 3 days by week during this period. (too many day off accumulated grimacing )

Not a problem at all - enjoy your time!

[rettichschnidi]

Turns out, that running SonarCloud for arbitrary external PRs can not be done in a secure fashion [1][2].

I will change my PR to run the analysis only on commits, not on PRs. I might come up with an improvement which allows committers to selectively run PRs using a combination of pull_request_target [3] and labels [2], but this will take a while, will be a separate PR.

[1] https://jira.sonarsource.com/browse/MMF-1371
[2] https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
[3] https://docs.github.com/en/actions/reference/events-that-trigger-workflows#pull_request_target