The wiremock based tests currently fail if another service is running on
on port 8080, and other tests fail with newer dependencies due to
changes in recursive comparisons. The wiremock tests are being altered
to use a random port for runs to prevent port conflict, and the tests
comparing HTTP entities are being altered to extract the InputStream for
comparing the contents from.
The character encoding is being set in Gradle to ensure that the build doesn't use Operating system specific encodings that will cause differences between builds of the same code on different machines.
The key for the Code Insights report uses a static value which results
in any report submitted by Sonarqube overwriting any existing report,
even where reports are submitted from different projects, such as would
happen in a mono-report setup. The report key is therefore being changed
to use the project key, so that repeated scans from a single project
continue to overwrite each other, whilst scans against the same
repository from different projects will allow new reports to be
submitted without altering existing reports.
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.
The text renderer for the `MarkdownFormatterFactory` had been performing
a `trim` on any inputs, which caused the single whitespace entries being
added as spacers after some inline images to be removed. As the
structure of the document should be presumed to match what the
generating component requires, it's unnecessary for the renderer to
attempt to alter this structure whilst rendering to a relevant document
format. Instead, any constraints on formatting should be left to the
system rendering the generated output.
The Formatters for generating the analysis report are created by a
FormatterFactory, but then need a formatter factory passed into them
during execution. This allows a potential scenario where a Formatter
could be passed a FormatterFactory for a different output type so
generate invalid content type, as well as causing a non-optimal API.
This change alters the FormatterFactory to be the component that is
aware of how to create Formatters for child components, rather than the
formatters doing this, therefore removing the need for a
FormatterFactory to be made available in formatters.
The GithubClient interface exposes a method that takes various Sonarqube
core classes and plugin constructed data as arguments and returns a
`DecorationResult`, all of which are items that the upstream decorator
should be aware of, but not the client responsible for communicating
with Github. Similarly, the `GraphqlGithubClient` had locally
constructed a `MarkdownFormatterFactory`, `DefaultGraphqlProvider`, and
`Clock` as well as requiring a Sonarqube `Server` instance for
instantiation, with the local construction requiring a second
constructor to be included purely for testing, and the `Server` instance
requiring the client have knowledge of Sonarqube's structure rather than
being passed a client configuration that had no external dependencies in
it.
This change alters the GithubClient implementation to use dependency
injection for all re-usable objects, and introduces a Github specific
object for submitting a check run, rather than relying on the
`AnlaysisDetails` object used in the plugin. The use of the settings
DTOs has been removed from the client, with the details being used in
the client factory and the relevant details being persisted in the
client from the constructor invocation. To support this, the
`MarkdownFormatterFactory` has been setup to be exposed for constructor
injection in Compute Engine components, and the `DefaultGraphqlProvider`
exposed in both Compute Engine and Server scopes.
The requirement of passing a `projectPath` inside the GithubClient has
also been removed, with the repository name and owner login being
extracted during the authentication phase and stored in the token for
the client to use them where needed.
The Bitbucket clients require different properties to be used from the
relevant configuration DTOs depending on whether Bitbucket cloud or
server are being used, with the management of the property retrieval
being delegated to the relevant client implementation. However, this
requires each client to reference DTO classes from Sonarqube core, where
the clients should really only interact with their own models.
As the work on retrieving the relevant details has already been
performed in the `DefaultBitbucketClientFactory`, the logic for
performing the retrieval has been removed from each client
implementations, and the calculated values are passed into the
constructor for each client instead. This does make each client instance
constrained to a single repository, but given the way the clients are
used within the decorators and validators, this isn't an issue.
The client API has therefore been altered to remove the references to
project and repository in any method signatures since the client now
retrieves this internally from the client configuration.
The clients have also been altered now to depend directly on the status
from the Quality Gate, with a new enum being used by the client to
indicate the report status, and the decorator performing the mapping
between the Quality Gate and report status.
Finally, to allow for the `DefaultBitbucketClientFactory` to have a
single constructor rather than a test-specific constructor, the facility
for creating an Http Client has been moved into an
`HttpClientBuilderFactory` and this new class configured for injection
in both the Compute Engine and server components.
The plugin previously only provided support for auto-detecting and
configuring the scanner properties for a Pull Request in Azure Devops
and a Merge Request or Branch in Gitlab CI. The Sonarqube documentation
also stated that Bitbucket Pipelines, Github Actions, CodeMagic, Jenkins
Branch API, and Cirrus CI could also be used to auto-discover Pull
Request or Branch information although the plugin did not provide these.
This change adds support for detecting these additional CIs based on the
various environment variables they provide, and to auto-configure Pull
Request or Branch parameters in the scanner when a suitable build job
is detected.
Includes the general clean-up of the creation of Branch and Pull Request
configuration to force fail-fast behaviour where target branches are not
provided or can't be matched against known branches, to ensure the
correct reference branch is selected for Pull Request analysis, and to
force an error to be displayed if a user mixes Pull Rrequest and Branch
parameters in their launch properties.
Updates Gradle to 7.3. Includes a modification to the Docker builder image to use a Gradle image rather than a JDK and the Gradle wrapper, as this allows caching of the Gradle image and possibly any interim steps rather than having to use the wrapper to download the full Gradle distribution on every build.
The AdoptOpenJDK has been discontinued since July 2021 (https://adoptopenjdk.net). Switching the distribution to Azul Zulu. When using Zulu you get all the latest updated (TCK Tested) builds for all versions of OpenJDK.
**Note:** Other distributions such as Temurin do not support archived fixed releases prior to Sept. 2021 and many non LTS (long term support) releases if you plan to try out newer features in the language.
When calling the Gitlab API with content that contains accented or cyrillic characters, the API returns an error response and fails to complete the decoration. Explicitly setting the encoding for all body content to UTF-8 on Gitlab API requests results in the content being encoded in a way for the Gitlab API handles correctly.
Sonarqube 9.1 encrypts the sensitive fields for DevOps decorators, such as private keys and personal access tokens. To allow the decorators to access these properties, the relevant methods now require encryption details to be provided, so the encryption handlers are now being loaded from the internal Sonarqube settings and passed to the appropriate target methods.
A change is also required in `SetBindingsAction` to pass additional fields for recording on the audit log when settings are saved. No additional settings are being added for the auditing as community edition does not provide a user interface for accessing audit logs, and uses a default cleaner task for purging logs after 30 days.
Azure DevOps does not correctly resolve URLs that contains spaces encoded as a `+`. To allow projects containg spaces to be decorated, the `+` from an the encoded names is being replaced with a `%20` since Azure Devops resolves spaces encoded this way properly.
Azure DevOps on-premise responds with an error if the `-preview` is not appended to the version number during the request to submit the pipeline status during Pull Request decoration. As the use of a preview version for this call does not seem to adversely affect invocation of this endpoint on Azure DevOps Cloud, the `-preview` flag has been unconditionally added to the status update, although it has not been added to any other invocations since they do not encounter the same error.
