Send total coverage back to GitLab instead of new coverage #225
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The coverage send back via the GitLab API should be the total coverage of the project, not the coverage of the new code in the PR. The GitLab docs explicitly mention this: https://docs.gitlab.com/ee/api/commits.html#post-the-build-status-to-a-commit The coverage reported by decorating the PR via a comment is not affected; this still shows both the total and new coverage. Note that there is an open GitLab issue for natively displaying new coverage for just the diff of a PR (https://gitlab.com/gitlab-org/gitlab/-/issues/20895), but this is not yet implemented. In addition, reporting coverage back is optional. So if there is no coverage information, we do not report it back.
|
Whoops, I was a bit overzealous in the housekeeping of my fork of this project -- I didn't mean to close the PR. Reopening now. |
|
Any news on this ? |
|
@mc1arke Could this be merged? Thanks. 😄 |
|
Kudos, SonarCloud Quality Gate passed! |
|
Merged. Thanks for your contribution! |
|
@mc1arke just ran an analysis with sonarqube 9.5 and with plugin version 1.12.0 and the reported coverage in the SonarQube external job is the new code coverage and not the total coverage.
Maybe should revisit this? |
Karql
referenced
this pull request
Mar 21, 2023
The access to metrics from a Pull Request analysis is exposed through an `AnalysisDetails` instance, which also provides the ability to extract a formatted report. As a number of the metrics used in the summary report need to be retrieved through various additional DAOs, and as the resolution of URLs for links and images requiring access to core Sonarqube configuration, `AnalysisDetails` holds references to a high number of classes from Sonarqube's core. Some of those core Sonarqube classes are also referenced directly in some decorators which don't make use of the summary report but need equivalent metrics to those shown in the summary which means some searching logic is duplicated across the plugin. This change pulls the report generation into a `ReportGenerator` class, with the report being an interim set of collected metrics that each decorator can extract required information, or generate a formatted report from.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reworked version of #157 (and #145). Third time's the charm, right? 🤞
The coverage send back via the GitLab API should be the total coverage
of the project, not the coverage of the new code in the PR. The GitLab
docs explicitly mention this:
https://docs.gitlab.com/ee/api/commits.html#post-the-build-status-to-a-commit
The coverage reported by decorating the PR via a comment is not affected;
this still shows both the total and new coverage.
Note that there is an open GitLab issue for natively displaying new coverage
for just the diff of a PR (https://gitlab.com/gitlab-org/gitlab/-/issues/20895),
but this is not yet implemented.
In addition, reporting coverage back is optional. So if there is no coverage
information, we do not report it back.