Refactor Bitbucket operations to prevent leaking scope #574

mc1arke · 2022-04-08T21:56:11Z

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 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.