SonarQube
Port's SonarQube integration allows you to model SonarQube resources in your software catalog and ingest data into them.
Core support
Setup
Choose your preferred installation method below. Not sure which to pick? See the installation methods overview.
Configuration
Port integrations use a YAML mapping block to ingest data from the third-party api into Port.
The mapping makes use of the JQ JSON processor to select, modify, concatenate, transform and perform other operations on existing fields and values from the integration API.
Default mapping configuration
This is the default mapping configuration for this integration:
Default mapping configuration (click to expand)
deleteDependentEntities: true
createMissingRelatedEntities: true
enableMergeEntity: true
resources:
- kind: projects_ga
selector:
query: 'true'
apiFilters:
qualifier:
- TRK
metrics:
- code_smells
- coverage
- bugs
- vulnerabilities
- duplicated_files
- security_hotspots
- new_violations
- new_coverage
- new_duplicated_lines_density
port:
entity:
mappings:
identifier: .key
title: .name
blueprint: '"sonarQubeProject"'
properties:
organization: .organization
link: .__link
qualityGateStatus: .__branch.status.qualityGateStatus
lastAnalysisDate: .analysisDate
numberOfBugs: .__measures[]? | select(.metric == "bugs") | .value
numberOfCodeSmells: .__measures[]? | select(.metric == "code_smells") | .value
numberOfVulnerabilities: .__measures[]? | select(.metric == "vulnerabilities") | .value
numberOfHotSpots: .__measures[]? | select(.metric == "security_hotspots") | .value
numberOfDuplications: .__measures[]? | select(.metric == "duplicated_files") | .value
coverage: .__measures[]? | select(.metric == "coverage") | .value
mainBranch: .__branch.name
revision: .revision
managed: .managed
relations:
group: '"all_teams"'
- kind: issues
selector:
query: 'true'
apiFilters:
resolved: 'false'
projectApiFilters: {}
port:
entity:
mappings:
identifier: .key
title: .message
blueprint: '"sonarQubeIssue"'
properties:
type: .type
severity: .severity
link: .__link
status: .status
assignees: .assignee
tags: .tags
createdAt: .creationDate
relations:
sonarQubeProject: .project
Mapping & selectors per resource
Use the explorer below to view sample payloads and the resulting Port entities for each resource type. For additional resources and advanced configurations, see the examples page.
Set up live events
This integration supports live events, allowing real-time updates to your software catalog without waiting for the next scheduled sync.
Note that different events are supported depending on the resource type.
- Hosted by Port
- Self-hosted
Live events base URL
For integrations installed using the Hosted by Port method, you can obtain the live events base URL from the Get an integration API. The response includes liveEventsUuid and liveEventsIngestHostname in the appSpec section.
Call the endpoint with your integration's identifier:
curl -X GET \
'https://api.port.io/v1/integration/<INTEGRATION_IDENTIFIER>' \
-H 'Authorization: Bearer <PORT_ACCESS_TOKEN>'
The port_region, port.baseUrl, portBaseUrl, port_base_url and OCEAN__PORT__BASE_URL parameters select which Port API instance to use:
- EU (app.port.io) →
https://api.port.io - US (app.us.port.io) →
https://api.us.port.io
In the response, look for the following fields under spec.appSpec:
{
"spec": {
"appSpec": {
"liveEventsUuid": "abcdefghijk",
"liveEventsIngestHostname": "ingest.ocean.getport.io"
}
}
}
Combine them to build the live events base URL:
https://<liveEventsIngestHostname>/live-events/<liveEventsUuid>
For example, with the values above, the live events base URL is:
https://ingest.ocean.getport.io/live-events/abcdefghijk
This is the same URL configured for the integration.
BaseUrl & webhook configuration
To enable real-time updates of the data in your software catalog, you need to define the liveEvents.baseUrl parameter.
This parameter should be set to the URL of your SonarQube integration instance, which needs to have the option to setup webhooks via HTTP requests/receive HTTP requests, so ensure the network is configured accordingly.
- If SonarQube and the integration are in the same cluster/network: Use an internal URL (e.g., a Kubernetes service DNS name).
For Kubernetes deployments, create a service to expose the integration pod and use the service URL asliveEvents.baseUrl. If both the source system and integration are in the same cluster, an internal ClusterIP service is sufficient. - If SonarQube is external to the integration's network: The integration must be exposed via an ingress, load balancer, or public URL that SonarQube can reach.
If liveEvents.baseUrl is not provided, the integration will continue to function correctly. In such a configuration, to retrieve the latest information from the target system, the scheduledResyncInterval parameter has to be set, or a manual resync will need to be triggered through Port's UI.
To test webhooks or live event delivery to your local environment, expose your local pod or service to the internet using ngrok (e.g. ngrok http http://localhost:8000)
Monitoring and sync status
To learn more about how to monitor and check the sync status of your integration, see the relevant documentation.
Examples
To view and test the integration's mapping against examples of the third-party API responses, use the jq playground in your data sources page. Find the integration in the list of data sources and click on it to open the playground.
Examples of blueprints and the relevant integration configurations can be found on the sonarqube examples page