Add SonarQube Analysis for PRs

[anarsultanov]

This PR introduces a custom GitHub Action to address Issue #19467 by adding SonarQube reports to PRs, enabling the detection of newly introduced issues and helping maintain high code quality in the project.

Summary:

• Implementation: Introduces a GitHub Action that runs SonarQube analysis using Docker.
• Caching Mechanism: On pushes to the main branch, the entire generated application is cached. This cache is then restored during PR analysis.
• PR Analysis: The cached main branch project is analyzed first, followed by the analysis of the PR changes. This process allows to identify and report only the issues newly introduced in the PR.

Simplification Suggestion:

We could simplify the approach by analyzing the generated project directly instead of focusing on the changes. This would streamline the workflow, eliminate the dependency on caching, and allow the use of the official SonarQube Community Edition image.

---

Please make sure the below checklist is followed for Pull Requests.

• All continuous integration tests are green
• Tests are added where necessary
• The JDL part is updated if necessary
• jhipster-online is updated if necessary
• Documentation is added/updated where necessary
• Coding Rules & Commit Guidelines as per our CONTRIBUTING.md document are followed

When you are still working on the PR, consider converting it to Draft (below reviewers) and adding skip-ci label, you can still see CI build result at your branch.

[mshima]

• the sonar container version should be reproducible and be loaded from generator-jhipster provided version instead of using latest.
  A new release will introduce errors/bugs without warnings.
• new issues is only reported after a period. AFAIK there is no way to check new issues between 2 checks. the pr is simulating a PR so it may work.
• PR comments requires a token to work.
• code coverage won't work without caching tests result.

[mshima]

We could simplify the approach by analyzing the generated project directly instead of focusing on the changes. This would streamline the workflow, eliminate the dependency on caching, and allow the use of the official SonarQube Community Edition image.

JHipster Lite is quite different.
JHipster generates MUCH more code.
A couple of months ago we did some work to reduce sonar issues/bugs and we got it down to 12 issues, a new sonar release and the number jumped to more than 100 issues, we reduced to 12 again, another sonar release and 300 issues are reported.
Targeting 0 issues is not doable for us.
The goal is to don't introduce new issues and make easier to check if issues are been fixed by a PR.

[anarsultanov]

Thank you for the review and comments, @mshima.

• SonarQube Version: I agree with using a specific SonarQube version instead of latest to ensure reproducibility and avoid unexpected issues with new releases. However, I’m not entirely clear on how generator-jhipster should provide a version to the action. Could you clarify that part?

• PR Simulation: Exactly, we simulate pull request analysis using a plugin that allows this in the Community version of SonarQube, which makes it feasible in our setup.

• PR Comments and Token Requirement: You’re absolutely right about the token requirement. As I understand it, even the default GITHUB_TOKEN won’t work for comments when the workflow is triggered by forks. We would need either a PAT (Personal Access Token) or a GitHub App-generated token. If that’s not feasible, we might consider removing the comment feature and relying solely on the logs.
  Update: Another options seems to be to use the pull_request_target event to ensure the workflow has the necessary permissions to comment on PRs. However, this approach also requires extra caution to avoid executing untrusted code.

• Code Coverage and Caching: Test results are cached along with the entire project after all tests have been run, ensuring that code coverage is properly handled.

[mshima]

• SonarQube Version: I agree with using a specific SonarQube version instead of latest to ensure reproducibility and avoid unexpected issues with new releases. However, I’m not entirely clear on how generator-jhipster should provide a version to the action. Could you clarify that part?

Sonar version should be get from

generator-jhipster/generators/server/resources/Dockerfile

Line 52 in 02be3b9

FROM sonarqube:10.6.0-community

Like we get node/java/npm versions and build ci matrix with them.

[mshima]

• PR Comments and Token Requirement: You’re absolutely right about the token requirement. As I understand it, even the default GITHUB_TOKEN won’t work for comments when the workflow is triggered by forks. We would need either a PAT (Personal Access Token) or a GitHub App-generated token. If that’s not feasible, we might consider removing the comment feature and relying solely on the logs.
  Update: Another options seems to be to use the pull_request_target event to ensure the workflow has the necessary permissions to comment on PRs. However, this approach also requires extra caution to avoid executing untrusted code.

---

pull_request_target should be avoided.
We should try a Fine-grained PAT with ISSUES and PR comment only.

