The Nodes dependency used for GraphQL communication in the Github Pull Request decorator is no longer available on Bintray due to Bintray being decommissioned, and is not available in the target version from any other repository. The JAR is therefore being included in the workspace and referenced directly in the build.gradle dependencies, and the Jackson dependency that was previously inherited through the Nodes dependency is being added directly to the project as a runtime dependency to ensure the relevant classes are still available during plugin execution.
This change adds the relevant docker files to allow building a development docker image containing the code in this repository, or generating an image using a released version of the plugin, with either of these being backed by a particular base Docker image of Sonarqube's community releases. The `.env` file contains the variables required to configure what builds is performed with docker-compose.yml then driving the relevant creation from there.
When submitting the status of a merge request to Gitlab, the plugin was attempting to submit to a commit on the MR's target project, but was getting a `404 Not Found` response from the Gitlab API where the source project was not the same as the target project, such as the source project being a fork. This change retrieves the MR details from the Gitlab API and retrieves the source project ID for use during subsequent decoration calls, so the commit will be searched for in the correct project.
Sonarqube 8.7 removed the concept of the `OrganizationDto` and removed the reference to this class in the `BranchSupportDelegate` interface, so the `CommunityBranchSupportDelegate` implementation has had to update the relevant method signature, therefore making this version of the plugin binary incompatible with older versions of Sonarqube.
Alongside this, various webservice endpoints for configuring the global ALM definitions have been moved into the Community edition from the commercial Sonarqube editions, so have been removed from this plugin to prevent the bundled definitions conflicting with the plugin versions.
As Sonarqube Community Edition now has direct UI options for configuring Bitbucket Cloud, the relevant endpoints have been introduced for supporting this UI, and the Bitbucket Cloud client used for Pull Request decorating has been updated to use OAuth 2 credential negotiation for authenticating, rather than using the Basic authentication previously used on all requests.
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.
When a background task for a pull request analysis is cancelled, a subsequent attempt to re-scan the pull request fails in the scanner since the `analysisDate` field is no longer present against the pull request. This change handles this missing date in a better manner, defaulting to having a `0` analysis date in the same way an error parsing the analysis date would.
In #237 the property names of the annotation model were changed to fix a bug with how code annotations are reported to Bitbucket Cloud. This PR however did not take into consideration that the previous naming was actually correct and required for Bitbucket Server. With this change Bitbucket Cloud will continue to receive the message as summary (API docs), while Bitbucket Server receives the message as message again (API docs).
The @JsonProperty annotations have been moved to the getters so that they support overrides, as mixing property-level and method-level annotations does not work for this use case. Technically this is only needed for the message property, but for consistency reasons this has been done for all fields and has been verified that this is mapped correctly for both cloud and server.
This commit fixes an issue with Bitbucket Cloud if more than 100 annotations
are present. Annotations will be chunked from now on on batches of 100 until
the total allowed of 1000 is reached.
For Bitbucket Server nothing changed.
Closes#209
Sonarqube 8.5.0 removed the `BranchSupport.Branch` class which breaks backwards-compatibility with previous Sonarqube versions, and requires updating how the ComponentKey is checked and generated during the creation of the analysis report. This version of Sonarqube also moves the bundled plugins into their own directory, so the build classpath has been updated to exclude those plugins from being able to be part of the compilation path, and updates the class-loading unit tests to reference a plugin class and file path that is still available in the newer Sonarqube version.
Includes additional Web Service parameters introduced in Sonarqube 8.4.0 for configuring Github ALM integration so that these values can be persisted when provided, even though the plugin does not actually require them.
There are situations where Bitbucket server is returning an error during API calls, but has no messages specified in the response body, so is causing a `NullPointerException` to be thrown by the plugin whilst attempting to provide details on the error. Specifically checking for the messages not being present allows for the underlying HTTP status code to be returned in the exception details so the user can get a better understanding of what the issue is.
The collection of `DefaultIssue` objects hold by the `PostAnalysisIssueVisitor` can take a significant amount of memory in the CE process heap when there are numerous issues. A `DefaultIssue` alone can weigh several 10s of kilobytes.
This change introduces a `PostAnalysisIssueVisitor.LightIssue` that contains a subset of the fields from `DefaultIssue` that are required during Pull Request decoration, thereby allowing the full `DefaultIssue` instances not to be retained on the heap.
The Bitbucket decoration was incorrectly mapping the issue URL into the annotation summary field, so Bitbucket was rendering a link instead of the issue summary. The relevant annotations are being updated to ensure the correct fields are set on the Bitbucket decoration.
SonarQube 8.2 introduced the ability to set the repository ID through the front-end for use when decorating a Gitlab Merge Request, although this was missed from the plugin when implementing the appropriate interfaces. This change therefore introduces the required implementation, and additional only attempts to resolve the server ID from scanner properties when the ID has not been set through the front-end,
If multiple micro-services are modified at once then only the final Sonarqube PR decoration appeared in the checks tab of Github. This change updates the name of the Status check to include the Sonarqube project name so that multiple checks can be attached to the one pull request.
Sonarqube 8.2 introduced a new `ProjectDto` with associated changes in `ProjectAlmSettingsDao` to require this new class in various methods, as well as changes in `ComponentFinder` to allow retrieval of instances of a project. This change makes use of these new classes and methods to allow the Web Services for setting up ALM bindings to operate.
As this class and the associated methods did not exist in previous versions of Sonarqube, this change breaks backwards compatibility, so means the plugin will now only support Sonarqube 8.2.
Sonarqube 8.2 also provides the ability to set the optional URL parameter on a Gitlab project so that scans run outside of Gitlab CI operate properly, so the additional parameter is now included in the appropriate WebServices and the Gitlab decorator.
This commit provides support for the newly created bitbucket cloud code insights
API endpoints. The implementation has been done under the consideration that in
newer versions no dedicated ALM support for bitbucket cloud exists, thus this
implementation is minimal invasive.
One thing to note here:
* For local testing the link on CloudCreateReportRequest has to be set manually to a non localhost URL since
bitbuckets API doesn't support it.
The release process has been updated to look for a commit to the gradle.properties file that removes the '-SNAPSHOT' suffix from the version number rather than being triggered off the push of a tag.
On Github Pull Request decoration, annotation for single line issues are reported on the wrong line, because end line of the annotated error is incorrectly incremented by one.
As part of the migration so using the new Sonarqube 8.1 APIs, the order of the ALM Slug and ALM Repo are being injected the wrong way round into the Bitbucket URL, so the project is not being found. Switching the properties to the correct order overcomes this issue and allows Pull Request decoration to complete.
Only decorate with unresolved and non closed issues on Github pull requests.
Currently, fixed issues are still displayed on line 0 of the file, although it is correctly marked as fixed in Sonarqube.
The Github ALM Binding Web Service uses the `AlmRepo` field to store the repository name, but the Github decorator was using `AlmSlug` to try and retrieve the repository name, so was getting a `null` value back and failing to find a matching repository. Switching to using `AlmRepo` in the decorator overcomes this issues.
