sourcegraph / sourcegraph-sonarqube

Show Sonarqube issues when browsing files on Sourcegraph

SonarQube Sourcegraph extension

⚠️ Deprecation notice

Sourcegraph extensions have been deprecated with the September 2022 Sourcegraph release. Learn more.

The repo and the docs below are kept to support older Sourcegraph versions.

Description

Show SonarQube issues when browsing files on Sourcegraph.

➡️ Try it out on github.com/apache/struts

You can toggle decorations with the SonarQube button in the action toolbar. Each decoration links to the issue on SonarQube.

Configuration

The extension can be configured through JSON in user, organization or global settings.

{
  // Configure the extension to use a private SonarQube instance.
  // By default, Sonarcloud is used.
  "sonarqube.instanceUrl": "https://sonarcloud.io/",
  // An API token to the SonarQube instance, if needed.
  "sonarqube.apiToken": "...",

  // The SonarQube extension needs to map the repository on Sourcegraph to a project inside an organization on
  // SonarQube. The default settings work for most projects on SonarCloud, but if you have a custom setup, you
  // can configure the following settings.

  // This regular expression is matched on the repository name. The values from the capture groups are
  // available in the templates below.
  "sonarqube.repositoryNamePattern": "(?:^|/)([^/]+)/([^/]+)$",
  // This template is used to form the SonarQube organization key.
  // By default, the second-last part of the repository name (first capture group above) is used as-is.
  // E.g. "apache" from "github.com/apache/struts".
  "sonarqube.organizationKeyTemplate": "$1",
  // This template is used to form the SonarQube project key.
  // By default, the second-last and last part of the repository name (first and second capture groups above)
  // are joined by an underscore.
  // E.g. "apache_struts" from "github.com/apache/struts".
  "sonarqube.projectKeyTemplate": "$1_$2",

  // CORS headers are necessary for the extension to fetch data, but SonarQube does not send them by default.
  // Here you can customize the URL to an HTTP proxy that adds CORS headers.
  // By default Sourcegraph's CORS proxy is used.
  // Set this to `null` to opt out of using a CORS proxy.
  "sonarqube.corsAnywhereUrl": "https://cors-anywhere.sgdev.org"
}

Limitations

The current commit viewed on Sourcegraph may not be analyzed on SonarQube. If that is the case, the extension will fallback to the latest analysis available on SonarQube on the default branch. This may result in decorations being off in some files if those files differ between the commit being viewed and the one analyzed on SonarQube.

---

SONARQUBE is a trademark belonging to SonarSource SA.

sourcegraph-sonarqube's Issues

Update readme example file to new non-broken file

Seems like it's not finding the current file, so any of the files like this one should work. Taken from SonarCloud's search.

SonarQube (capital Q) not Sonarqube

The capitalization of Q should be fixed:

It doesn't seem to be possible to disable the CORS proxy

I've got a SonarQube instance running in a K8S cluster behind an Ingress, which I have configured to include CORS headers, like so:

ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: sonarqube
  namespace: sonarqube
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/enable-cors: "true"
    nginx.ingress.kubernetes.io/cors-allow-origin: "https://url.of.private.sonarqube.instance.io"
...

This works, and all requests to the instance do include CORS headers now, therefore I don't require an external CORS proxy.

However, I can't seem to disable the sgdev.org proxy setting - if I don't set the value, or set it to blank, https://cors-anywhere.sgdev.org gets used anyway (eg Chrome records a request being sent to https://cors-anywhere.sgdev.org/https://url.of.private.sonarqube.instance.io).

Further, all requests that get sent through this proxy return a 403 error, so this extension just basically doesn't work.

Is there a way to switch this behavior off? Even if the proxy worked, I would very much prefer to not bounce our requests off of your proxy, especially since we don't need to do so.

Thanks!