@DanielFran can you generate a Fine grained PAT with PR and ISSUES (to be used in https://github.com/jhipster/generator-jhipster/blob/main/.github/workflows/issue-check.yml workflow) comment permission?

[anarsultanov]

• SonarQube Version: I agree with using a specific SonarQube version instead of latest to ensure reproducibility and avoid unexpected issues with new releases. However, I’m not entirely clear on how generator-jhipster should provide a version to the action. Could you clarify that part?

Sonar version should be get from

generator-jhipster/generators/server/resources/Dockerfile

Line 52 in 02be3b9

FROM sonarqube:10.6.0-community

Like we get node/java/npm versions and build ci matrix with them.

To be able to analyze differences (using pull request analysis), we have to use the mc1arke/sonarqube-with-community-branch-plugin image, as the standard SonarQube Community Edition does not support this feature. Should we consider adding another entry to the Dockerfile for this specific image, or is there a preferred approach to handle this?

[mshima]

• SonarQube Version: I agree with using a specific SonarQube version instead of latest to ensure reproducibility and avoid unexpected issues with new releases. However, I’m not entirely clear on how generator-jhipster should provide a version to the action. Could you clarify that part?

Sonar version should be get from

generator-jhipster/generators/server/resources/Dockerfile

Line 52 in 02be3b9

FROM sonarqube:10.6.0-community

Like we get node/java/npm versions and build ci matrix with them.

To be able to analyze differences (using pull request analysis), we have to use the mc1arke/sonarqube-with-community-branch-plugin image, as the standard SonarQube Community Edition does not support this feature. Should we consider adding another entry to the Dockerfile for this specific image, or is there a preferred approach to handle this?

A specific Dockerfile in test-integration/sonar-pr then?
It's possible to use the Dockerfile instead of passing the version through matrix.

[anarsultanov]

A specific Dockerfile in test-integration/sonar-pr then? It's possible to use the Dockerfile instead of passing the version through matrix.

I'm not entirely sure I understand the requirement. Do you mean creating a Dockerfile in test-integration/sonar-pr that inherits from the specific image (e.g., FROM mc1arke/sonarqube-with-community-branch-plugin:10.3-community), which we then build and start during the workflow? I’m wondering what the benefit of this approach would be compared to simply specifying the version directly in the action.

[mshima]

A specific Dockerfile in test-integration/sonar-pr then? It's possible to use the Dockerfile instead of passing the version through matrix.

I'm not entirely sure I understand the requirement. Do you mean creating a Dockerfile in test-integration/sonar-pr that inherits from the specific image (e.g., FROM mc1arke/sonarqube-with-community-branch-plugin:10.3-community), which we then build and start during the workflow? I’m wondering what the benefit of this approach would be compared to simply specifying the version directly in the action.

Reproducible version and auto update through dependabot.

[mshima]

A docker-compose file with renovate auto update is an alternative.

[anarsultanov]

Reproducible version and auto update through dependabot.
A docker-compose file with renovate auto update is an alternative.

Thanks for the clarification. We could use a custom manager if Renovate doesn’t detect the dependency in the action, but adding a Dockerfile might be simpler. I’ll push this change together with the token once it’s created by @DanielFran

[DanielFran]

ISSUES and PR comment only

@mshima @anarsultanov I created JHIPSTER_PAT_PR_ISSUES token

[mshima]

@DanielFran have you added to repository secrets?

[DanielFran]

@DanielFran have you added to repository secrets?

Yes, it can be used PAT_PR_ISSUES_TOKEN

[mshima]

• if cache does not match, the overall issues should be shown.

[mshima]

use kebab case instead of snake case. It's the default for actions.

[mshima]

Dockerfile needs to be added to dependabot config:

generator-jhipster/.github/dependabot.yml

Lines 198 to 207 in 1ffb5de

	- package-ecosystem: 'docker'
	directory: '/generators/server/resources/'
	schedule:
	interval: 'daily'
	time: '00:20'
	open-pull-requests-limit: 5
	labels:
	- 'theme: dependencies'
	- 'theme: docker :whale:'
	- 'skip-changelog'

[anarsultanov]

Seems like some issue with token: Error: Parameter token or opts.auth is required
And based on this, it might not even be possible to make it work with:

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository.

One option we can try is to load the result into artifacts since it uses some other token that might be accessible.

Update: but if you want to keep things as is, to only get comments on pull requests created directly in the repository, we can get rid of the PAT and rely on the default token.

[mshima]

Polish

[mshima]

Fold log to improve readability.

[anarsultanov]

Bounty claimed https://opencollective.com/generator-jhipster/expenses/217026

[DanielFran]

@anarsultanov approved