Browse Source
Revert "MMF-1458 Port SONAR-space docs to embedded docs" (#766)
This reverts commit a7893ef0a2.
tags/7.5
G. Ann Campbell
5 years ago
51 changed files with 34 additions and 2705 deletions
+ 5
- 7
server/sonar-docs/README.md
View File
| @@ -68,14 +68,13 @@ As documentation writers there are two ways it is possible for us to break the S | |||
| * broken links | |||
| Even without spinning up servers, you can double-check that your changes won't break the build. | |||
| **Test everything** | |||
| **Test everything** | |||
| You can run all the tests, and make sure that both your markup is well-formed and your links are correct by running the build script: | |||
| ``` | |||
| cd sonar-enterprise/ | |||
| ./build.sh -x test -x obfuscate | |||
| ``` | |||
| **Test links only** | |||
| **Test links only** | |||
| If you only want to double-check your links changes, you can | |||
| ``` | |||
| cd sonar-enterprise/server/sonar-docs | |||
| @@ -105,13 +104,13 @@ Ex.: | |||
| ``` | |||
| --- | |||
| title: Demo page | |||
| url: /sonarcloud-pricing/ | |||
| url: /sonarcloud-pricing | |||
| --- | |||
| ``` | |||
| ** Metadata conventions** | |||
| * Metadata tags can appear in any order, but by convention, `title` should come first. | |||
| * The `url` tag is required, and should start and end with '/' | |||
| * The `url` tag is optional, but by convention, should be specified to both make the publish path explicit and avoid problems potentially caused by moving or renaming files. | |||
| ### Includes | |||
| @@ -222,8 +221,7 @@ baz | |||
| Basic syntax: | |||
| ``` | |||
| [[collapse]] | |||
| ```[[collapse]] | |||
| | ## Block title | |||
| | Block content | |||
| ``` | |||
BIN
server/sonar-docs/src/images/architecture-integrate.png
View File
BIN
server/sonar-docs/src/images/architecture-scanning.png
View File
BIN
server/sonar-docs/src/images/encrypt-value.png
View File
BIN
server/sonar-docs/src/images/http-header-authentication.png
View File
BIN
server/sonar-docs/src/images/rule-template-details.png
View File
BIN
server/sonar-docs/src/images/rule-templates.png
View File
BIN
server/sonar-docs/src/images/rules-custom.png
View File
+ 1
- 1
server/sonar-docs/src/layouts/components/Footer.js
View File
| @@ -32,7 +32,7 @@ export default function Footer() { | |||
| src="https://licensebuttons.net/l/by-nc/3.0/us/88x31.png" | |||
| /> | |||
| </a> | |||
| © 2008-2018, SonarSource S.A, Switzerland. Except where otherwise noted, content in this space | |||
| © 2008-2017, SonarSource S.A, Switzerland. Except where otherwise noted, content in this space | |||
| is licensed under a{' '} | |||
| <a | |||
| href="https://creativecommons.org/licenses/by-nc/3.0/us/" | |||
+ 0
- 103
server/sonar-docs/src/pages/analysis/analysis-parameters.md
View File
| @@ -1,103 +0,0 @@ | |||
| --- | |||
| title: Analysis Parameters | |||
| url: /analysis/analysis-parameters/ | |||
| --- | |||
| ## Table of Contents | |||
| Parameters to configure project analysis can be set in multiple places. Here is the hierarchy of parameters: | |||
| * Global analysis parameters, defined in the UI, apply to all the projects (From the top bar, go to **[Administration > Configuration > General Settings](/#sonarqube-admin#/admin/settings)**) | |||
| * Project analysis parameters, defined in the UI, override global parameters (At a project level, go to Administration > General Settings) | |||
| * Project analysis parameters, defined in a project analysis configuration file or an analyzer configuration file, override the ones defined in the UI | |||
| * Analysis / Command line parameters, defined when launching an analysis, override project analysis parameters | |||
| Note that only parameters set through the UI are stored in the database. | |||
| For example, if you override the sonar.exclusions parameter via command line for a specific project, it will not be stored in the database. Local analyses in Eclipse, for example, would still be executed with the exclusions defined in the UI and therefore stored in the DB. | |||
| Note that the list of parameters below is not exhaustive. Most of the property keys shown in the interface, at both global and project levels, can also be set as analysis parameters. However, exclusions/inclusions are far easier to manage in the UI. | |||
| ## Mandatory Parameters | |||
| ### Server | |||
| Key | Description | Default | |||
| ---|----|--- | |||
| `sonar.host.url`| the server URL | http://localhost:9000 | |||
| ### Project Configuration | |||
| Key | Description | Default | |||
| ---|----|--- | |||
| `sonar.projectKey`|The project's unique key. Allowed characters are: letters, numbers, `-`, `_`, `.` and `:`, with at least one non-digit. | For Maven projects, this is automatically set to `<groupId>:<artifactId>` | |||
| `sonar.sources` | Comma-separated paths to directories containing source files. | Read from build system for Maven, Gradle, MSBuild projects | |||
| ## Optional Parameters | |||
| ### Project Identity | |||
| Key | Description | Default | |||
| ---|----|--- | |||
| `sonar.projectName`|Name of the project that will be displayed on the web interface.|`<name>` for Maven projects, otherwise project key. If there is already a name in the DB, it won't be overwritten | |||
| `sonar.projectVersion` | The project version. | `<version>` for Maven projects, otherwise "not provided" | |||
| ### Authentication | |||
| If the "Anyone" pseudo-group does not have permission to perform analyses, you'll need to supply the credentials of a user with Execute Analysis permission for the analysis to run under. | |||
| Key | Description | Default | |||
| ---|----|--- | |||
| `sonar.login` | The login or authentication token of a {instance} user with Execute Analysis permission on the project. | | |||
| `sonar.password` | The password that goes with the `sonar.login` username. This should be left blank if an authentication token is being used. | | |||
| ### Web Services | |||
| Key | Description | Default | |||
| ---|----|--- | |||
| `sonar.ws.timeout` | Maximum time to wait for the response of a Web Service call (in seconds). Modifying this value from the default is useful only when you're experiencing timeouts during analysis while waiting for the server to respond to Web Service calls. | 60 | |||
| ### Project Configuration | |||
| Key | Description | Default | |||
| ---|----|--- | |||
| `sonar.projectDescription` | The project description. Not compatible with Maven. | `<description>` for Maven projects | |||
| `sonar.links.homepage` | Project home page. Not compatible with Maven. | `<url>` for Maven projects | |||
| `sonar.links.ci` | Continuous integration. Not compatible with Maven. | `<ciManagement><url>` for Maven projects | |||
| `sonar.links.issue` | Issue tracker. Not compatible with Maven. | `<issueManagement><url>` for Maven projects | |||
| `sonar.links.scm` | Project source repository. Not compatible with Maven. | `<scm><url>` for Maven projects | |||
| `sonar.links.scm_dev` | Developer connection. Not compatible with Maven. | `<scm><developerConnection>` for Maven projects | |||
| `sonar.tests` | Comma-separated paths to directories containing tests. Not compatible with Maven. | Default tests location for Java Maven projects. | |||
| `sonar.sourceEncoding` | Encoding of the source files. Ex: `UTF-8`, `MacRoman`, `Shift_JIS`. This property can be replaced by the standard property `project.build.sourceEncoding` in Maven projects. The list of available encodings depends on your JVM. | System encoding | |||
| `sonar.externalIssuesReportPaths` | Comma-delimited list of paths to Generic Issue reports. | | |||
| `sonar.projectDate` | Assign a date to the analysis. This parameter is only useful when you need to retroactively create the history of a not-analyzed-before project. The format is `yyyy-MM-dd`, for example: 2010-12-01. Since you cannot perform an analysis dated prior to the most recent one in the database, you must analyze recreate your project history in chronological order, oldest first.  Note: You may need to adjust your housekeeping settings if you wish to create a long-running history. | Current date | |||
| `sonar.projectBaseDir` | Use this property when you need analysis to take place in a directory other than the one from which it was launched. E.G. analysis begins from `jenkins/jobs/myjob/workspace` but the files to be analyzed are in `ftpdrop/cobol/project1`. The path may be relative or absolute. Specify not the the source directory, but some parent of the source directory. The value specified here becomes the new "analysis directory", and other paths are then specified as though the analysis were starting from the specified value of `sonar.projectBaseDir`. Note that the analysis process will need write permissions in this directory; it is where the `sonar.working.directory` will be created. | | |||
| `sonar.working.directory` | Set the working directory for an analysis triggered with the SonarQube Scanner or the SonarQube Scanner for Ant (versions greater than 2.0). This property is not compatible with the SonarScanner for MSBuild. Path must be relative, and unique for each project.  Beware: the specified folder is deleted before each analysis. | `.sonar` | |||
| `sonar.scm.provider` | This property can be used to explicitly tell {instance} which SCM plugin should be used to grab SCM data on the project (in case auto-detection does not work). The value of this property is always lowercase and depends on the plugin (ex. "tfvc" for the TFVC plugin). Check the documentation page of each plugin for more. | | |||
| `sonar.scm.forceReloadAll` | By default, blame information is only retrieved for changed files. Set this property to `true` to load blame information for all files. This can be useful is you feel that some SCM data is outdated but {instance} does not get the latest information from the SCM engine. | | |||
| ### Duplications | |||
| Key | Description | Default | |||
| ---|----|--- | |||
| `sonar.cpd.exclusions` | Comma-delimited list of file path patterns to be excluded from duplication detection | | |||
| `sonar.cpd.${language}.minimumtokens` | A piece of code is considered duplicated as soon as there are at least 100 duplicated tokens in a row (overide with `sonar.cpd.${language}.minimumTokens`) spread across at least 10 lines of code (override with `sonar.cpd.${language}.minimumLines`). For Java projects, a piece of code is considered duplicated when there is a series of at least 10 statements in a row, regardless of the number of tokens and lines. This threshold cannot be overridden. | 100 | |||
| `sonar.cpd.${language}.minimumLines` | (see above) | 10 | |||
| ### Analysis Logging | |||
| Key | Description | Default | |||
| ---|----|--- | |||
| `sonar.log.level` | Control the quantity / level of logs produced during an analysis. `DEBUG`: Display `INFO` logs + more details at `DEBUG` level. Similar to `sonar.verbose=true`. `TRACE`: Display `DEBUG` logs + the timings of all ElasticSearch queries and Web API calls executed by the SonarQube Scanner. | `INFO` | |||
| `sonar.verbose` | Add more detail to both client and server-side analysis logs. Activates `DEBUG` mode for the scanner, and adds client-side environment variables and system properties to server-side log of analysis report processing. NOTE: There is the potential for this setting to expose sensitive information such as passwords if they are stored as server-side environment variables. | false | |||
| `sonar.showProfiling` | Display logs to see where the analyzer spends time. This parameter generates a file containing these timing infos in `<workingDir>/profiling/<moduleKey>-profiler.xml` where `<workingDir>` is: `.sonar/profiling/` when analysis is run with SonarQube Scanner, and `target/sonar/profiling/` when SonarQube Scanner for Maven is used. | `false` | |||
| `sonar.scanner.dumpToFile` | Outputs to the specified file the full list of properties passed to the scanner API as a means to debug analysis. | | |||
| `sonar.scanner.metadataFilePath` | Set the location where the scanner writes the `report-task.txt` file containing among other things the `ceTaskId`. | value of `sonar.working.directory` | |||
| <!-- sonarqube --> | |||
| ### Deprecated | |||
| [[danger]] | |||
| |  These parameters are listed for completeness, but are deprecated and should not be used in new analyses. | |||
| Key | Description | |||
| ---|----|--- | |||
| `sonar.branch` **Deprecated since SQ 6.7** | _The Developer Edition provides fuller-featured branch functionality._ Manage SCM branches. Two branches of the same project are considered to be different projects in SonarQube. As a consequence issues found in a project A in a branch B1 are not linked to issues found for this project A in a branch B2. There is no way to automatically resolve issues from B2 when they are resolved in B1 as again A-B1 & A-B2 are considered separated projects. | |||
| `sonar.language` **Deprecated since SQ 4.5** | Set the language of the source code to analyze. Browse the Plugin Library page to get the list of all available languages. If not set, a multi-language analysis will be triggered. | |||
| `sonar.profile` **Deprecated since SQ 4.5** | Override the profile to be used. This should be set on a per-langauge basis through the UI instead. | |||
| `sonar.analysis.mode` **Deprecated since SQ 6.6** | This parameter is set to `preview` as part of non-Developer Edition PR decoration. | |||
| <!-- /sonarqube --> | |||
+ 0
- 39
server/sonar-docs/src/pages/architecture/architecture-integration.md
View File
| @@ -1,39 +0,0 @@ | |||
| --- | |||
| title: Architecture and Integration | |||
| url: /architecture/architecture-integration/ | |||
| --- | |||
| The SonarQube Platform is made of 4 components: | |||
| 1. One SonarQube Server starting 3 main processes: | |||
| a. Web Server for developers, managers to browse quality snapshots and configure the SonarQube instance | |||
| b. Search Server based on Elasticsearch to back searches from the UI | |||
| c. Compute Engine Server in charge of processing code analysis reports and saving them in the SonarQube Database | |||
| 2. One SonarQube Database to store: | |||
| * the configuration of the SonarQube instance (security, plugins settings, etc.) | |||
| * the quality snapshots of projects, views, etc. | |||
| 3. Multiple SonarQube Plugins installed on the server, possibly including language, SCM, integration, authentication, and governance plugins | |||
| 4. One or more SonarQube Scanners running on your Build / Continuous Integration Servers to analyze projects | |||
|  | |||
| ## Integration | |||
| The following schema shows how SonarQube integrates with other ALM tools and where the various components of SonarQube are used. | |||
| 1. Developers code in their IDEs and use SonarLint to run local analysis. | |||
| 2. Developers push their code into their favourite SCM : git, SVN, TFVC, ... | |||
| 3. The Continuous Integration Server triggers an automatic build, and the execution of the SonarQube Scanner required to run the SonarQube analysis. | |||
| 4. The analysis report is sent to the SonarQube Server for processing. | |||
| 5. SonarQube Server processes and stores the analysis report results in the SonarQube Database, and displays the results in the UI. | |||
| 6. Developers review, comment, challenge their Issues to manage and reduce their Technical Debt through the SonarQube UI. | |||
| 7. Managers receive Reports from the analysis. | |||
| Ops use APIs to automate configuration and extract data from SonarQube. | |||
| Ops use JMX to monitor SonarQube Server. | |||
|  | |||
| ## About Machines and Locations | |||
| * The SonarQube Platform cannot have more than one SonarQube Server and one SonarQube Database. | |||
| * For optimal performance, each component (server, database, scanners) should be installed on a separate machine, and the server machine should be dedicated. | |||
| * SonarQube Scanners scale by adding machines. | |||
| * All machines must be time synchronized. | |||
| * The SonarQube Server and the SonarQube Database must be located in the same network | |||
| * SonarQube Scanners don't need to be on the same network as the SonarQube Server. | |||
| * There is **no communication** between **SonarQube Scanners** and the **SonarQube Database**. | |||
+ 0
- 51
server/sonar-docs/src/pages/instance-administration/configuring-portfolios-and-applications.md
View File
| @@ -1,51 +0,0 @@ | |||
| --- | |||
| title: Configuring Portfolios and Applications | |||
| url: /instance-administration/configuring-portfolios-and-applications/ | |||
| --- | |||
| *Portfolios and Applications are available as part of the [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html).* | |||
| * **UI Path** : **Administration > Configuration > Portfolios** | |||
| * **Permission** : you must have the Global Permission "Administer System" to access this page | |||
| The Portfolios management interface allows you to configure both Portfolios and Applications. It is divided into two or three columns. On the left is the list of top-level Portfolios and Applications. If a Portfolio is chosen, two more columns will be shown: sub-Portfolios, and projects. If an Application is chosen, only the projects column will be available. | |||
| From here, you can edit or delete an existing Portfolio or Application, or create a new one. | |||
| ### Creating | |||
| Use the “Create” button at the top-left of the interface to open the creation dialog. You’re required to provide a name. You can optionally specify a description and key. Visibility defaults to Public, but Private may be chosen. Private Portfolios and Applications are only visible to those explicitly granted the right. | |||
| ### Populating Portfolios | |||
| Once your Portfolio exists, you can populate it with any mix of projects, Applications, and sub-portfolios. Applications may only be populated with projects. | |||
| ### Adding a Sub-portfolio | |||
| To add a sub-portfolio, click on “Add Portfolio” at the top of the third column, and choose: | |||
| * **Standard** - This option allows you to create a new sub-Portfolio from scratch. Once created, you can add projects, applications, and more layers of sub-portfolios. | |||
| * **Local Reference** - This option allows you to reference an existing Portfolio/Application as a sub-portfolio. Once added, it is not editable here, but must be chosen in the left-most column to be edited. | |||
| ### Adding Projects to a Portfolio | |||
| To add projects directly to a Portfolio or standard sub-Portfolio, first select the Portfolio in the left column, and the sub-Portfolio (if necessary) in the middle column. | |||
| There are four project selection modes: | |||
| * **Manual** – choose the projects individually. | |||
| * **Tags** - select one or more project tags. Projects with those tags will automatically be included. | |||
| * **Regular Expression** – specify a regular expression and projects with a matching name OR key will be included. | |||
| * **All Remaining Projects** – choose this option to add all projects not already included in this Portfolio (directly or via sub-Portfolio). | |||
| [[info]] | |||
| |**Project unicity under a portfolio**<br/><br/> | |||
| |Projects, applications and sub-portfolios can only appear once in any given hierarchy in order to avoid magnifying their impacts on aggregated ratings. The portfolio configuration interface has some logic to prevent obvious duplications (e.g. manually adding the same project), however in case of more subtle duplications (e.g. due to regex, or other bulk definition), then the calculation of that portfolio will fail with a helpful error message. | |||
| ### Populating Applications | |||
| Once your application exists, you can populate it with manually-selected projects. By default, the configuration interface shows the list of projects currently selected for the application. To add additional projects, choose the "Unselected" or "All" filter. | |||
| ### Creating branches | |||
| Once your application is populated with projects, you can create application branches by choosing long-lived branches from the application's component projects. This option is available in the Application's **Administration > Edit Definition** interface, or from the global administration interface. | |||
| ### After Computation | |||
| When you launch the Computation, the real work is done on {instance} server side. | |||
| For each Portfolio, a “Background Task” is created and you can follow the progress on each in the **Administration > Projects > Background Tasks** by looking at the logs available for each Portfolio. | |||
+ 0
- 167
server/sonar-docs/src/pages/instance-administration/delegated-auth.md
View File
| @@ -1,167 +0,0 @@ | |||
| --- | |||
| title: Delegating Authentication | |||
| url: /instance-administration/delegated-auth/ | |||
| --- | |||
| ## Table of Contents | |||
| SonarQube comes with an onboard user database, as well as the ability to delegate authentication via HTTP Headers, or LDAP. | |||
| ## HTTP Header Authentication | |||
| This feature is designed to delegate user authentication to third-party systems (proxies/servers). | |||
| When this feature is activated, SonarQube expects that the authentication is handled prior any query reaching the server. | |||
| The tool that handles the authentication should: | |||
| * intercept calls to the SonarQube server | |||
| * take care of the authentication | |||
| * update the HTTP request header with the relevant SonarQube user information | |||
| * re-route the request to SonarQube with the appropriate header information | |||
|  | |||
| All the parameters required to activate and configure this feature are available in SonarQube server configuration file (in _$SONARQUBE_HOME/conf/sonar.properties_). | |||
| Using Http header authentication is an easy way integrate your SonarQube deployment with an in-house SSO implementation. | |||
| ## LDAP Authentication | |||
| You can configure SonarQube authentication and authorization to an LDAP server (including LDAP Service of Active Directory) by configuring the correct values in your _$SONARQUBE_HOME/conf/sonar.properties_ file. | |||
| The main features are: | |||
| * Password checking against the external authentication engine. | |||
| * Automatic synchronization of usernames and emails. | |||
| * Automatic synchronization of relationships between users and groups (authorization). | |||
| * Ability to authenticate against both the external and the internal authentication systems. There is an automatic fallback on SonarQube internal system if the LDAP server is down. | |||
| * During the first authentication trial, if the user's password is correct, the SonarQube database is automatically populated with the new user. Each time a user logs into SonarQube, the username, the email and the groups this user belongs to that are refreshed in the SonarQube database. You can choose to have group membership synchronized as well, but this is not the default. | |||
| | Apache DS | OpenLDAP | Open DS | Active Directory | |||
| ----|-----------|----------|---------|----------------- | |||
| Anonymous |  | | | | |||
| Simple|||| | |||
| LDAPS||| | | |||
| DIGEST-MD5|| || | |||
| CRAM-MD5|| || | |||
| GSSAPI|| | | | |||
|  = successfully tested | |||
| ### Setup | |||
| 1. Configure the LDAP plugin by editing the _$SONARQUBE_HOME/conf/sonar.properties_ file (see table below) | |||
| 2. Restart the SonarQube server and check the log file for: | |||
| ``` | |||
| INFO org.sonar.INFO Security realm: LDAP ... | |||
| INFO o.s.p.l.LdapContextFactory Test LDAP connection: OK | |||
| ``` | |||
| 1. Log into SonarQube | |||
| 1. On logout users will be presented a login page (_/sessions/login_), where they can choose to login as technical user or a domain user by passing appropriate credentials | |||
| From SonarQube Scanners, we recommend using [local technical users](/instance-administration/security/) for authentication against SonarQube Server. | |||
| **General Configuration** | |||
| Property|Description|Default value|Required|Example | |||
| ---|---|---|---|--- | |||
| `sonar.security.realm`|Set this to `LDAP` authenticate first against the external sytem. If the external system is not reachable or if the user is not defined in the external system, authentication will be performed against SonarQube's internal database.| none |Yes|`LDAP` (only possible value) | |||
| `sonar.authenticator.downcase`|Set to true when connecting to a LDAP server using a case-insensitive setup.|`false`|No | |||
| `ldap.url`|URL of the LDAP server. If you are using ldaps, you should install the server certificate into the Java truststore.| none |Yes|`ldap://localhost:10389` | |||
| `ldap.bindDn`|The username of an LDAP user to connect (or bind) with. Leave this blank for anonymous access to the LDAP directory.|none|No|`cn=sonar,ou=users,o=mycompany` | |||
| `ldap.bindPassword`|The password of the user to connect with. Leave this blank for anonymous access to the LDAP directory.|none|No|`secret` | |||
| `ldap.authentication`|Possible values: `simple`, `CRAM-MD5`, `DIGEST-MD5`, `GSSAPI`. See [the tutorial on authentication mechanisms](http://java.sun.com/products/jndi/tutorial/ldap/security/auth.html)|`simple`|No | |||
| `ldap.realm`|See [Digest-MD5 Authentication](http://java.sun.com/products/jndi/tutorial/ldap/security/digest.html), [CRAM-MD5 Authentication](http://java.sun.com/products/jndi/tutorial/ldap/security/crammd5.html)| none|No|example.org | |||
| `ldap.contextFactoryClass`|Context factory class.|`com.sun.jndi.ldap.LdapCtxFactory`|No | |||
| `ldap.StartTLS`|Enable use of `StartTLS`|`false`|No | |||
| `ldap.followReferrals`|Follow referrals or not. See [Referrals in the JNDI](http://docs.oracle.com/javase/jndi/tutorial/ldap/referral/jndi.html)|`true` | |||
| **User Mapping** | |||
| Property|Description|Default value|Required|Example for Active Directory | |||
| ---|---|---|---|--- | |||
| `ldap.user.baseDn`|Distinguished Name (DN) of the root node in LDAP from which to search for users.|None|Yes|`cn=users,dc=example,dc=org` | |||
| `ldap.user.request`|LDAP user request.|`(&(objectClass=inetOrgPerson)(uid={login}))`|No|`(&(objectClass=user)(sAMAccountName={login}))` | |||
| `ldap.user.realNameAttribute`|Attribute in LDAP defining the user’s real name.|`cn`|No| | |||
| `ldap.user.emailAttribute`|Attribute in LDAP defining the user’s email.|`mail`|No| | |||
| **Group Mapping** | |||
| Only [groups](http://identitycontrol.blogspot.fr/2007/07/static-vs-dynamic-ldap-groups.html) are supported (not [roles](http://identitycontrol.blogspot.fr/2007/07/static-vs-dynamic-ldap-groups.html)). Only [static groups](http://identitycontrol.blogspot.fr/2007/07/static-vs-dynamic-ldap-groups.html) are supported (not [dynamic groups](http://identitycontrol.blogspot.fr/2007/07/static-vs-dynamic-ldap-groups.html)). | |||
| [[warning]] | |||
| |When group mapping is configured (i.e the below `ldap.group.*` properties are configured), membership in LDAP server will override any membership locally configured in SonarQube. LDAP server becomes the one and only place to manage group membership (and the info is fetched each time the user logs in). | |||
| For the delegation of authorization, [groups must be first defined in SonarQube](/instance-administration/security/). Then, the following properties must be defined to allow SonarQube to automatically synchronize the relationships between users and groups. | |||
| Property|Description|Default value|Required|Example for Active Directory | |||
| ---|---|---|---|--- | |||
| `ldap.group.baseDn`|Distinguished Name (DN) of the root node in LDAP from which to search for groups.|none|No|`cn=groups,dc=example,dc=org` | |||
| `ldap.group.request`|LDAP group request.|`(&(objectClass=groupOfUniqueNames)(uniqueMember={dn}))`|No|`(&(objectClass=group)(member={dn}))` | |||
| `ldap.group.idAttribute`|Property used to specifiy the attribute to be used for returning the list of user groups in the compatibility mode.|`cn`|No|`sAMAccountName` | |||
| ### Sample Configuration | |||
| ``` | |||
| # LDAP configuration | |||
| # General Configuration | |||
| sonar.security.realm=LDAP | |||
| ldap.url=ldap://myserver.mycompany.com | |||
| ldap.bindDn=my_bind_dn | |||
| ldap.bindPassword=my_bind_password | |||
| # User Configuration | |||
| ldap.user.baseDn=ou=Users,dc=mycompany,dc=com | |||
| ldap.user.request=(&(objectClass=inetOrgPerson)(uid={login})) | |||
| ldap.user.realNameAttribute=cn | |||
| ldap.user.emailAttribute=mail | |||
| # Group Configuration | |||
| ldap.group.baseDn=ou=Groups,dc=sonarsource,dc=com | |||
| ldap.group.request=(&(objectClass=posixGroup)(memberUid={uid})) | |||
| ``` | |||
| ## Advanced LDAP Topics | |||
| ### Authentication Methods | |||
| * **`Anonymous`** - Used when only read-only access to non-protected entries and attributes is needed when binding to the LDAP server. | |||
| * **`Simple`** Simple authentication is not recommended for production deployments not using the ldaps secure protocol since it sends a cleartext password over the network. | |||
| * **`CRAM-MD5`** - The Challenge-Response Authentication Method (CRAM) based on the HMAC-MD5 MAC algorithm ([RFC 2195](http://tools.ietf.org/html/rfc2195)). | |||
| * **`DIGEST-MD5`** - This is an improvement on the CRAM-MD5 authentication method ([RFC 2831](http://www.ietf.org/rfc/rfc2831.txt)). | |||
| * **`GSSAPI`** - GSS-API is Generic Security Service API ([RFC 2744](http://www.ietf.org/rfc/rfc2744.txt)). One of the most popular security services available for GSS-API is the Kerberos v5, used in Microsoft's Windows 2000 platform. | |||
| For a full discussion of LDAP authentication approaches, see [RFC 2829](http://www.ietf.org/rfc/rfc2829.txt) and [RFC 2251](http://www.ietf.org/rfc/rfc2251.txt). | |||
| ### Multiple Servers | |||
| To configure multiple servers: | |||
| ``` | |||
| # List the different servers | |||
| ldap.servers=server1,server2 | |||
| # Configure server1 | |||
| ldap.server1.url=ldap://server1:1389 | |||
| ldap.server1.user.baseDn=dc=dept1,dc=com | |||
| ... | |||
| # Configure server2 | |||
| ldap.server2.url=ldap://server2:1389 | |||
| ldap.server2.user.baseDn=dc=dept2,dc=com | |||
| ... | |||
| ``` | |||
| Authentication will be tried on each server, in the order they are listed in the configurations, until one succeeds. User/Group mapping will be performed against the first server on which the user is found. | |||
| Note that all the LDAP servers must be available while (re)starting the SonarQube server. | |||
| ### Troubleshooting | |||
| * Detailed connection logs (and potential error codes received from LDAP server) are output to SonarQube's _$SONARQUBE_HOME/logs/web.log_, when logging is in `DEBUG` mode. | |||
| * Time out when running SonarQube analysis using LDAP | |||
| Java parameters are documented here: http://docs.oracle.com/javase/jndi/tutorial/ldap/connect/config.html. Such parameters can be set in `sonar.web.javaAdditionalOpts` in _$SONARQUBE_HOME/conf/sonar.properties_. | |||
| * Kerberos Troubleshooting resources | |||
| * [Enabling Kerberos Logging](http://support.microsoft.com/kb/262177/en-us) | |||
| * [Troubleshooting Kerberos Delegation](https://gallery.technet.microsoft.com/Troubleshooting-Kerberos-72837743) | |||
| * Troubleshooting NTLM | |||
| * [Enabling NTLM Logging](http://blogs.technet.com/b/askds/archive/2009/10/08/ntlm-blocking-and-you-application-analysis-and-auditing-methodologies-in-windows-7.aspx) | |||
| ## Authenticating Via Other Systems | |||
| Additionally, several plugins are available to allow delegation to other providers: | |||
| * Crowd - [SonarQube Crowd Plugin](https://github.com/SonarCommunity/sonar-crowd) | |||
| * GitHub - [GitHub Authentication Plugin](https://redirect.sonarsource.com/plugins/authgithub.html) | |||
| * Bitbucket - [Bitbucket Authentication Plugin](https://github.com/SonarQubeCommunity/sonar-auth-bitbucket) | |||
+ 0
- 27
server/sonar-docs/src/pages/instance-administration/git-integration.md
View File
| @@ -1,27 +0,0 @@ | |||
| --- | |||
| title: Git Integration | |||
| url: /instance-administration/git-integration/ | |||
| --- | |||
| [Git](http://www.git-scm.com/) integration is supported out of the box with a pure Java implementation so there's no need to have Git command line tool installed on the machine where analysis is performed. | |||
| Auto-detection of Git during analysis will happen if there is a .git folder in the project root directory or in one of its parent folders. Otherwise you can force the provider using `-Dsonar.scm.provider=git`. A full clone is required for this integration to be able to collect the required blame information (see Known Issues). If a shallow clone is detected, a warning will be logged and no attempt will be made to retrieve blame information.. | |||
| ### Known Issues | |||
| * Git doesn't consider old "Mac" line ends (CR) as new lines. As a result the blame operation will contain fewer lines than expected by SonarQube and analysis will fail. The solution is to fix line ends to use either Windows (CR/LF) or Unix (LF) line ends. | |||
| * JGit doesn't support .mailmap file to "clean" email adress during the blame | |||
| ### Advanced information | |||
| The plugin uses [JGit](https://www.eclipse.org/jgit/) 4.9.0. JGit is a pure Java implementation of Git client. | |||
| ### How to investigate error during blame (only possible on Unix/Linux)? | |||
| If you get an error when blame is executed on a file, it may be a limitation or a bug in JGit. To confirm please follow these steps: | |||
| 1. Download the standalone JGit command line distribution | |||
| 2. Try to execute the blame command on the offending file: | |||
| `chmod +x /path/to/org.eclipse.jgit.pgm-4.9.0.201710071750-r.sh /path/to/org.eclipse.jgit.pgm-4.9.0.201710071750-r.sh blame -w /path/to/offending/file` | |||
| 3. If you get the same error as during analysis, then this really looks like a bug in JGit (especially if you don't have an issue with the native git command line tool). Please try to do previous steps with latest version of JGit and report all information to the [SonarQube Community Forum](https://community.sonarsource.com/). | |||
+ 0
- 48
server/sonar-docs/src/pages/instance-administration/project-move.md
View File
| @@ -1,48 +0,0 @@ | |||
| --- | |||
| title: Project Move | |||
| url: /instance-administration/project-move/ | |||
| --- | |||
| _Project Move is available as part of [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html)_ | |||
| ## Table of Contents | |||
| Project Move allows you to export a project from one SonarQube instance and import it into another, identically configured SonarQube instance. To use Project Move, you must have the Administer permission on the project in the source instance, and access to the file systems of both instances. | |||
| ## When to Use "Project Move" | |||
| In the following cases: | |||
| * you want to create a central SonarQube instance at enterprise level and you want to keep the history created on N instances used previously at the team level | |||
| * your company is acquiring another company that already has a central SonarQube instance | |||
| * an application is transferred from one team to another in a large company and that company has several SonarQube instances | |||
| ## Prerequisites | |||
| In order to be able to export and then load your Project's data, the two SonarQube instances must have: | |||
| * the exact same version | |||
| * the same plugins with the same versions | |||
| * the same custom metrics | |||
| * the same custom rules | |||
| ## How To Export | |||
| On the source instance: | |||
| * reanalyze the project one last time to make sure it is populated with data corresponding to your current SonarQube installation | |||
| * navigate to the project and at the project level, choose **Administration > Import / Export** | |||
| * click on the **Export** button to generate a zip file containing the settings and history of your Project (but not the source code). Note that if you need to change the Project's key, you must to do it before performing the export. | |||
| A zip file containing all project data ex is generated in _$SONAR_SOURCE_HOME/data/governance/project_dumps/export/_ named _<project_key>.zip_ | |||
| ## How To Import | |||
| On the target instance: | |||
| * With a user having the "Administer System" and "Create Projects" permissions, go to **[Administration > Projects > Management](/#sonarqube-admin#/admin/projects_management/)** and [provision the project](/project-administration/project-existence/) using the same key the project had in the source instance. | |||
| * Configure the Project's permissions, and the Quality Profiles and Quality Gate associated to the Project | |||
| * Put the generated zip file into the directory _$SONAR_TARGET_HOME/data/governance/project_dumps/import_ | |||
| * Go to the Project's Home Page and choose **Administration > Import / Export** | |||
| * Click on the Import button to start importing your data | |||
| ** Source code is not included in the zip file. Once the import is finished, trigger an analysis to import source files into the new instance. | |||
| Notes: | |||
| * If the import is successful, the zip file will automatically be deleted. | |||
| * It is not possible to import a Project that has been already analyzed on the target instance. | |||
+ 0
- 151
server/sonar-docs/src/pages/instance-administration/security.md
View File
| @@ -1,151 +0,0 @@ | |||
| --- | |||
| title: Security | |||
| url: /instance-administration/security/ | |||
| --- | |||
| ## Table of Contents | |||
| ## Overview | |||
| SonarQube comes with a number of global security features: | |||
| * on-board authentication and authorization mechanisms | |||
| * the ability to force users to authenticate before they can see any part of a SonarQube instance | |||
| * the ability to delegate to authentication (for more see [Delegating Authentication](/instance-administration/delegated-auth/)) | |||
| Additionally, you can configure at a group or user level who can: | |||
| * see that a project even exists | |||
| * access a project's source code | |||
| * administer a project (set exclusion patterns, tune plugin configuration for that project, etc.) | |||
| * administer Quality Profiles, Quality Gates, and the SonarQube instance itself. | |||
| Another aspect of security is the encryption of settings such as passwords. SonarQube provides a built-in mechanism to encrypt settings. | |||
| ## Authentication | |||
| The first question that should be answered when setting the security strategy for SonarQube is: Can anonymous users browse the SonarQube instance or is authentication be required? | |||
| To force user authentication, log in as a system administrator, go to **[Administration > Configuration > General Settings > Security](/#sonarqube-admin#/admin/settings?category=security)**, and set the **Force user authentication** property to true. | |||
| ### Authentication Mechanisms | |||
| Authentication can be managed through a number of mechanisms: | |||
| * Via the SonarQube built-in users/groups database | |||
| * Via external identity providers such as an LDAP server (including LDAP Service of Active Directory), GitHub etc. See the Authentication & Authorization section of the Plugin Library. | |||
| * Via HTTP headers | |||
| ### Technical Users | |||
| When you create a user in SonarQube's own database, it is considered local and will only be authenticated against SonarQube's own user/group database rather than against any external tool (LDAP, Active Directory, Crowd, etc.). By default `admin` is a local account. | |||
| Similarly, all non-local accounts will be authenticated only against the external tool. | |||
| An Administrator can manage tokens on a user's behalf via **[Administration > Security > Users](/#sonarqube-admin#/admin/users)**. From here, click in the user's **Tokens** column to see the user's existing tokens, and either revoke existing tokens or generate new ones. Once established, a token is the only credential needed to run an analysis. Tokens should be passed as the value of the `sonar.login` property. | |||
| ### Default Admin Credentials | |||
| When installing SonarQube, a default user with Administer System permission is created automatically: | |||
| * Login: admin | |||
| * Password: admin | |||
| ## Reinstating Admin Access | |||
| If you changed and then lost the `admin` password, you can reset it using the following query: | |||
| ``` | |||
| update users set crypted_password = '$2a$12$uCkkXmhW5ThVK8mpBvnXOOJRLd64LJeHTeCkSuB3lfaR2N0AYBaSi', salt=null, hash_method='BCRYPT' where login = 'admin' | |||
| ``` | |||
| If you've deleted `admin` and subsequently locked out the other users with global administrative permissions, you'll need to re-grant `admin` to a user with the following query: | |||
| ``` | |||
| INSERT INTO user_roles(user_id, role) VALUES ((select id from users where login='mylogin'), 'admin'); | |||
| ``` | |||
| ## Authorization | |||
| The way authorization is implemented in SonarQube is pretty standard. It is possible to create as many users and groups of users as needed. The users can then be attached (or not) to (multiple) groups. Groups and / or users are then given (multiple) permissions. The permissions grant access to projects, services and functionalities. | |||
| To administer groups and users, choose **Administration > Security**, and use the sub-menu items. | |||
| ### User | |||
| Multiple integrations that allow the delegation of authentication are available (see the [Plugin Library](https://redirect.sonarsource.com/doc/plugin-library.html) and [Other Plugins](https://docs.sonarqube.org/display/PLUG/Other+Plugins), but you can manually create and edit users at **[Settings > Security > Users](/#sonarqube-admin#/admin/users)**. For manually-created users, login and password can be set at creation. Manually-created users can edit their passwords. | |||
| During both user creation and edit, you can set an account's screen name, email address. User login and email address will be implicitly recognized by the Issue Assignment feature as SCM accounts if applicable, but you can set additional SCM accounts explicitly. | |||
| ### Group | |||
| A group is a set of users. | |||
| To administer groups, go to **[Administration > Security > Groups](/#sonarqube-admin#/admin/groups)**. | |||
| To edit the membership of a group, click the icon next to the membership total. | |||
| Two groups have a special meaning: | |||
| * **Anyone** is a group that exists in the system, but that cannot be managed. Every user belongs to this group, including Anonymous user. | |||
| * **sonar-users** is the default group to which users are automatically added. | |||
| ### Global Permissions | |||
| To set global permissions, log in as a System administrator and go to **[Administration > Security > Global Permissions](/#sonarqube-admin#/admin/permissions)**. | |||
| * **Administer System**: All administration functions for the instance: global configuration. | |||
| * **Administer Quality Profiles**: Any action on quality profiles. | |||
| * **Administer Quality Gates**: Any action on quality gates | |||
| * **Execute Analysis**: Execute analyses (project, view, report, developer), and to get all settings required to perform the analysis, even the secured ones like the scm account password, and so on. | |||
| * **Create Projects**: Initialize the structure of a new project before its first analysis. This permission is also required when doing the very first analysis of a project that has not already been created via the GUI. | |||
| * **Create Applications**: Create a new Application. | |||
| * **Create Portfolios**: Create a new Portfolio. | |||
| ### Project Permissions | |||
| Project permissions are available from the project-level Administration menu: **Administration > Permissions**. | |||
| Project visibility may be toggled between public or private. Making a project private hides its source code and measures from the `Anyone` group. For both public and private projects, four different permissions can be set: | |||
| * **Administer Issues**: Change the type and severity of issues, resolve issues as being "Won't Fix" or "False Positive" (users also need "Browse" permission). | |||
| * **Administer Security Hotspots**: "Detect" (convert) a Vulnerability from a "Security Hotspot", reject, clear, accept or reopen a "Security Hotspot" (users also need "Browse" permission). | |||
| * **Administer**: Access project settings and perform administration tasks (users also need "Browse" permission). | |||
| * **Execute Analysis**: Execute analyses (project, view, report, developer), and to get all settings required to perform the analysis, even the secured ones like the scm account password, the jira account password, and so on. | |||
| Private projects have two additional permissions: | |||
| * **Browse**: Access a project, browse its measures, issues and perform some issue edits (confirm/resolve/reopen, assignment, comment). | |||
| * **See Source Code**: View the project's source code. | |||
| Note that permissions _are not_ cumulative. For instance, if you want to be able to administer the project, you also have to be granted the Browse permission to be able to access the project (which is the default for Public project). | |||
| You can either manually grant permissions for each project to some users and groups or apply permission templates to projects. | |||
| ## Permission Templates for Default Permissions | |||
| SonarQube ships with a default permissions template, which automatically grants specific permissions to certain groups when a project, portfolio, or application is created. It is possible to edit this template, and to create additional templates. A separate template can be set for each type of resource. Further, for projects you can have a template apply only to a subset of new projects using a project key regular expression (the template's **Project Key Pattern**). By default, every new project with a key that matches the supplied pattern will have template's permissions applied. | |||
| Templates are empty immediately after creation. Clicking on the template name will take you to its permission editing interface. | |||
| Templates are administered through **[Administration > Security > Permission Templates](/#sonarqube-admin#/admin/permission_templates)**. | |||
| ### Creators permissions | |||
| **Creators** is a special group that appears only in the permission template editing interface. Any permissions assigned to this group will at the time of project/portfolio/application creation be granted to the single user account used to create the project. This allows SonarQube administrators to let users autonomously create and administer their own projects. | |||
| While templates can be applied after project creation, applying a template that includes "Creators" permissions to an existing project/portfolio/application will not grant the relevant permissions to the project's original creator because that association is not stored. | |||
| ### Reset project permissions to a template | |||
| To apply permission templates to projects go to **[Administration > Projects > Management](/#sonarqube-admin#/admin/projects_management)**. You can either apply a template to a specific project using the project-specific **Actions > Apply Permission Template** option or use the Bulk Apply Permission Template to apply a template to all selected projects. | |||
| Note that there is no relation between a project and a permission template, meaning that: | |||
| * the permissions of a project can be modified after a permission template has been applied to this project | |||
| * none of the project permissions is changed when a permission template is modified | |||
| ## Settings Encryption | |||
| Encryption is mostly used to remove clear passwords from settings (database or SCM credentials for instance). The implemented solution is based on a symetric key algorithm. The key point is that the secret key is stored in a secured file on disk. This file must owned by and readable only by the system account that runs the SonarQube server. | |||
| The algorithm is AES 128 bits. Note that 256 bits cipher is not used because it's not supported by default on all Java Virtual Machines ([see this article](https://confluence.terena.org/display/~visser/No+256+bit+ciphers+for+Java+apps)). | |||
| 1. **Generate the secret key** | |||
| A unique secret key must be shared between all parts of the SonarQube infrastructure (server and analyzers). To generate it, go to **[Administration > Configuration > Encryption](/#sonarqube-admin#/admin/settings/encryption)** and click on Generate Secret Key. | |||
| 1. **Store the secret key on the SonarQube server** | |||
| * Copy the generated secred key to a file on the machine hosting the SonarQube server. The default location is _~/.sonar/sonar-secret.txt_. If you want to store it somewhere else, set its path through the `sonar.secretKeyPath` property in _$SONARQUBE_HOME/conf/sonar.properties_ | |||
| * Restrict file permissions to the account running the SonarQube server (ownership and read-access only). | |||
| * Restart your SonarQube server | |||
| 1. **Generate the encrypted values of your settings** | |||
| Go back to **[Administration > Configuration > Encryption](/#sonarqube-admin#/admin/settings/encryption)** and use the form that has been added to the interface to generated encrypted versions of your values. | |||
|  | |||
| 1. **Use the encrypted values in your SonarQube server configuration** | |||
| Simply copy these encrypted values into `$SONARQUBE_HOME/conf/sonar.properties` | |||
| ``` | |||
| sonar.jdbc.password={aes}CCGCFg4Xpm6r+PiJb1Swfg== # Encrypted DB password | |||
| ... | |||
| sonar.secretKeyPath=C:/path/to/my/secure/location/my_secret_key.txt | |||
| ``` | |||
+ 0
- 394
server/sonar-docs/src/pages/instance-administration/system-info.md
View File
| @@ -1,394 +0,0 @@ | |||
| --- | |||
| title: Server Logs & System Info | |||
| url: /instance-administration/system-info/ | |||
| --- | |||
| ## Table of Contents | |||
| The System Info page is found at **[Administration > System](/#sonarqube-admin#/admin/system)**. It gives you access to detailed information on the state of your SonarQube instance. | |||
| ## System Info | |||
| You can browse details about your running instance on this page. Additionally, if you have a Support contract, you might be asked by a Support representative to send in your System Info, which can be downloaded from this page using the eponymously named button at the top. | |||
| ### Server Id | |||
| Your server id can be obtained from this page by expanding the **System** section. If you're running a commercial instance, you can also find this value on the License page (**[Administration > Configuration > License Manager](/#sonarqube-admin#/admin/extension/license/app)** | |||
| ## Logs | |||
| Server-side logging is controlled by properties set in _$SONARQUBE_HOME/conf/sonar.properties_. | |||
| 4 logs files are created: one per SonarQube process. | |||
| ### Log Level | |||
| The server-side log level can be customized via the `sonar.log.level` property. Supported values are: | |||
| * **`INFO`** - the default | |||
| * **`DEBUG`** - for advanced logs. | |||
| * **`TRACE`** - show advanced logs and all SQL and Elasticsearch requests. `TRACE` level logging slows down the server environment, and should be used only for tracking web request performance problems. | |||
| ### Log Level by Process | |||
| The server-side log level can be adjusted more precisely for the 4 processes of SonarQube Server via the following property: | |||
| * **`sonar.log.level.app`** - for the Main process of SonarQube (aka WrapperSimpleApp, the bootstrapper process starting the 3 others) | |||
| * **`sonar.log.level.web`** - for the WebServer | |||
| * **`sonar.log.level.ce`** - for the ComputeEngineServer | |||
| * **`sonar.log.level.es`** - for the SearchServer | |||
| ### Log Rotation | |||
| To control log rolling, use the `sonar.log.rollingPolicy` | |||
| * **`time:[value]`** - for time-based rotation. For example, use `time:yyyy-MM-dd` for daily rotation, and * `time:yyyy-MM` for monthly rotation. | |||
| * **`size:[value]`** - for size-based rotation. For example, `size:10MB`. | |||
| * **`none`** - for no rotation. Typically this would be used when logs are handled by an external system like logrotate. | |||
| `sonar.log.maxFiles` is the maximum number of files to keep. This property is ignored if `sonar.log.rollingPolicy=none`. | |||
| ### UI Access to Logs and Log Levels | |||
| The System Info page gives you the ability to download your instance's current log files (log files rotate on a regular basis), and to tune the log level via controls at the top of the page. Changes made here are temporary, and last only until the next time the instance is restarted, at which point the level will be reset to the more permanent value set in _$SONARQUBE_HOME/conf/sonar.properties`. Regardless, if you change your log level _from_ `INFO`, but sure to change it back as soon as is practical; log files can get very large very quickly at lower log levels. | |||
| ## Total Lines of Code | |||
| ### SonarQube 6.7 LTS and newer | |||
| The number of Lines of Code (for licensing purposes) in an instance can be found in the **System** section of the System Info page on, and on the License page (**[Administration > Configuration > License Manager](/#sonarqube-admin#/admin/extension/license/app)** in commercial editions. | |||
| If you're on a commercial edition and using Branch or PR analysis, rest assured that only lines from the single largest branch in a project are considered for licensing purposes. The Lines of Code in the rest of the branches are ignored. | |||
| ### Versions older than 6.7 | |||
| The best approach there is to query the database. The actual query varies based on the version of SonarQube and the database engine. Two queries are provided: | |||
| * one query that counts LOCs across *all* projects | |||
| & one query that filters out project branches (i.e. projects analysed with the `sonar.branch` parameter). However, this query is accurate only if projects with branches are also analysed once without sonar.branch. | |||
| **SonarQube LTS v5.6.x** | |||
| [[collapse]] | |||
| | ## MySQL | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.project_id = p.id | |||
| | inner join project_measures pm on pm.snapshot_id = s.id | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_resource_id is null | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| |``` | |||
| | select sum(pm.value) as loc_without_branch from projects p | |||
| | inner join snapshots s on s.project_id = p.id | |||
| | inner join project_measures pm on pm.snapshot_id = s.id | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_resource_id is null | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc' | |||
| | and ( | |||
| | INSTR(p.kee, ':') = 0 or not exists( | |||
| | select * from projects p_root where p_root.kee = SUBSTR(p.kee, 1, LENGTH(p.kee) - INSTR(REVERSE(p.kee), ':')) | |||
| | )); | |||
| |``` | |||
| [[collapse]] | |||
| | ## PostgreSQL 8.0-9.0 | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.project_id = p.id | |||
| | inner join project_measures pm on pm.snapshot_id = s.id | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_resource_id is null | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| | Not feasible on this specific database | |||
| [[collapse]] | |||
| | ## PostgreSQL 9.1+ | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.project_id = p.id | |||
| | inner join project_measures pm on pm.snapshot_id = s.id | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_resource_id is null | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| | ``` | |||
| | select sum(pm.value) as loc_without_branch from projects p | |||
| | inner join snapshots s on s.project_id = p.id | |||
| | inner join project_measures pm on pm.snapshot_id = s.id | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_resource_id is null | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc' | |||
| | and ( | |||
| | POSITION(':' IN p.kee) = 0 or not exists( | |||
| | select * from projects p_root where p_root.kee = SUBSTRING(p.kee, 0, LENGTH(p.kee) - POSITION(':' in REVERSE(p.kee)) + 1) | |||
| | )); | |||
| | ``` | |||
| [[collapse]] | |||
| | ## Oracle | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.project_id = p.id | |||
| | inner join project_measures pm on pm.snapshot_id = s.id | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = 1 | |||
| | and p.enabled = 1 | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_resource_id is null | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| | ``` | |||
| | select sum(pm.value) as loc_without_branch from projects p | |||
| | inner join snapshots s on s.project_id = p.id | |||
| | inner join project_measures pm on pm.snapshot_id = s.id | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = 1 | |||
| | and p.enabled = 1 | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_resource_id is null | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc' | |||
| | and ( | |||
| | INSTR(p.kee, ':') = 0 or not exists( | |||
| | select * from projects p_root where p_root.kee = SUBSTR(p.kee, 0, INSTR(p.kee, ':', -1) - 1) | |||
| | )); | |||
| | ``` | |||
| [[collapse]] | |||
| | ## Microsoft SQL Server (a.k.a MSSQL) | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.project_id = p.id | |||
| | inner join project_measures pm on pm.snapshot_id = s.id | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = 1 | |||
| | and p.enabled = 1 | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_resource_id is null | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| | ``` | |||
| | select sum(pm.value) as loc_without_branch from projects p | |||
| | inner join snapshots s on s.project_id = p.id | |||
| | inner join project_measures pm on pm.snapshot_id = s.id | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = 1 | |||
| | and p.enabled = 1 | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_resource_id is null | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc' | |||
| | and ( | |||
| | CHARINDEX(':', p.kee) = 0 or not exists( | |||
| | select * from projects p_root where p_root.kee = SUBSTRING(p.kee, 0, LEN(p.kee) - CHARINDEX(':', REVERSE(p.kee)) + 1 ) | |||
| | )); | |||
| | ``` | |||
| **SonarQube 6.0-6.6** | |||
| [[collapse]] | |||
| | ## MySQL | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.component_uuid = p.uuid | |||
| | inner join project_measures pm on pm.analysis_uuid = s.uuid | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_component_uuid is null | |||
| | and pm.component_uuid = p.uuid | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| | ``` | |||
| | select sum(pm.value) as loc_without_branch from projects p | |||
| | inner join snapshots s on s.component_uuid = p.uuid | |||
| | inner join project_measures pm on pm.analysis_uuid = s.uuid | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_component_uuid is null | |||
| | and pm.component_uuid = p.uuid | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc' | |||
| | and ( | |||
| | INSTR(p.kee, ':') = 0 or not exists( | |||
| | select * from projects p_root where p_root.kee = SUBSTR(p.kee, 1, LENGTH(p.kee) - INSTR(REVERSE(p.kee), ':')) | |||
| | )); | |||
| | ``` | |||
| [[collapse]] | |||
| | ## PostgreSQL 8.0-9.0 | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.component_uuid = p.uuid | |||
| | inner join project_measures pm on pm.analysis_uuid = s.uuid | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_component_uuid is null | |||
| | and pm.component_uuid = p.uuid | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| | Not feasible on this specific database | |||
| [[collapse]] | |||
| | ## PostgreSQL 9.1+ | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.component_uuid = p.uuid | |||
| | inner join project_measures pm on pm.analysis_uuid = s.uuid | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_component_uuid is null | |||
| | and pm.component_uuid = p.uuid | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| | ``` | |||
| | select sum(pm.value) as loc_without_branch from projects p | |||
| | inner join snapshots s on s.component_uuid = p.uuid | |||
| | inner join project_measures pm on pm.analysis_uuid = s.uuid | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = true | |||
| | and p.enabled = true | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_component_uuid is null | |||
| | and pm.component_uuid = p.uuid | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc' and ( | |||
| | POSITION(':' IN p.kee) = 0 or not exists( | |||
| | select * from projects p_root where p_root.kee = SUBSTRING(p.kee, 0, LENGTH(p.kee) - POSITION(':' in REVERSE(p.kee)) + 1) | |||
| | )); | |||
| | ``` | |||
| [[collapse]] | |||
| | ## Oracle | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.component_uuid = p.uuid | |||
| | inner join project_measures pm on pm.analysis_uuid = s.uuid | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = 1 | |||
| | and p.enabled = 1 | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_component_uuid is null | |||
| | and pm.component_uuid = p.uuid | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| | ``` | |||
| | select sum(pm.value) as loc_without_branch from projects p | |||
| | inner join snapshots s on s.component_uuid = p.uuid | |||
| | inner join project_measures pm on pm.analysis_uuid = s.uuid | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = 1 | |||
| | and p.enabled = 1 | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_component_uuid is null | |||
| | and pm.component_uuid = p.uuid | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc' | |||
| | and ( | |||
| | INSTR(p.kee, ':') = 0 or not exists( | |||
| | select * from projects p_root where p_root.kee = SUBSTR(p.kee, 0, INSTR(p.kee, ':', -1) - 1) | |||
| | )); | |||
| | ``` | |||
| [[collapse]] | |||
| | ## Microsoft SQL Server (a.k.a. MSSQL) | |||
| | Global LOCs | |||
| | ``` | |||
| | select sum(pm.value) as global_loc from projects p | |||
| | inner join snapshots s on s.component_uuid = p.uuid | |||
| | inner join project_measures pm on pm.analysis_uuid = s.uuid | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = 1 | |||
| | and p.enabled = 1 | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_component_uuid is null | |||
| | and pm.component_uuid = p.uuid | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc'; | |||
| | ``` | |||
| | LOCs without `sonar.branch` | |||
| | ``` | |||
| | select sum(pm.value) as loc_without_branch from projects p | |||
| | inner join snapshots s on s.component_uuid = p.uuid | |||
| | inner join project_measures pm on pm.analysis_uuid = s.uuid | |||
| | inner join metrics m on m.id=pm.metric_id | |||
| | where s.islast = 1 | |||
| | and p.enabled = 1 | |||
| | and p.qualifier = 'TRK' | |||
| | and p.scope = 'PRJ' | |||
| | and p.copy_component_uuid is null | |||
| | and pm.component_uuid = p.uuid | |||
| | and pm.person_id is null | |||
| | and m.name='ncloc' | |||
| | and ( | |||
| | CHARINDEX(':', p.kee) = 0 or not exists( | |||
| | select * from projects p_root where p_root.kee = SUBSTRING(p.kee, 0, LEN(p.kee) - CHARINDEX(':', REVERSE(p.kee)) + 1 ) | |||
| | )); | |||
| | ``` | |||
+ 0
- 13
server/sonar-docs/src/pages/previous-versions.md
View File
| @@ -1,13 +0,0 @@ | |||
| --- | |||
| title: Documentation for Previous Versions | |||
| url: /previous-versions/ | |||
| --- | |||
| **Not using the latest and greatest version of SonarQube?** | |||
| Here are the links to the documentation of previous versions: | |||
| * [Documentation for 7.2](https://docs.sonarqube.org/display/SONARQUBE72) | |||
| * [Documentation for 7.1](https://docs.sonarqube.org/display/SONARqube71) | |||
| * [Documentation for 7.0](https://docs.sonarqube.org/display/SONARQUBE70) | |||
| * [Documentation for 6.7 LTS](https://docs.sonarqube.org/display/SONARQUBE67) | |||
+ 0
- 25
server/sonar-docs/src/pages/project-administration/managing-project-history.md
View File
| @@ -1,25 +0,0 @@ | |||
| --- | |||
| title: Managing Project History | |||
| url: /project-administration/managing-project-history/ | |||
| --- | |||
| One of the most powerful features of {instance} is that it shows you not just your project health today, but how it has changed over time. It does that by selectively keeping data from previous analyses (see [Housekeeping](/instance-administration/housekeeping/)). It doesn't keep all previous analyses - that would bloat the database. Similarly, for the analyses it does keep, {instance} doesn't keep all the data. Once a project snapshot moves from the "Last analysis" (i.e. the most recent) to being part of the project's history, data below the project level is purged - again to keep from bloating the database. | |||
| Typically these aren't things you need to even think about; {instance} just handles them for you. But occasionally you may need to remove a bad snapshot from a project's history or change the housekeeping algorithms. | |||
| ## Managing History | |||
| Occasionally, you may need to manually delete a project snapshot, whether because the wrong quality profile was used, or because there was a problem with analysis, and so on. Note that the most recent snapshot (labeled "Last snapshot") can never be deleted. | |||
| [[warning]] | |||
| |**About deleting snapshots**<br/><br/> | |||
| |Deleting a snapshot is a 2-step process:<br/><br/> | |||
| |* The snapshot must first be removed from the project history by clicking on Delete snapshot. It |won't be displayed anymore on this History page but will still be present in the database. | |||
| |* The snapshot is actually deleted during the next project analysis. | |||
| At project level, from the front page **Activity** list, choose **Show More** to see the full activity list. | |||
| For every snapshot, it is possible to manually: | |||
| * Add, rename or remove a version | |||
| * Add, rename or remove an event | |||
| * Delete the snapshot | |||
+ 0
- 142
server/sonar-docs/src/pages/project-administration/narrowing-the-focus.md
View File
| @@ -1,142 +0,0 @@ | |||
| --- | |||
| title: Narrowing the Focus | |||
| url: /project-administration/narrowing-the-focus/ | |||
| --- | |||
| ## Table of Contents | |||
| If SonarQube's results aren't relevant, developers will push back on using it. That's why precisely configuring what to analyze for each project is a very important step. Doing so allows you to remove noise, like the issues and duplications marked on generated code, or the issues from rules that aren't relevant for certain types of objects. | |||
| SonarQube gives you several options for configuring exactly what will be analyzed. You can | |||
| * completely ignore some files or directories | |||
| * exclude files/directories from Issues detection (specific rules or all of them) but analyze all other aspects | |||
| * exclude files/directories from Duplications detection but analyze all other aspects | |||
| * exclude files/directories from Coverage calculations but analyze all other aspects | |||
| You can make these changes globally or at a project level. At both levels, the navigation path is the same: **Administration > General Settings > Analysis Scope**. | |||
| ## Ignore Files | |||
| We recommend that you exclude generated code, source code from libraries, etc. There are four different ways to narrow your analysis to the source code that will be relevant to the development team. You can combine them all together to tune your analysis scope. | |||
| ### Source Directories | |||
| Set the [sonar.sources](/analysis/analysis-parameters/) property to limit the scope of the analysis to certain directories. | |||
| ### File Suffixes | |||
| Most language plugins offer a way to restrict the scope of analysis to files matching a set of extensions. Go to **Administration > General Settings > [Language]** to set the File suffixes property. | |||
| ### Choosing Files | |||
| To specify which files are are and are not included in an analysis go to **Administration > General Settings > Analysis Scope > Files**. | |||
| Use exclusion to analyze everything but the specified files: | |||
| * sonar.exclusions - to exclude source code files | |||
| * sonar.test.exclusions - to exclude unit test files | |||
| Use inclusion to analyzes only the specified files: | |||
| * sonar.inclusions | |||
| * sonar.test.inclusions | |||
| You can set these properties at the project and global levels. | |||
| See the Patterns section for more details on the syntax to use in these inputs. | |||
| ## Ignore Issues | |||
| You can have SonarQube ignore issues on certain components and against certain coding rules. Go to **Administration > General Settings > Analysis Scope > Issues**. | |||
| Note that the properties below can only be set through the web interface because they are multi-valued. | |||
| ### Ignore Issues on Files | |||
| You can ignore all issues on files that contain a block of code matching a given regular expression. | |||
| Example: | |||
| * *Ignore all issues in files containing "@javax.annotation.Generated"* | |||
| `@javax\.annotation\.Generated` | |||
| ### Ignore Issues in Blocks | |||
| You can ignore all issues on specific blocks of code, while continuing to scan and mark issues on the remainder of the file. Blocks to be ignored are delimited by start and end strings which can be specified by regular expressions (or plain strings). | |||
| Notes: | |||
| * If the first regular expression is found but not the second one, the end of the file is considered to be the end of the block. | |||
| * Regular expressions are not matched on a multi-line basis. | |||
| ### Ignore Issues on Multiple Criteria | |||
| You can ignore issues on certain components and for certain coding rules. To list a specific rule, use the fully qualified rule ID. | |||
| [[info]] | |||
| |  You can find the fully qualified rule ID on the Rule definition. | |||
| Examples: | |||
| * *Ignore all issues on all files* | |||
| KEY = `*` | |||
| PATH = `**/*` | |||
| * *Ignore all issues on COBOL program "bank/ZTR00021.cbl"* | |||
| KEY = `*` | |||
| PATH = `bank/ZTR00021.cbl` | |||
| * *Ignore all issues on classes located directly in the Java package "com.foo", but not in its sub-packages* | |||
| KEY = `*` | |||
| PATH = `com/foo/*` | |||
| * *Ignore all issues against coding rule "cpp:Union" on files in the directory "object" and its sub-directories* | |||
| KEY = `cpp:Union` | |||
| PATH = `object/**/*` | |||
| ### Restrict Scope of Coding Rules | |||
| You can restrict the application of a rule to only certain components, ignoring all others. | |||
| Examples: | |||
| * *Only check the rule "Magic Number" on "Bean" objects and not on anything else* | |||
| KEY = `checkstyle:com.puppycrawl.tools.checkstyle.checks.coding.MagicNumberCheck` | |||
| PATH = `**/*Bean.java` | |||
| * *Only check the rule "Prevent GO TO statement from transferring control outside current module on COBOL programs" located in the directories "bank/creditcard" and "bank/bankcard". This requires two criteria to define it:* | |||
| KEY #1 = `cobol:COBOL.GotoTransferControlOutsideCurrentModuleCheck` | |||
| PATH #1 = `bank/creditcard/**/*` | |||
| KEY #2 = `cobol:COBOL.GotoTransferControlOutsideCurrentModuleCheck` | |||
| PATH #2 = `bank/bankcard/**/*` | |||
| ## Ignore Duplications | |||
| You can prevent some files from being checked for duplications. | |||
| To do so, go to **Administration > General Settings > Analysis Scope > Duplications** and set the *Duplication Exclusions* property. See the Patterns section for more details on the syntax. | |||
| ## Ignore Code Coverage | |||
| You can prevent some files from being taken into account for code coverage by unit tests. | |||
| To do so, go to **Administration > General Settings > Analysis Scope > Code Coverage** and set the *Coverage Exclusions* property. See the Patterns section for more details on the syntax. | |||
| ## Patterns | |||
| Paths are relative to the project base directory. | |||
| The following wildcards can be used: | |||
| \* zero or more characters | |||
| \*\* zero or more directories | |||
| \? a single character | |||
| Relative paths are based on the fully qualified name of the component. | |||
| Examples: | |||
| `# Exclude all classes ending by "Bean"` | |||
| `# Matches org/sonar.api/MyBean.java, org/sonar/util/MyOtherBean.java, org/sonar/util/MyDTO.java, etc.` | |||
| `sonar.exclusions=**/*Bean.java,**/*DTO.java` | |||
| `# Exclude all classes in the "src/main/java/org/sonar" directory` | |||
| `# Matches src/main/java/org/sonar/MyClass.java, src/main/java/org/sonar/MyOtherClass.java` | |||
| `# But does not match src/main/java/org/sonar/util/MyClassUtil.java` | |||
| `sonar.exclusions=src/main/java/org/sonar/*` | |||
| `# Exclude all COBOL programs in the "bank" directory and its sub-directories` | |||
| `# Matches bank/ZTR00021.cbl, bank/data/CBR00354.cbl, bank/data/REM012345.cob` | |||
| `sonar.exclusions=bank/**/*` | |||
| `# Exclude all COBOL programs in the "bank" directory and its sub-directories whose extension is .cbl` | |||
| `# Matches bank/ZTR00021.cbl, bank/data/CBR00354.cbl` | |||
| `sonar.exclusions=bank/**/*.cbl` | |||
+ 0
- 18
server/sonar-docs/src/pages/project-administration/portfolio-pdf-configuration.md
View File
| @@ -1,18 +0,0 @@ | |||
| --- | |||
| title: Portfolio PDF Configuration | |||
| url: /project-administration/portfolio-pdf-configuration/ | |||
| --- | |||
| *Portfolio PDFs are available as part of the [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html).* | |||
| A user with administrative rights on a portfolio can configure email distribution of the PDF. From a Portfolio Home Page go to **Administration > Executive Report**. | |||
| ###Frequency | |||
| You can tune the email frequency of the PDF Report. The possible values are: | |||
| * Daily: report is sent during the first portfolio calculation of the day (if any) | |||
| * Weekly: report is sent during the first portfolio calculation of the week (if any) from Monday | |||
| * Monthly (default): report is sent during the first portfolio calculation of the month (if any), starting from the first day of the current month | |||
| ###Other Recipients | |||
| If people without SonarQube accounts want to receive the PDF, you can feed the administrative "Other Recipients" field with their email addresses. | |||
+ 0
- 34
server/sonar-docs/src/pages/project-administration/project-existence.md
View File
| @@ -1,34 +0,0 @@ | |||
| --- | |||
| title: Project Existence | |||
| url: /project-administration/project-existence/ | |||
| --- | |||
| Typically, projects are created during their first analysis and never deleted (because old software never dies). For atypical situations, there is the page at **[Administration > Projects > Management](/#sonarqube-admin#/admin/projects_management/)**, which allows you to manage project existence. | |||
| ## How do I provision a project before its first analysis? | |||
| Provisioning a project allows you to declare and configure it (define permissions, set quality profiles, etc.) before running the first analysis. To be able to provision projects, you have to be logged in and be granted the Provision Projects permission. | |||
| To provision a new project, go to **[Administration > Projects > Management](/#sonarqube-admin#/admin/projects_management/)** and click on **Create Project**. The only required information is the key and the name of your project. | |||
| Once the project is provisioned, you can configure it (define permissions, set quality profiles, etc.), and when you're finished with the configuration, you can simply run the project's first analysis. | |||
| You can also provision and configure projects using the Web API. | |||
| ## How do I find provisioned projects (that haven't been analyzed yet)? | |||
| The **[Projects Management](/#sonarqube-admin#/admin/projects_management/)** search interface includes a toggle to allow you to narrow your results on this page to only projects that have never been analyzed. From there you can deal with them on this page as a set, or click through to the individual project homepages for individual attention and administration. | |||
| ## How do I lock down permissions on a project? (Private vs Public) | |||
| By default, any newly created project will be considered "Public". It means every SonarQube user, authenticated or not, will be able to: | |||
| * **Browse**: Access a project, browse its measures, issues and perform some issue edits (confirm/resolve/reopen, assignment, comment). | |||
| * **See Source Code**: View the project's source code. | |||
| If you want to be sure only a limited list of Groups and Users can see the project, you need to mark it Private. Once a project is private you will be able to define which Groups and Users can **Browse** the project or **See Source Code**. | |||
| If you want all newly created projects to be considered "Private", you can change the default visibility in **[Administration > Projects > Management](/#sonarqube-admin#/admin/projects_management/)**. | |||
| ## How do I delete projects? | |||
| A project may be deleted individually from the Administration page of the project. See Project Settings for more details. To delete projects in bulk, use **[Administration > Projects > Management](/#sonarqube-admin#/admin/projects_management/)**. Here you can select the projects to delete. A deleted project is gone for good, there is no way to undo this action. | |||
| ## How do I find projects that are no longer analyzed? | |||
| The **[Projects Management](/#sonarqube-admin#/admin/projects_management/)** search interface includes a date picker to help you find all projects last analyzed before your specified date. From there you can deal with them on this page as a set, or click through to the individual project homepages for individual attention and administration. | |||
+ 0
- 63
server/sonar-docs/src/pages/project-administration/project-settings.md
View File
| @@ -1,63 +0,0 @@ | |||
| --- | |||
| title: Project Settings | |||
| url: /project-administration/project-settings/ | |||
| --- | |||
| ## Table of Contents | |||
| ## Tags | |||
| Project tags allow you to categorize and group projects for easier selection on the Projects page. Project tags can be administered from the project home page. Administrators will see a dropdown menu indicator next to the project's list of current tags (or next to the "No tags" indicator). If the tag you want isn't visible in the dropdown, use the built in "search" input to find what you're looking for or create it on the fly. | |||
| ## Administration Items | |||
| Project administration is accessible through the **Administration** menu of each project. | |||
| Only project administrators can access project settings (See Authorization). | |||
| ### Adding a Project | |||
| A project is automatically added at its first analysis. Note that you can also provision projects. | |||
| ### Analysis Report Processing | |||
| A project-level Background Tasks page is available at **Administration > Tasks** to allow project administrators to check their projects' processing. It offers analysis report details and logs. See Background Tasks for more. | |||
| ### Deleting a Project | |||
| You can delete a project through **Administration > Deletion**: | |||
| Note also that a projects can also be deleted in bulk. | |||
| ### Setting the New Code Period | |||
| The new code period can be set on a per-project basis through **Administration > General Settings > New Code > New Code Period**. The default value is `previous_version`, which is most appropriate value for projects that version/release regularly. For other projects, a time period such as 30 days (enter "30", the "days" part is understood) may be more appropriate. | |||
| Note that this can be set at the global level as well. | |||
| ### Updating Project Key | |||
| The project key can be updated (without losing the history on the project) at **Administration > Update Key**. | |||
| The new key must contain at least one non-digit character. Allowed characters are: 'a' through 'z', 'A' through 'Z', '-' (dash), '\_' (underscore), '.' (dot), ':' (colon) and digits '0' to '9'. | |||
| ### Default Issue Assignee | |||
| When new issues are created during an analysis, they are assigned to the last committer where the issue was raised. When it is not possible to identify the last committer, issues can be assigned to a default assignee, at **Administration > General Settings > Issues**. | |||
| ### Setting Quality Gate and Quality Profiles | |||
| Project administrators can select which ... | |||
| * Quality profiles (go to **Administration > Quality Profiles**) | |||
| * Quality gate (go to **Administration > Quality Gate**) | |||
| ... to use on their project. | |||
| ### Setting Exclusions | |||
| See [Narrowing the Focus](/project-administration/narrowing-the-focus/). | |||
| ### Customizing Links | |||
| On top of standard links which may only be set as [Analysis Parameters](/analysis/analysis-parameters/), additional custom links can be added through the web interface (under **Administration > Links**). Those links will then be displayed in the [Project Page](/user-guide/project-page/). | |||
+ 0
- 63
server/sonar-docs/src/pages/requirements/benchmark.md
View File
| @@ -1,63 +0,0 @@ | |||
| --- | |||
| title: Benchmark | |||
| url: /requirements/benchmark/ | |||
| --- | |||
| ## Context | |||
| The following figures have been produced on common hardware available in most mid-size companies : | |||
| | App ESXi Server Configuration | DB ESXi Server Configuration | | |||
| | ------------------------------------------------------- | ------------------------------------------------------- | | |||
| | 2* Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (32 VCPUs) | 2* Intel(R) Xeon(R) CPU E5-2650 v2 @ 2.60GHz (32 VCPUs) | | |||
| | 128GB RAM | 128GB RAM | | |||
| | 1.9 TB volume (RAID5 of 8 Hard Drives of 300GB SAS 15K) | 1.9TB volume (RAID5 of 8 hard drives of 300GB SAS 15k) | | |||
| | 2*1 GB NICs | 2*1 GB NICs | | |||
| | ESXi 6.0 | ESXi 6.0 | | |||
| We created 2 VMs, one for SonarQube Server, one for SonarQube Database inside two ESXi 6.0 Servers : | |||
| | App VM Server Configuration | DB VM Server Configuration | | |||
| | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | |||
| | 8 VCPUs | 4 VCPUs | | |||
| | 16GB RAM | 8GB RAM | | |||
| | 20 GB storage for system + 200 GB storage for data (LVM) (RAID5 of 8 hard drives of 300GB SAS 15k) | 20 GB storage for system + 200 GB storage for data (LVM) | | |||
| | 1GB NIC | 1GB NIC | | |||
| | CentOS 7 64bits | CentOS 7 64bits | | |||
| | | MySQL 5.6.27 (Oracle Community Edition) | | |||
| ## Goals | |||
| With SonarQube 5.2+ there is no longer Source Lines indexation done by the SearchServer, so quantity of code you are going to analyze will not affect the performance of the SearchServer. | |||
| By running this benchmark, we wanted to validate the number of Millions of Issues a given hardware hosting SonarQube can support. | |||
| * can SonarQube digest millions of Issues and how many time does it take ? | |||
| ( can we still use the UI of SonarQube with these millions of Issues ? | |||
| ## Results | |||
| ### Indexation Throughput | |||
| Issues Indexation done by the Search Server is not linear : | |||
| | Millions of issues | Indexation time (hours) | | |||
| | ------------------ | ----------------------- | | |||
| | 25 | 1 | | |||
| | 60 | 2-3 | | |||
| | 100 | 6-7 | | |||
| ### RAM to Allocate to SearchServer | |||
| RAM to allocate to the SearchServer so to ElastSearch is linear according to the number of Issues : | |||
| | Millions of issues | SearchServer RAM in GB | | |||
| | ------------------ | ---------------------- | | |||
| | 25 | 4 | | |||
| | 60 | 7 | | |||
| | 100 | 12 | | |||
| *SearchServer's RAM can be configured in sonar.properties using : sonar.search.javaOpts* | |||
| ### CPU Allocation | |||
| With SonarQube 5.2+, the SearchServer is configured to use 5 [ElasticSearch Primary Shards](https://www.elastic.co/guide/en/elasticsearch/reference/2.0/glossary.html#glossary-primary-shard). This allows SonarQube to handle by default 50 Millions of Issues on a server having at least 4 CPU Cores dedicated to the SearchServer. | |||
| | Millions of issues | \#Shards | \# Cores | | | |||
| | ------------------ | -------- | -------- | --------------------- | | |||
| | 50 | 5 | 4 | default configuration | | |||
| | 30 | 3 | 2 | | | |||
| Shard configuration must be adjusted according to the quantity of Issues you have to manage. The rule is to have 1 Shard by block of 10M Issues. So for 100M Issues, you need 10 Shards, so at least 9 Cores. | |||
+ 0
- 41
server/sonar-docs/src/pages/requirements/hardware-recommendations.md
View File
| @@ -1,41 +0,0 @@ | |||
| --- | |||
| title: Hardware Recommendations | |||
| url: /requirements/hardware-recommendations/ | |||
| --- | |||
| ## Database | |||
| We recommend that for large instances, the database used by SonarQube is hosted on a machine which is physically separate from SonarQube Server but close to it on the network. | |||
| ### Oracle | |||
| In case your SonarQube Server is running on Linux and you are using Oracle, the Oracle JDBC Driver may be blocked due to /dev/random. See [this Oracle article](http://www.usn-it.de/index.php/2009/02/20/oracle-11g-jdbc-driver-hangs-blocked-by-devrandom-entropy-pool-empty/) for more details about this problem. | |||
| To avoid it, you may want to add this JVM parameter to your SonarQube Web Server (`sonar.web.javaOpts`) configuration : | |||
| ``` | |||
| -Djava.security.egd=file:///dev/urandom | |||
| ``` | |||
| ## Elasticsearch (aka ES) | |||
| * [Elasticsearch](https://www.elastic.co/) is used by SonarQube in the background in the SearchServer process. To ensure good performance of your SonarQube, you need to follow these recommendations that are linked to ES usage. | |||
| ## JVM | |||
| * It is recommended to set the min and max memory to the same value to prevent the heap from resizing at runtime, a very costly process. See -Xms and -Xmx of property `sonar.search.javaOpts`. | |||
| ## Disk | |||
| * Disk can easily become the bottleneck of ES. If you can afford SSDs, they are by far superior to any spinning media. SSD-backed nodes see boosts in both query and indexing performance. If you use spinning media, try to obtain the fastest disks possible (high performance server disks 15k RPM drives). | |||
| * Make sure to increase the number of open files descriptors on the machine (or for the user running SonarQube server). Setting it to 32k or even 64k is recommended. See [this ElasticSearch article](https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html). | |||
| * Using RAID 0 is an effective way to increase disk speed, for both spinning disks and SSD. There is no need to use mirroring or parity variants of RAID because of Elasticsearch replicas and database primary storage. | |||
| 8 Do not use remote-mounted storage, such as NFS, SMB/CIFS or network-attached storages (NAS). They are often slower, display larger latencies with a wider deviation in average latency, and are a single point of failure. | |||
| * Advanced: if you are using SSD, make sure your OS I/O Scheduler is configured correctly. When you write data to disk, the I/O Scheduler decides when that data is actually sent to the disk. The default under most *nix distributions is a scheduler called cfq (Completely Fair Queuing). This scheduler allocates "time slices" to each process, and then optimizes the delivery of these various queues to the disk. It is optimized for spinning media: the nature of rotating platters means it is more efficient to write data to disk based on physical layout. This is very inefficient for SSD, however, since there are no spinning platters involved. Instead, deadline or noop should be used instead. The deadline scheduler optimizes based on how long writes have been pending, while noop is just a simple FIFO queue. This simple change can have dramatic impacts. | |||
| * Advanced: if SQ home directory is located on a slow disk, then the property `sonar.path.data` can be used to move data to a faster disk (RAID 0 local SSD for instance). | |||
| ## Memory | |||
| * Machine available memory for OS must be at least the Elasticsearch heap size. The reason is that Lucene (used by ES) is designed to leverage the underlying OS for caching in-memory data structures. That means that by default OS must have at least 1Gb of available memory. | |||
| * Don't allocate more than 32Gb. See [this ElasticSearch article](http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/heap-sizing.html) for more details. | |||
| * Advanced: Elasticsearch uses a hybrid mmapfs / niofs directory by default to store its indices. The default operating system limits on mmap counts is likely to be too low, which may result in out of memory exceptions. On Linux, you can increase the limits by running the following command as root : | |||
| ``` | |||
| sysctl -w vm.max_map_count=262144 | |||
| ``` | |||
| To set this value permanently, update the `vm.max_map_count` setting in `/etc/sysctl.conf`. | |||
| ## CPU | |||
| * If you need to choose between faster CPUs or more cores, then choose more cores. The extra concurrency that multiple cores offers will far outweigh a slightly faster clock-speed. | |||
| * By nature data are distributed on multiples nodes, so execution time depends on the slowest node. It's better to have multiple medium boxes than one fast + one slow. | |||
+ 0
- 142
server/sonar-docs/src/pages/requirements/requirements.md
View File
| @@ -1,142 +0,0 @@ | |||
| --- | |||
| title: Prerequisites and Overview | |||
| url: /requirements/requirements/ | |||
| --- | |||
| ## Table of Contents | |||
| ## Prerequisite | |||
| The only prerequisite for running SonarQube is to have Java (Oracle JRE 8 or OpenJDK 8) installed on your machine. | |||
|  **Note:** _On Mac OS X it is highly recommended to install Oracle JDK 8 instead of the corresponding Oracle JRE since the JRE installation does not fully set up your Java environment properly. See [this post](http://stackoverflow.com/questions/15624667/mac-osx-java-terminal-version-incorrect) for more information._ | |||
| ## Hardware Requirements | |||
| 1. A small-scale (individual or small team) instance of the SonarQube server requires at least 2GB of RAM to run efficiently and 1GB of free RAM for the OS. If you are installing an instance for a large teams or Enterprise, please consider the additional recommendations below. | |||
| 2. The amount of disk space you need will depend on how much code you analyze with SonarQube. As an example, [SonarCloud](https://sonarcloud.io) the public instance of SonarQube, has more than 350 million lines of code under analysis with 5 years of history. SonarCloud is currently running on clustered [Amazon EC2 m5.large](http://aws.amazon.com/ec2/instance-types/) instances with allocations of 50 Gb of drive space per node. It handles 19,000+ projects with roughly 14M open issues. SonarCloud runs on PostgreSQL 9.5 and it is using about 250Gb of disk space for the database. | |||
| 3. SonarQube must be installed on hard drives that have excellent read & write performance. Most importantly, the "data" folder houses the Elasticsearch indices on which a huge amount of I/O will be done when the server is up and running. Great read & write hard drive performance will therefore have a great impact on the overall SonarQube server performance. | |||
| ### Enterprise Hardware Recommendations | |||
| For large teams or Enterprise-scale installations of SonarQube, additional hardware is required. At the Enterprise level, monitoring your SonarQube instance/instance-administration/java-process-memory is essential and should guide further hardware upgrades as your instance grows. A starting configuration should include at least: | |||
| * 8 cores, to allow the main SonarQube platform to run with multiple Compute Engine workers | |||
| * 16GB of RAM | |||
| For additional requirements and recommendations relating to database and ElasticSearch, see Hardware Recommendations/requirements/hardware-recommendations. | |||
| ## Supported Platforms | |||
| ### Java | |||
| The SonarQube Java analyzer is able to analyze any kind of Java source files regardless of the version of Java they comply to. But SonarQube analysis and the SonarQube Server require specific versions of the JVM. | |||
| We recommend using the Critical Path Update (CPU) releases. | |||
| | Java | | | |||
| | -------------- | ------------------------ | | |||
| | Oracle JRE |  9 | | |||
| | |  8 | | |||
| | |  7 | | |||
| | Open JDK |  9 | | |||
| | |  8 | | |||
| | |  7 | | |||
| | IBM JRE |  | | |||
| | GCJ |  | | |||
| | Oracle JRockit |  | | |||
| ### Database | |||
| | Database | | | |||
| | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | |||
| | [PostgreSQL](http://www.postgresql.org/) |  9.3 - 9.6 | | |||
| | |  10 | | |||
| | |  Must be configured to use UTF-8 charset | | |||
| | [Microsoft SQL Server](http://www.microsoft.com/sqlserver/) |  2012 (MSSQL Server 11.0) | | |||
| | |  2014 (MSSQL Server 12.0) with bundled Microsoft JDBC driver. Express Edition is supported. | | |||
| | |  2016 (MSSQL Server 13.0) with bundled Microsoft JDBC driver. Express Edition is supported. | | |||
| | |  Collation must be case-sensitive (CS) and accent-sensitive (AS) (example: Latin1_General_CS_AS) | | |||
| | |  READ_COMMITTED_SNAPSHOT must be set on the SonarQube database to avoid potential deadlocks under heavy load | | |||
| | |  Both Windows authentication (“Integrated Security”) and SQL Server authentication are supported. See the Microsoft SQL Server section in Installing/installation/installing-the-server page for instructions on configuring authentication. | | |||
| | [Oracle] (http://www.oracle.com/database/) |  10G | | |||
| | |  11G with [Oracle 11.2.x](http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html) drivers | | |||
| | |  12C with [Oracle 12.2.x](http://www.oracle.com/technetwork/database/features/jdbc/jdbc-ucp-122-3110062.html) drivers | | |||
| | |  Must be configured to use a UTF8-family charset (see NLS_CHARACTERSET) | | |||
| | |  The driver ojdbc14.jar is not supported | | |||
| | |  Only the thin mode is supported, not OCI | | |||
| | [MySQL](http://www.mysql.com/) | Not recommended for large instances | | |||
| | |  5.6 | | |||
| | |  5.7 | | |||
| | |  Must be configured to use UTF8 charset and a case-sensitive (CS) collation | | |||
| | |  Only InnoDB storage engine is supported, but not MyISAM | | |||
| | | Only the bundled mysql-connector-java jar is supported | | |||
| ### Web Browser | |||
| To get the full experience SonarQube has to offer, you must enable JavaScript in your browser. | |||
| | | | | |||
| | --------------------------- | --------------------------------------- | | |||
| | Microsoft Internet Explorer |  IE 9 | | |||
| | |  IE 10 | | |||
| | |  IE 11 | | |||
| | Microsoft Edge |  Latest | | |||
| | Mozilla Firefox |  Latest | | |||
| | Google Chrome |  Latest | | |||
| | Opera |  Not tested | | |||
| | Safari |  Latest | | |||
| ## Platform notes | |||
| ### Linux | |||
| If you're running on Linux, you must ensure that: | |||
| * vm.max_map_count is greater or equals to 262144 | |||
| * fs.file-max is greater or equals to 65536 | |||
| * the user running SonarQube can open at least 65536 file descriptors | |||
| * the user running SonarQube can open at least 2048 threads | |||
| You can see the values with the following commands : | |||
| ``` | |||
| sysctl vm.max_map_count | |||
| sysctl fs.file-max | |||
| ulimit -n | |||
| ulimit -u | |||
| ``` | |||
| You can set them dynamically for the current session by running the following commands as **_root_**: | |||
| ``` | |||
| sysctl -w vm.max_map_count=262144 | |||
| sysctl -w fs.file-max=65536 | |||
| ulimit -n 65536 | |||
| ulimit -u 2048 | |||
| ``` | |||
| To set these values more permanently, you must update either **/etc/sysctl.d/99-sonarqube.conf** (or **/etc/sysctl.conf** as you wish) to reflect these values. | |||
| If the user running SonarQube (**_sonarqube_** in this example) does not have the permission to have at least 65536 open descriptors, you must insert this line in **/etc/security/limits.d/99-sonarqube.conf** (or **/etc/security/limits.conf** as you wish) : | |||
| ``` | |||
| sonarqube - nofile 65536 | |||
| sonarqube - nproc 2048 | |||
| ``` | |||
| You can get more detail in the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/system-config.html). | |||
| If you are using systemd to start SonarQube, you must specify those limits inside your unit file in the section \[service\] : | |||
| ``` | |||
| [Service] | |||
| ... | |||
| LimitNOFILE=65536 | |||
| LimitNPROC=2048 | |||
| ... | |||
| ``` | |||
| ### seccomp filter | |||
| By default, Elasticsearch is [using seccomp filter](https://www.kernel.org/doc/Documentation/prctl/seccomp_filter.txt). On most distribution this feature is activated in the kernel, however on distribution like Red Hat Linux 6 this feature is deactivated. If you are using a distribution without this feature and you cannot upgrade to a newer version with seccomp activated, you have to explicitly deactivate this security layer by updating **sonar.search.javaAdditionalOpts** in **sonar.properties** : | |||
| ``` | |||
| sonar.search.javaAdditionalOpts=-Dbootstrap.system_call_filter=false | |||
| ``` | |||
| You can check if seccomp is available on your kernel with : | |||
| ``` | |||
| $ grep SECCOMP /boot/config-$(uname -r) | |||
| ``` | |||
| If your kernel has seccomp, you will see : | |||
| ``` | |||
| CONFIG_HAVE_ARCH_SECCOMP_FILTER=y | |||
| CONFIG_SECCOMP_FILTER=y | |||
| CONFIG_SECCOMP=y | |||
| ``` | |||
| For more detail, see the [Elasticsearch documentation](https://www.elastic.co/guide/en/elasticsearch/reference/5.6/breaking-changes-5.6.html). | |||
+ 0
- 21
server/sonar-docs/src/pages/setup/get-started-2-minutes.md
View File
| @@ -1,21 +0,0 @@ | |||
| --- | |||
| title: Get Started in Two Minutes Guide | |||
| url: /setup/get-started-2-minutes/ | |||
| --- | |||
| <!-- sonarqube --> | |||
| 1. Unzip - let's say in "C:\sonarqube" or "/etc/sonarqube", the SonarQube distribution once it's downloaded. ([Download Page](https://www.sonarqube.org/)) | |||
| 2. Start the SonarQube Server: | |||
| ``` | |||
| # On Windows, execute: | |||
| C:\sonarqube\bin\windows-x86-xx\StartSonar.bat | |||
| # On other operating systems, execute: | |||
| /etc/sonarqube/bin/[OS]/sonar.sh console | |||
| ``` | |||
| 3. Log in to [http://localhost:9000](http://localhost:9000) with System Administrator credentials (admin/admin) and follow the tutorial to analyze your first project. | |||
| <!-- /sonarqube --> | |||
+ 0
- 9
server/sonar-docs/src/pages/setup/install-cluster.md
View File
| @@ -1,9 +0,0 @@ | |||
| --- | |||
| title: Running SonarQube as a Cluster | |||
| url: /setup/install-cluster/ | |||
| --- | |||
| <!-- sonarqube --> | |||
| <!-- /sonarqube --> | |||
+ 0
- 35
server/sonar-docs/src/pages/setup/install-plugin.md
View File
| @@ -1,35 +0,0 @@ | |||
| --- | |||
| title: Install a Plugin | |||
| url: /setup/install-plugin/ | |||
| --- | |||
| <!-- sonarqube --> | |||
| There are two options to install a plugin into SonarQube: | |||
| - Marketplace - Installs plugins automatically, from the SonarQube UI. | |||
| - Manual Installation - You'll use this method if your SonarQube instance doesn't have access to the Internet. | |||
| ## Marketplace | |||
| If you have access to the Internet and you are connected with a SonarQube user having the Global Permission "Administer System", you can go to Administration > Marketplace. | |||
| - Find the plugin you want to install | |||
| - Click on Install and wait for the download to be processed | |||
| Once download is complete, a "Restart" button will be available to restart your instance. | |||
| See Marketplace for more details on how to configure your SonarQube Server to connect to the Internet. | |||
| ## Manual Installation | |||
| In the page dedicated to the plugin you want to install (ex: for Python: SonarPython, click on the "Download" link of the version compatible with your SonarQube version. | |||
| Put the downloaded jar in `$SONARQUBE_HOME/extensions/plugins`, removing any previous versions of the same plugins. | |||
| Once done, you will need to restart your SonarQube Server. | |||
| ### License | |||
| If you installed a Commercial Edition, you will need to set the License Key in Administration > Configuration > License Manager before being able to use it. | |||
| <!-- /sonarqube --> | |||
+ 0
- 9
server/sonar-docs/src/pages/setup/install-server.md
View File
| @@ -1,9 +0,0 @@ | |||
| --- | |||
| title: Installing the Server | |||
| url: /setup/install-server/ | |||
| --- | |||
| <!-- sonarqube --> | |||
| <!-- /sonarqube --> | |||
+ 0
- 127
server/sonar-docs/src/pages/setup/operate-server.md
View File
| @@ -1,127 +0,0 @@ | |||
| --- | |||
| title: Operate the Server | |||
| url: /setup/operate-server/ | |||
| --- | |||
| <!-- sonarqube --> | |||
| ## Running SonarQube as a Service on Windows | |||
| ### Install/uninstall NT service (may have to run these files via Run As Administrator): | |||
| ``` | |||
| %SONARQUBE_HOME%/bin/windows-x86-32/InstallNTService.bat | |||
| %SONARQUBE_HOME%/bin/windows-x86-32/UninstallNTService.bat | |||
| ``` | |||
| ### Start/stop the service: | |||
| ``` | |||
| %SONARQUBE_HOME%/bin/windows-x86-32/StartNTService.bat | |||
| %SONARQUBE_HOME%/bin/windows-x86-32/StopNTService.bat | |||
| ``` | |||
| ## Running SonarQube as a Service on Linux | |||
| The following has been tested on Ubuntu 8.10 and CentOS 6.2. | |||
| Create the file /etc/init.d/sonar with this content: | |||
| ``` | |||
| #!/bin/sh | |||
| # | |||
| # rc file for SonarQube | |||
| # | |||
| # chkconfig: 345 96 10 | |||
| # description: SonarQube system (www.sonarsource.org) | |||
| # | |||
| ### BEGIN INIT INFO | |||
| # Provides: sonar | |||
| # Required-Start: $network | |||
| # Required-Stop: $network | |||
| # Default-Start: 3 4 5 | |||
| # Default-Stop: 0 1 2 6 | |||
| # Short-Description: SonarQube system (www.sonarsource.org) | |||
| # Description: SonarQube system (www.sonarsource.org) | |||
| ### END INIT INFO | |||
| /usr/bin/sonar $* | |||
| ``` | |||
| Register SonarQube at boot time (Ubuntu, 32 bit): | |||
| ``` | |||
| sudo ln -s $SONAR_HOME/bin/linux-x86-32/sonar.sh /usr/bin/sonar | |||
| sudo chmod 755 /etc/init.d/sonar | |||
| sudo update-rc.d sonar defaults | |||
| ``` | |||
| Register SonarQube at boot time (RedHat, CentOS, 64 bit): | |||
| ``` | |||
| sudo ln -s $SONAR_HOME/bin/linux-x86-64/sonar.sh /usr/bin/sonar | |||
| sudo chmod 755 /etc/init.d/sonar | |||
| sudo chkconfig --add sonar | |||
| ``` | |||
| ## Securing the Server Behind a Proxy | |||
| This section helps you configure the SonarQube Server if you want to run it behind a proxy. This can be done for security concerns or to consolidate multiple disparate applications. | |||
| ### Server Configuration | |||
| To run the SonarQube server over HTTPS, you must build a standard reverse proxy infrastructure. | |||
| The reverse proxy must be configured to set the value "X_FORWARDED_PROTO: https" in each HTTP request header. Without this property, redirection initiated by the SonarQube server will fall back on HTTP. | |||
| ### Using an Apache Proxy | |||
| We assume that you've already installed Apache 2 with module mod_proxy, that SonarQube is running and available on http://private_sonar_host:sonar_port/ and that you want to configure a Virtual Host for www.public_sonar.com. | |||
| At this point, edit the HTTPd configuration file for the www.public_sonar.com virtual host. Include the following to expose SonarQube via mod_proxy at http://www.public_sonar.com/: | |||
| ``` | |||
| ProxyRequests Off | |||
| ProxyPreserveHost On | |||
| <VirtualHost *:80> | |||
| ServerName www.public_sonar.com | |||
| ServerAdmin admin@somecompany.com | |||
| ProxyPass / http://private_sonar_host:sonar_port/ | |||
| ProxyPassReverse / http://www.public_sonar.com/ | |||
| ErrorLog logs/somecompany/sonar/error.log | |||
| CustomLog logs/somecompany/sonar/access.log common | |||
| </VirtualHost> | |||
| ``` | |||
| Apache configuration is going to vary based on your own application's requirements and the way you intend to expose SonarQube to the outside world. If you need more details about Apache HTTPd and mod_proxy, please see [http://httpd.apache.org](http://httpd.apache.org). | |||
| ### Using Nginx | |||
| We assume that you've already installed Nginx, that you are using a Virtual Host for www.somecompany.com and that SonarQube is running and available on http://sonarhost:sonarport/. | |||
| At this point, edit the Nginx configuration file. Include the following to expose SonarQube at http://www.somecompany.com/: | |||
| ``` | |||
| # the server directive is nginx's virtual host directive | |||
| server { | |||
| # port to listen on. Can also be set to an IP:PORT | |||
| listen 80; | |||
| # sets the domain[s] that this vhost server requests for | |||
| server_name www.somecompany.com; | |||
| location / { | |||
| proxy_pass http://sonarhost:sonarport; | |||
| } | |||
| } | |||
| ``` | |||
| Nginx configuration will vary based on your own application's requirements and the way you intend to expose SonarQube to the outside world. If you need more details about Nginx, please see [https://www.nginx.com/resources/admin-guide/reverse-proxy/](https://www.nginx.com/resources/admin-guide/reverse-proxy/). | |||
| Note that you may need to increase the max URL length since SonarQube requests can have URLs longer than 2048. | |||
| ### Using IIS | |||
| Please see: [http://blog.jessehouwing.nl/2016/02/configure-ssl-for-sonarqube-on-windows.html](http://blog.jessehouwing.nl/2016/02/configure-ssl-for-sonarqube-on-windows.html) | |||
| <!-- /sonarqube --> | |||
+ 0
- 19
server/sonar-docs/src/pages/setup/overview.md
View File
| @@ -1,19 +0,0 @@ | |||
| --- | |||
| title: Overview | |||
| url: /setup/overview/ | |||
| --- | |||
| <!-- sonarqube --> | |||
| ## Get Started in Two Minutes | |||
| To give the SonarQube Platform a quick try, follow the [Get Started in Two Minutes Guide](/setup/get-started-2-minutes/). | |||
| ## Install a Production Instance | |||
| To install a production instance, read the Requirements, and then follow the Installation Guide. | |||
| ## After the Installation | |||
| After your server is up and running, you'll need to install one or more [SonarQube Scanners](https://docs.sonarqube.org/display/SCAN) on the machines where analysis will be performed. | |||
| ## Upgrade your Production Instance | |||
| To upgrade your production instance, read the Upgrade Guide and the relevant, version-specific upgrade notes. | |||
| <!-- /sonarqube --> | |||
+ 0
- 43
server/sonar-docs/src/pages/setup/troubleshooting.md
View File
| @@ -1,43 +0,0 @@ | |||
| --- | |||
| title: Troubleshooting | |||
| url: /setup/troubleshooting/ | |||
| --- | |||
| <!-- sonarqube --> | |||
| ## Checking the logs | |||
| If you're having trouble starting your server for the first time (or any subsequent time!) the first thing to do is check your server logs. You'll find them in `$SONARQUBE_HOME/logs`: | |||
| * sonar.log - Log for the main process. Holds general information about startup and shutdown. You'll get overall status here but not details. Look to the other logs for that. | |||
| * web.log - Information about initial connection to the database, database migration and reindexing, and the processing of HTTP requests. This includes database and search engine logs related to those requests. | |||
| * ce.log - Information about background task processing and the database and search engine logs related to those tasks. | |||
| * es.log - Ops information from the search engine, such as Elasticsearch startup, health status changes, cluster-, node- and index-level operations, etc. | |||
| ## Understanding the logs | |||
| When there's an error, you'll very often find a stacktrace in the logs. If you're not familiar stacktraces, they can be intimidatingly tall walls of incomprehensible text. As a sample, here's a fairly short one: | |||
| ``` | |||
| java.lang.IllegalStateException: Unable to blame file **/**/foo.java | |||
| at org.sonarsource.scm.git.JGitBlameCommand.blame(JGitBlameCommand.java:128) | |||
| at org.sonarsource.scm.git.JGitBlameCommand.access$000(JGitBlameCommand.java:44) | |||
| at org.sonarsource.scm.git.JGitBlameCommand$1.call(JGitBlameCommand.java:112) | |||
| at org.sonarsource.scm.git.JGitBlameCommand$1.call(JGitBlameCommand.java:109) | |||
| at java.util.concurrent.FutureTask.run(Unknown Source) | |||
| at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) | |||
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) | |||
| at java.lang.Thread.run(Unknown Source) | |||
| Caused by: java.lang.NullPointerException | |||
| at org.eclipse.jgit.treewalk.filter.PathFilter.create(PathFilter.java:77) | |||
| at org.eclipse.jgit.blame.BlameGenerator.<init>(BlameGenerator.java:161) | |||
| at org.eclipse.jgit.api.BlameCommand.call(BlameCommand.java:203) | |||
| at org.sonarsource.scm.git.JGitBlameCommand.blame(JGitBlameCommand.java:126) | |||
| ... 7 more | |||
| ``` | |||
| Unless you wrote the code that produced this error, you really only care about: | |||
| * the first line, which ought to have a human-readable message after the colon. In this case, it's Unable to blame file `**/**/foo.java` | |||
| * and any line that starts with `Caused by:`. There are often several `Caused by` lines, and indentation makes them easy to find as you scroll through the error. Be sure to read each of these lines. Very often one of them - the last one or next to last one - contains the real problem. | |||
| <!-- /sonarqube --> | |||
+ 0
- 121
server/sonar-docs/src/pages/setup/upgrade-notes.md
View File
| @@ -1,121 +0,0 @@ | |||
| --- | |||
| title: Release Upgrade Notes | |||
| url: /setup/upgrade-notes/ | |||
| --- | |||
| <!-- sonarqube --> | |||
| ## Release 7.3 Upgrade Notes | |||
| ### New "Administer Security Hotspots" Permission | |||
| During the upgrade, the new "Administer Security Hotspots" permission is granted to all users/groups who already have the "Administer Issues" permission. | |||
| ### Expanded Compute Engine Logs | |||
| Starting with this version, Compute Engine logs will be more verbose. These logs are rotated automatically, but on a daily basis, not based on file size. | |||
| ### PostgreSQL < 9.3 No Longer Supported | |||
| SonarQube 7.3+ only supports PostgreSQL 9.3 to 10. SonarQube will not start if you are using a lower version of PostgreSQL. | |||
| ### Some 3rd-party Plugins Incompatible | |||
| APIs deprecated before SonarQube 5.6 are dropped in this version, making some third-party plugins incompatible. It is always advised to check plugin compatibility in the Plugin Version Matrix with each new upgrade, and more so for this version. | |||
| ## Release 7.2 Upgrade Notes | |||
| ### License Incompatibility | |||
| Users coming from 6.7.5 must not upgrade to this version. Your license will be incompatible. Instead, if you seek an upgrade to an intermediate version before the next L.T.S. version, you must start from 7.3 or higher. | |||
| ### Pull Request Analysis | |||
| Pull Requests are now a first class citizen feature in SonarQube for Developer, Enterprise and Data Center Edition users. | |||
| If you are using GitHub, you need to be sure to NOT have the GitHub Plugin in your SONARQUBE_HOME/extensions/plugins directory. | |||
| ### New Edition Packaging | |||
| SonarSource Commercial Editions are now distributed individually, so you directly get the features and functionalities that match your needs. This means that upgrade/downgrade from one edition to another is no longer possible within the SonarQube Marketplace. In order to use a different edition you must download its dedicated package, and have a license ready for using that edition. | |||
| ### Deprecated Features | |||
| SonarQube 7.2 is the last version supporting PostgreSQL < 9.3. Starting from SonarQube 7.3 the minimal supported version of PostgreSQL will be 9.3: SONAR-10668 | |||
| ### Dropped Features | |||
| None | |||
| ## Release 7.1 Upgrade Notes | |||
| ### License Incompatibility | |||
| Users coming from 6.7.5 must not upgrade to this version. Your license will be incompatible. Instead, if you seek an upgrade to an intermediate version before the next L.T.S. version, you must start from 7.3 or higher. | |||
| ### Live Portfolios | |||
| Portfolio measures are now updated without having to explicitly trigger recalculation. As a result, the "views" scanner task no longer has any effect, and will fail with a clear error message. | |||
| ### Deprecated Features | |||
| Support for MySQL is deprecated for all editions below Data Center Edition (see below). | |||
| ### Dropped Features | |||
| - Support for MySQL in Data Center Edition. | |||
| - The "accessors" metric, which was deprecated in SonarQube 5.0. | |||
| ## Release 7.1 Upgrade Notes | |||
| ### License incompatibility | |||
| Users coming from 6.7.5 must not upgrade to this version. Your license will be incompatible. Instead, if you seek an upgrade to an intermediate version before the next L.T.S. version, you must start from 7.3 or higher. | |||
| ### Measures: Live Update | |||
| Project measures, including the Quality Gate status, are computed without having to trigger another code scan when issue changes may impact them. | |||
| ### Built-In Read-Only Quality Gate | |||
| In order to make clear the default, minimum and recommended criteria Quality Gates, the "Sonar way" Quality Gate is now read-only, and the default if one is not already set. It may be updated automatically at each upgrade of SonarQube. | |||
| ### Deprecated Features | |||
| None | |||
| ### Dropped Features | |||
| It's no longer possible to unset the default Quality Gate. | |||
| ## Release 6.7.5 Upgrade Notes | |||
| ### Commercial Edition Must Be Upgraded | |||
| Because a new server identifier will be generated at upgrade to this version, startup will fail unless you upgrade your commercial edition to the latest compatible version. I.E. don't just copy over your edition plugins from one instance to the next, but make sure to download the latest edition bundle. | |||
| ### SonarLint Must Be Upgraded | |||
| Analyzers provided as part of a commercial package will be disabled in old versions of SonarLint. SonarLint users must upgrade to the latest available version: | |||
| - SonarLint for Eclipse: 3.3+. | |||
| - SonarLint for IntelliJ: 3.1+ | |||
| ### Multi-Version Upgrade | |||
| Don't forget to read all the intermediate upgrade notes if you're upgrading more than a single version. | |||
| ## Release 6.7 Upgrade Notes | |||
| ### Drop of Issues Report | |||
| The deprecated Issues Report feature has been removed. | |||
| <!-- /sonarqube --> | |||
+ 0
- 60
server/sonar-docs/src/pages/setup/upgrading.md
View File
| @@ -1,60 +0,0 @@ | |||
| --- | |||
| title: Upgrading | |||
| url: /setup/upgrading/ | |||
| --- | |||
| <!-- sonarqube --> | |||
| Upgrading across multiple versions is handled automatically. However, if in your migration path you have an LTS version, you must first migrate to this LTS and then migrate to your target version. | |||
| Example 1 : 5.1 -> 7.0, migration path is 5.1 -> 5.6.7 LTS -> 6.7.x LTS -> 7.0 | |||
| Example 2 : 6.2 -> 6.7, migration path is 6.2 -> 6.7.x LTS (where x is the latest patch available for 6.7 - you don't need to install all the intermediary patches, just take the latest) | |||
| ## How to Upgrade? | |||
| This is a generic upgrade guide, please read carefully the Upgrade Notes of your target version and of each intermediate version, if any (below). | |||
|  Planning to Upgrade to a Commercial Editions? | |||
| If you are targetting to move to 6.7 LTS and to install a commercial Edition, please read this [documentation](https://docs.sonarqube.org/display/SONARQUBE67/SonarSource+Editions). | |||
| Before you start, backup your SonarQube Database. Upgrade problems are rare, but you'll want the backup if anything does happen. | |||
| 1. Download and unzip the SonarQube distribution of your edition in a fresh directory, let's say `$NEW_SONARQUBE_HOME` | |||
| 2. Manually install the non-default plugins that are compatible with your version of SonarQube. Use the Compatibility Matrix to ensure that the versions you install are compatible with your server version. Note that the most recent versions of all SonarSource code analyzers available in your edition are installed by default. Simply copying plugins from the old server to the new is not recommended; incompatible or duplicate plugins could cause startup errors. | |||
| 3. Update the contents of `sonar.properties` and `wrapper.conf` files (in `$NEW_SONARQUBE_HOME/conf`) with the settings of the related files in the `$OLD_SONARQUBE_HOME/conf` directory (web server URL, database, ldap settings, etc.). Do not copy-paste the old files. | |||
| If you are using the Oracle DB, copy its JDBC driver into `$NEW_SONARQUBE_HOME/extensions/jdbc-driver/oracle` | |||
| 4. Stop your old SonarQube Server | |||
| 5. Start your new SonarQube Server | |||
| 6. Browse to `http://yourSonarQubeServerURL/setup` and follow the setup instructions | |||
| 7. Analyze your projects (and compute your Views|Portofolios|Application if you own the Enterprise Edition product) to get fresh data | |||
| ## Anything Else? | |||
| ### Oracle Clean-up | |||
| Starting with 6.6, there's an additional step you may want to perform if you're using Oracle. On Oracle the database columns to be dropped are now marked as UNUSED and are not physically dropped anymore. To reclaim disk space, Oracle administrators must drop these unused columns manually. The SQL request is `ALTER TABLE foo DROP UNUSED COLUMNS`. The relevant tables are listed in the system table `all_unused_col_tabs`. | |||
| ### Additional Database Maintenance | |||
| Refreshing your database's statistics and rebuilding your database's indices are recommended once the technical upgrade is done (just before the very last step). | |||
| For PostgreSQL, that means executing `VACUUM FULL`. According to the PostgreSQL documentation: | |||
| ``` | |||
| In normal PostgreSQL operation, tuples that are deleted or obsoleted by an update are not physically removed from their table; they remain present until a VACUUM is done. | |||
| ``` | |||
| ### Scanner Update | |||
| When upgrading SonarQube, you should also make sure you’re using the latest versions of the SonarQube scanners to take advantage of features and fixes on the scanner side. Please check the documentation pages of the Scanners you use for the most recent version compatible with SonarQube and your build tools. | |||
| ### SonarQube as a Linux or Windows Service | |||
| If you use external configuration, such as a script or Windows Service to control your server, you'll need to update it to point to `$NEW_SONARQUBE_HOME`. | |||
| In case you used the InstallNTService.bat to install SonarQube as a Windows Service, run the $OLD_SONARQUBE_HOME/bin/.../UninstallNTService.bat before running the InstallNTService.bat of the $NEW_SONARQUBE_HOME. | |||
| ## Release Upgrade Notes | |||
| Usually SonarQube releases come with some specific recommendations for upgrading from the previous version. You should read the upgrade notes for each version between your current version and the target version. To upgrade from a version not listed in [Release Upgrade Notes](/setup/upgrade-notes/), see [Documentation for Previous Versions](https://docs.sonarqube.org/display/SONARNEXT/Documentation+for+previous+versions). | |||
| <!-- /sonarqube --> | |||
+ 1
- 1
server/sonar-docs/src/pages/sonarcloud/analyze-a-project.md
View File
| @@ -8,7 +8,7 @@ url: /analyze-a-project/ | |||
| A project must belong to an [organization](/organizations/overview/). Create one if you intend to collaborate with your team mates, or use your personal organization for test purposes. | |||
| [[info]] | |||
| | ** Important note for private code:** Newly created organizations and personal organizations are under a free plan by default. This means projects analyzed on these organizations are public by default: the code will be browsable by anyone. If you want private projects, you should [upgrade your organization to a paid plan](/sonarcloud-pricing/). | |||
| | ** Important note for private code:** Newly created organizations and personal organizations are under a free plan by default. This means projects analyzed on these organizations are public by default: the code will be browsable by anyone. If you want private projects, you should [upgrade your organization to a paid plan](/sonarcloud-pricing/) in the "Administration > Billing" page of your organization. | |||
| Find the key of your organization, you will need it at later stages. It can be found on the top right corner of your organization's header. | |||
+ 1
- 1
server/sonar-docs/src/pages/sonarcloud/privacy.md
View File
| @@ -1,5 +1,5 @@ | |||
| --- | |||
| title: Privacy Policy | |||
| title: Privacy | |||
| url: /privacy/ | |||
| --- | |||
+ 1
- 1
server/sonar-docs/src/pages/sonarcloud/security.md
View File
| @@ -1,5 +1,5 @@ | |||
| --- | |||
| title: Security Statement | |||
| title: SonarCloud Security | |||
| url: /security/ | |||
| --- | |||
+ 0
- 28
server/sonar-docs/src/pages/user-guide/applications.md
View File
| @@ -1,28 +0,0 @@ | |||
| --- | |||
| title: Applications | |||
| url: /user-guide/applications/ | |||
| --- | |||
| *Applications are available as part of the [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html).* | |||
| ## Using Applications | |||
| An Application is an aggregation of projects into a synthetic project. Assume you have a set of projects which has been split for technical reasons, but which shares a lifecycle; they interact directly in production and are always released together. With an Application, they can be treated as a single entity in {instance} with a unified Project Homepage, Issues list, Measures space, and most importantly: Quality Gate. | |||
| ### Applications vs. Portfolios | |||
| Applications and Portfolios are both aggregations of projects, but they have different goals and therefore different presentations. A Portfolio is designed to be a very high-level, executive overview that shows how a package of projects that may only be tangentially related are doing quality-wise, and what the trends are. Applications allow you to see your set of projects as a larger, overall meta-project. For instance, because all the projects in an application ship together, if one of them isn't releasable then none of them are, and an Application's consolidated Quality Gate gives you an immediate summary of what must be fixed across all projects in order to allow you to release the set. | |||
| ## Application Setup | |||
| Applications are created and edited in the global Portfolio administration interface: **Administration > Configuration > Portfolios**. For more, see [Configuring Portfolios and Applications](/instance-administration/configuring-portfolios-and-applications/). Applications must be created initially by a user with global administration rights, but after set-up, administration of an individual Application can be delegated to other users. | |||
| ### Populating Application Data | |||
| An Application is automatically re-calculated after each analysis of one of its projects. If you want immediate (re)calculation, a user with administration rights on the Application can use the Recompute button in the Application-level Administration > Edit Definition interface. The global Portfolio administration interface: **Administration > Configuration > Portfolios** offers the ability to queue re-computation of all Applications and Portfolios at once. | |||
| ## Applications and Branch Analysis | |||
| Long-lived Branches are available for applications. They allow you to aggregate long-lived branches from the projects in an application. | |||
| Once an Application has been set up, anyone with administration rights on the Application can manually create a new branch in the **Administration > Edit Definition** interface. Branches can also be managed from the global **Administration > Configuration > Portfolios** interface. For each Application branch you can choose which project branch should be included, or whether the project should be represented in the branch at all. | |||
+ 0
- 25
server/sonar-docs/src/pages/user-guide/built-in-rule-tags.md
View File
| @@ -1,25 +0,0 @@ | |||
| --- | |||
| title: Built-in Rule Tags | |||
| url: /user-guide/built-in-rule-tags/ | |||
| --- | |||
| Tags are a way to categorize rules and issues. Issues inherit the tags on the rules that raised them. Some tags are language-specific, but many more appear across languages. Users can add tags to rules and issues, but most rules have some tags out of the box. Here is a non-comprehensive list of what some of those built-in tags mean: | |||
| * [brain-overload](https://sonarcloud.io/coding_rules?tags=brain-overload) - there is too much to keep in your head at one time | |||
| * [bad-practice](https://sonarcloud.io/coding_rules?tags=bad-practice) - the code likely works as designed, but the way it was designed is widely recognized as being a bad idea. | |||
| * [bug](https://sonarcloud.io/coding_rules?tags=bug) - something is wrong and it will probably affect production | |||
| * [cert](https://sonarcloud.io/coding_rules?tags=cert) - relates to a rule in a [CERT](https://www.securecoding.cert.org/confluence/x/BgE) standard. There are currently three CERT standards: [C](https://www.securecoding.cert.org/confluence/x/HQE), [C++](https://www.securecoding.cert.org/confluence/x/fQI), and [Java](https://www.securecoding.cert.org/confluence/x/Ux). Many of these rules are not language-specific, but are good programming practices. That's why you'll see this tag on non-C/C++, Java rules. | |||
| * [clumsy](https://sonarcloud.io/coding_rules?tags=clumsy) - extra steps are used to accomplish something that could be done more clearly and concisely. (E.G. calling .toString() on a String). | |||
| * [confusing](https://sonarcloud.io/coding_rules?tags=confusing) - will take maintainers longer to understand than is really justified by what the code actually does | |||
| * [convention](https://sonarcloud.io/coding_rules?tags=convention) - coding convention - typically formatting, naming, whitespace... | |||
| * [cwe](https://sonarcloud.io/coding_rules?tags=cwe) - relates to a rule in the [Common Weakness Enumeration](http://cwe.mitre.org/). For more on CWE in SonarQube language plugins, and on security-related rules in general, see [Security-related rules](/user-guide/security-rules/). | |||
| * [design](https://sonarcloud.io/coding_rules?tags=design) - there is something questionable about the design of the code | |||
| * [lock-in](https://sonarcloud.io/coding_rules?tags=lock-in) - environment-specific features are used | |||
| * [misra](https://sonarcloud.io/coding_rules?tags=misra) - relates to a rule in one of the [MISRA](http://www.misra.org.uk/) standards. While the MISRA rules are primarily about C and C++, many of them are not language-specific (E.G. don't use a float as a loop counter) but are simply good programming practices. That's why you'll see these tags on non-C/C++ rules. | |||
| * [owasp-.*](https://sonarcloud.io/coding_rules?tags=owasp-a1%2Cowasp-a2%2Cowasp-a3%2C%2Cowasp-a4%2Cowasp-a5%2Cowasp-a6%2Cowasp-a7%2Cowasp-a8%2Cowasp-a9%2Cowasp-a10) - relates to a rule in the [OWASP Top Ten](https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project) security standards. Note, that the OWASP Top Ten is a list of high-level vulnerabilities which translates to many, many potential rules. | |||
| * [pitfall](https://sonarcloud.io/coding_rules?tags=pitfall) - nothing is wrong yet, but something could go wrong in the future; a trap has been set for the next guy and he'll probably fall into it and screw up the code. | |||
| * [sans-top25-.*](https://sonarcloud.io/coding_rules?tags=sans-top25-risky%2Csans-top25-porous%2Csans-top25-insecure) - relates to the [SANS Top 25 Coding Errors](http://www.sans.org/top25-software-errors/), which are security-related. Note that the SANS Top 25 list is pulled directly from the CWE. | |||
| * [security](https://sonarcloud.io/coding_rules?tags=security) - relates to the security of an application. | |||
| * [suspicious](https://sonarcloud.io/coding_rules?tags=suspicious) - it's not guaranteed that this is a **bug**, but it looks suspiciously like one. At the very least, the code should be re-examined & likely refactored for clarity. | |||
| * [unpredictable](https://sonarcloud.io/coding_rules?tags=unpredictable) - the code may work fine under current conditions, but may fail erratically if conditions change. | |||
| * [unused](https://sonarcloud.io/coding_rules?tags=unused) - unused code, E.G. a private variable that is never used. | |||
| * [user-experience](https://sonarcloud.io/coding_rules?tags=user-experience) - there's nothing technically wrong with your code, but it may make some or all of your users hate you. | |||
+ 0
- 71
server/sonar-docs/src/pages/user-guide/code-viewer.md
View File
| @@ -1,71 +0,0 @@ | |||
| --- | |||
| title: Code Viewer | |||
| url: /user-guide/code-viewer/ | |||
| --- | |||
| ## Table of Contents | |||
| The code viewer is the heart of {instance}: it displays the source code of a file (both source and test files), and its high-level statistics: | |||
| * **Lines** | |||
| * **Issues** (generated by the rules activated on the quality profile) | |||
| * **Test coverage** by unit or integration tests | |||
| * **Duplications** within the same file or in other files | |||
| * **SCM information** like who last committed a specific line and when | |||
| You will land on the code viewer: | |||
| * when drilling down from the Measures and Code pages. | |||
| * when reviewing issues on the Issues page. | |||
| * when searching for a particular file using the search input at the top-right. | |||
| The code viewer has two aspects, the current file and pinned files. | |||
| ## Current File | |||
| ### Layout | |||
| The code viewer is composed of 2 parts: | |||
| * The **header** lies across the top of the file. It displays useful information such as # lines, # issues, coverage and duplication percentages. | |||
| * The **source code** is in the center, decorated with additional information such as SCM data, coverage and duplications bars. | |||
| ### Header | |||
| The header can contain up to four data blocks, one per main axis: Lines, Issues, Coverage (for source files) or Tests (for test files), and Duplications. Data blocks which aren't relevant to the current file won't be shown. For instance, if the project has no tests, the coverage number will be omitted. Similarly, the duplications block will be omitted if there are no duplications. | |||
| ### The source code | |||
| The main purpose of the code viewer is to show source code and any problems it may have. For that reason, issue, duplication, and test decorations are always visible, but issues may be collapsed if you don't come to the code viewer from the Issues page, and a yellow highlight is present on all new code. | |||
| The light yellow background is meaning: new code during the leak period. | |||
| The dark yellow background is meaning: new code during the leak period not covered by tests. | |||
| ### Additional actions | |||
| The actions menu at the top-right of the code viewer header offers additional options. | |||
| * **INSERT GRAPHIC HERE** | |||
| The most notable of these is "Show Details", which opens a modal popup with additional data on the file: | |||
| * **INSERT GRAPHIC HERE** | |||
| ### Pinned Files | |||
| Both source files and rule descriptions can be pinned directly: | |||
| * **INSERT GRAPHIC HERE** | |||
| or from another file's duplication detail. | |||
| You can adjust the height of the currently-active pinned window, minimize it, maximize it, and close it. The currently-active window will automatically be minimized if you change contexts or pin another file. | |||
| ### Further Reading | |||
| To learn more about the code viewer, please see : | |||
| * **INSERT LINKS BELOW** | |||
| * Seeing Coverage | |||
| * Seeing Tests | |||
| * Seeing Duplications | |||
+ 0
- 147
server/sonar-docs/src/pages/user-guide/issues.md
View File
| @@ -1,147 +0,0 @@ | |||
| --- | |||
| title: Issues | |||
| url: /user-guide/issues/ | |||
| --- | |||
| ## Table of Contents | |||
| While running an analysis, {instance} raises an issue every time a piece of code breaks a coding rule. The set of coding rules is defined through the associated [quality profile](/instance-administration/quality-profiles/) for each language in the project. | |||
| Each issue has one of five severities: | |||
| 1. **BLOCKER** | |||
| Bug with a high probability to impact the behavior of the application in production: memory leak, unclosed JDBC connection, .... The code MUST be immediately fixed. | |||
| 1. **CRITICAL** | |||
| Either a bug with a low probability to impact the behavior of the application in production or an issue which represents a security flaw: empty catch block, SQL injection, ... The code MUST be immediately reviewed. | |||
| 1. **MAJOR** | |||
| Quality flaw which can highly impact the developer productivity: uncovered piece of code, duplicated blocks, unused parameters, ... | |||
| 1. **MINOR** | |||
| Quality flaw which can slightly impact the developer productivity: lines should not be too long, "switch" statements should have at least 3 cases, ... | |||
| 1. **INFO** | |||
| Neither a bug nor a quality flaw, just a finding. | |||
| Ideally, the team wouldn't introduce any new issues (any new technical debt). [SonarLint](https://sonarlint.org) can help developers because it provides the ability to perform local analyses to check their code before pushing it back to the SCM. But in real life, it's not always possible to code without any new technical debt, and sometimes it's not worth it. | |||
| So new issues get introduced. | |||
| ## Understanding issue context | |||
| Sometimes, issues are self-evident once they're pointed out. For instance, if your team has agreed to a init-lower, camelCase variable naming convention, and an issue is raised on `My_variable`, you don't need a lot of context to understand the problem. But in other situations context may be essential to understanding why an issue was raised. That's why {instance} supports not just the primary issue location, where the issue message is shown, but also secondary issue locations. For instance, secondary issues locations are used to mark the pieces of code in a method which add Cognitive Complexity to a method. | |||
| But there are times when a simple laundry list of contributing locations isn't enough to understand an issue. For instance, when a null pointer can be dereferenced on some paths through the code, what you really need are issue flows. Each flow is a _set_ of secondary locations ordered to show the exact path through the code on which a problem can happen. And because there can be multiple paths through the code on which, for instance a resource is not released, {instance} supports multiple flows. | |||
| ## Lifecycle of Code Smell, Bug, and Vulnerability Issues | |||
| ### Statuses | |||
| After creation, issues flow through a lifecycle, taking one of five possible statuses: | |||
| * **Open** - set by {instance} on new issues | |||
| * **Confirmed** - set manually to indicate that the issue is valid | |||
| * **Resolved** - set manually to indicate that the next analysis should Close the issue | |||
| * **Reopened** - set automatically by {instance} when a Resolved issue hasn't actually been corrected | |||
| * **Closed** - set automatically by {instance} for automatically created issues. | |||
| ### Resolutions | |||
| Closed issues will have one of two resolutions: | |||
| * **Fixed** - set automatically when a subsequent analysis shows that the issue has been corrected | |||
| * **Removed** - set automatically when either the related coding rule or the file is no longer available. The rule may not be available either because it has been removed from the profile or because the underlying plugin has been uninstalled. The file could be unavailable because it has been removed from the project, moved to a different location or renamed. | |||
| Resolved issues will have one of two resolutions: | |||
| * **False Positive** - set manually | |||
| * **Won't Fix** - set manually | |||
| ### Issue Workflow | |||
| Issues are automatically closed (status: Closed) when: | |||
| * an issue (of any status) has been properly fixed => Resolution: Fixed | |||
| * an issue no longer exists because the related coding rule has been deactived or is no longer available (ie: plugin has been removed) => Resolution: Removed | |||
| Issues are automatically reopened (status: Reopened) when: | |||
| * an issue that was manually Resolved as Fixed(but Resolution is not False positive) is shown by a subsequent analysis to still exist | |||
| ### Security Hotspot Issue Lifecycle | |||
| Security Hotspot issues have a dedicated lifecycle. They aren't considered actionable, and must be reviewed by a user with the "Administer Security Hotspots" permission. | |||
| ## Lifecycle of Security Hotspot Issues | |||
| Security Hotspot issues have a dedicated lifecycle. They aren't considered actionable, and must be reviewed by a user with the "Administer Security Hotspots" permission. | |||
| ### Statuses | |||
| After creation, Security Hotspot issues flow through a dedicated lifecycle, taking one of four possible statuses: | |||
| * **Open** - set by {instance} on new issues | |||
| * **Resolved** (Won't Fix) - set automatically by {instance} when a Security Auditor Accepts the fix done by a developer on a Manual Vulnerability or when an Open Hotspot or Manual Vulnerability is Cleared by a Security Auditor. | |||
| * **To Review** - set automatically when a developer requests a security auditor to Review the fix she has done on a Manual Vulnerability | |||
| * **Reopened** - set when a developer Dismisses an Open Manual Vulnerability or when a Security Auditor manually reopens issues in order to run a new audit on already Resolved issues | |||
| Security Hotspot issues are only ever closed if the code containing the Security Hotspot is deleted. A Security Hotspot may also become Removed if the rule which identified the hotspot is removed from the project's Quality Profile. | |||
| ## Understanding which Issues are "New" | |||
| To determine the creation date of an issue, an algorithm is executed during each analysis to determine whether an issue is new or existed previously. This algorithm relies on line content hashes (excluding whitespace) the issue is reported on. For multi-line issues, the hash of the first line is used. For each file (after detection of file renaming), the algorithm takes the base list of issues from the previous analysis, and tries to match those issues with the raw issue list reported by the new analysis. The algorithm tries to first match using the strongest evidence, and then falls back to weaker heuristics. | |||
| * if the issue is on the same rule, with the same line number and with the same line hash (but not necessarily with the same message) > MATCH | |||
| * detect block move inside file, then if the issue is on the same (moved) line and on the same rule (but not necessarily with the same message) > MATCH | |||
| * on the same rule, with the same message and with the same line hash (but not necessarily with the same line) > MATCH | |||
| * on the same rule, with the same message and with the same line number (but not necessarily with the same line hash) > MATCH | |||
| * on the same rule and with the same line hash (but not the same message and not the same line) > MATCH | |||
| * is there a matching **CLOSED** issue > MATCH and Reopen | |||
| Unmatched "base" issues are closed as fixed. | |||
| Unmatched "raw" issues are new. | |||
| ## Automatic Issue Assignment | |||
| ### For Bug, Vulnerability and Code Smell | |||
| New issues are automatically assigned during analysis to the last committer on the issue line if the committer can be correlated to a {instance} user. Note that currently, issues on any level above a file, e.g. directory / project, cannot be automatically assigned. | |||
| ### For Security Hotspot | |||
| Issues are automatically assigned only when the Security Hotspot is transformed into a Vulnerability through the "Detect" action. | |||
| ### User Correlation | |||
| Login and email correlations are made automatically. I.e. if the user commits with her email address and that email address is part of her {instance} profile, then new issues raised on lines where she was the last committer will be automatically assigned to her. | |||
| Additional correlations can be made manually in the user's profile (see "SCM accounts" in Authorization for more). | |||
| ### Known Limitation | |||
| If the SCM login associated with an issue is longer than 255 characters allowed for an issue author, the author will be left blank. | |||
| ## Issue edits | |||
| {instance}'s issues workflow can help you manage your issues. There are seven different things you can do to an issue (other than fixing it in the code!): Comment, Assign, Confirm, Change Severity, Resolve, Won't Fix, and False Positive. | |||
| These actions break out into three different categories. First up is the "technical review" category. | |||
| ### Technical Review | |||
| The Confirm, False Positive, Won't Fix, Severity change, and Resolve actions all fall into this category, which presumes an initial review of an issue to verify its validity. Assume it's time to review the technical debt added in the last review period - whether that's a day, a week, or an entire sprint. You go through each new issue and do one: | |||
| * **Confirm** - By confirming an issue, you're basically saying "Yep, that's a problem." Doing so moves it out of "Open" status to "Confirmed". | |||
| * **False Positive** - Looking at the issue in context, you realize that for whatever reason, this issue isn't actually a problem. So you mark it False Positive and move on. Requires Administer Issues permission on the project. | |||
| * **Won't Fix** - Looking at the issue in context, you realize that while it's a valid issue it's not one that actually needs fixing. In other words, it represents accepted technical debt. So you mark it Won't Fix and move on. Requires Administer Issues permission on the project. | |||
| * **Severity change** - This is the middle ground between the first two options. Yes, it's a problem, but it's not as bad a problem as the rule's default severity makes it out to be. Or perhaps it's actually far worse. Either way, you adjust the severity of the issue to bring it in line with what you feel it deserves. Requires Administer Issues permission on the project. | |||
| * **Resolve** - If you think you've fixed an open issue, you can Resolve it. If you're right, the next analysis will move it to closed status. If you're wrong, its status will go to re-opened. | |||
| Additionally, Security Hotspots allow the following: | |||
| * **Detect** - Confirms a Security Hotspot as a true issue and manually opens a Vulnerability. Requires Administer Security Hotspots on the project. | |||
| * **Clear** - Marks a Security Hotspot or manually opened Vulnerability as being without issue and shouldn't be fixed. Requires Administer Security Hotspots on the project. | |||
| * **Request Review** - Request that a Security Auditor review changes made to remediate a manually opened Vulnerability. | |||
| * **Reject** - After review ,reject the remediation for a manually opened Vulnerability and return it to an open issue. Requires Administer Security Hotspots on the project. | |||
| If you tend to mark a lot of issues False Positive or Won't Fix, it means that some coding rules are not appropriate for your context. So, you can either completely deactivate them in the quality profile or use issue exclusions to narrow the focus of the rules so they are not used on specific parts (or types of object) of your application. Similarly, making a lot of severity changes should prompt you to consider updating the rule severities in your profiles. | |||
| As you edit issues, the related metrics (e.g. New Bugs), will update automatically, as will the Quality Gate status if it's relevant. | |||
| ### Dispositioning | |||
| Once issues have been through technical review, it's time to decide who's going to deal them. By default they're assigned to the last committer on the issue line (at the time the issue is raised), but you can certainly reassign them to yourself or someone else. The assignee will receive email notification of the assignment if he signed up for notifications, and the assignment will show up everywhere the issue is displayed, including in the My Issues list in the My Account space. | |||
| ### General | |||
| At any time during the lifecycle of an issue, you can log a comment on it. Comments are displayed in the issue detail in a running log. You have the ability to edit or delete the comments you made. | |||
| You can also edit an issue's tags. Issues inherit the tags of the rules that created them, but the tag set on an issue is fully editable. Tags can be created, added and removed at will for users with the Browse permission on the project. | |||
| Although they are initially inherited from the relevant rule, the tags on an issue are not synchronized with the rule, so adding tags to a rule will not add those tags to the rule's issues. | |||
| ### Bulk Change | |||
| All of these changes and more can be made to multiple issues at once using the Bulk Change option in the issues search results pane. | |||
| ## Purging Closed Issues | |||
| By default, Closed issues are kept for 30 days. For more details, see [Housekeeping](/instance-administration/housekeeping/). | |||
+ 0
- 54
server/sonar-docs/src/pages/user-guide/portfolios.md
View File
| @@ -1,54 +0,0 @@ | |||
| --- | |||
| title: Portfolios | |||
| url: /user-guide/portfolios/ | |||
| --- | |||
| *Portfolios are available as part of the [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html).* | |||
| ### Portfolios Home Page | |||
| The Portfolio Home Page is the central place for managers and tech leads to keep an eye on the Releasability of the projects under their supervision. Releasability is based on the project's quality gate: green or orange (pass or warning) is releasable. Red (error) is not. Each Portfolio home page offers an aggregate view of the releasability of all the projects in the Portfolio. | |||
| At the top of the page, you can easily see whether overall Portfolio is currently rated as releasable and if any projects in the Portfolio have failed their Quality Gate. And the Reliability, Security, and Maintainability ratings show the overall health of the Portfolio in these three domains, along with an indicator of the worst-performing project(s) in each domain. | |||
| For each domain you see: | |||
| * the rating (see Metric Definitions for more details about how they are computed) | |||
| * an indicator of when the rating last changed | |||
| * an indicator of the worst-performing project(s) in the domain | |||
| ### Releasability Rating | |||
| The Releasability Rating tells you the ratio of projects in the Portfolio that do NOT have a **FAILED** Quality Gate (ie QG being **PASSED** or **WARNING**) : | |||
| **A**: > 80% | |||
| **B**: > 60% | |||
| **C**: > 40% | |||
| **D**: > 20% | |||
| **E**: <= 20% | |||
| ### Reliability, Security and Maintainability Ratings | |||
| Each of the Reliability, Security and Maintainability Ratings for a Portfolio is calculated as the average of the ratings for all projects included in the Portfolio. SonarQube converts the rating for each project to a number (see conversion table below), calculates an average for the portfolio and converts that average back to a rating. Averages that land exactly on the 0.5 mark are rounded up (i.e. the result is the "lower" of the two possible ratings, so an average of 2.5 would result in a "C" rating). | |||
| This gives an “issue density" measure on the three axes of Reliability, Security and Maintainability for your Portfolio. | |||
| Rating conversion: | |||
| **E**: 5 | |||
| **D**: 4 | |||
| **C**: 3 | |||
| **B**: 2 | |||
| **A**: 1 | |||
| *Note: the Portfolio Home Page is also available at Sub-Portfolio level* | |||
| ### Print as PDF or Subscribe | |||
| On a Portfolio Home Page you can choose to download an overview of the Portfolio as a PDF. To do that, simply click on the "Print as PDF" button. This is really convenient, for example, if you're going into a meeting where you may not have access to your SonarQube instance. | |||
| If you don't want to perform this action every time, you can subscribe to receive the PDF by email. The frequency of the mailing is decided by the administrator of the Portfolio. | |||
| Please note you will receive the PDF only if the Portfolio is computed. | |||
| Portfolios are created and edited in the global Portfolio administration interface: **Administration > Configuration > Portfolios**. For more information, see [Configuring Portfolios and Applications](/instance-administration/configuring-portfolios-and-applications/). | |||
+ 0
- 56
server/sonar-docs/src/pages/user-guide/project-page.md
View File
| @@ -1,56 +0,0 @@ | |||
| --- | |||
| title: Project Page | |||
| url: /user-guide/project-page/ | |||
| --- | |||
| ## Table of Contents | |||
| The Project Hompepage is the entry point of any project showing: | |||
| * the releasability status of the project | |||
| * the current state of its quality | |||
| * the quality of what has been produced since the beginning of its [New Code Period](/user-guide/fixing-the-water-leak/). | |||
| The Project Page answers two questions: | |||
| * can I release my project today? | |||
| * if not, what should I improve to make the project pass the Quality Gate? | |||
| ## Can I release today? | |||
| Since the [Quality Gate](/user-guide/quality-gates/) is your most powerful tool to enforce your quality policy, the page starts with the project's current Quality Gate status. If the project passes, a simple, green all-clear is shown. | |||
| If not, details and drill-downs are immediately available to quickly identify what went wrong, with a section for each error or warning condition showing what the current project value is and what it should be. As usual, you'll be able to click through on current values to get to drilldowns. | |||
| ## What should I fix first? | |||
| Because the best way to improve a project's quality is to catch and fix new problems before they become entrenched, the first view of a project is centered around the New Code Period, which is highlighted in yellow on the right of the project homepage. The project space page shows a high-level summary of critical metrics, both current values and their New Code Period values. | |||
| Just below the Quality Gate information, you have the numbers of old and new Issues in the Reliability and Security domains and then the Maintainability domain. Clicking on any figure on the page will take you to a detailed view, either in the Measures Page or the Issues Page. | |||
| The most important thing a developer must do is to ensure the new Issues in the yellow part of the screen are acknowledged, reviewed and fixed and to make sure that new code is covered by tests to help prevent future regressions. Regardless of how many Issues were introduced in the past or how little test coverage there is overall, a focus on the newly added Issues will ensure that the situation won't degrade versus the version you previously released in production. | |||
| So, which issues should you go after first: Bugs, Vulnerabilities or Code Smells? It depends, because the answer is dependent on the nature of your Issues. Let's say you have issues for a block of code that is duplicated 5 times, and inside this duplicated block of code, you have 3 Bugs and 5 Security Issues. The best approach is probably to fix the duplication first and then resolve the Bugs and Vulnerabilities in the newly centralized location, rather than fixing them 5 times. | |||
| That's why you need to review your new Issues before jumping into resolving them. | |||
| ## How can I ... | |||
| ### How can I see project measures at a lower level? | |||
| The project-level **Measures** menu item takes you to a dedicated sub-space where you see all project measures. Choose a measure for more details. Both list and tree views are available for each measure, and treemaps are available for percentages and ratings. | |||
| ### How can I see all the issues in a project? | |||
| The project-level **Issues** menu item takes you to a project-specific Issues page, where you can perform all the same actions you can at the higher level. | |||
| On this page, you can easily narrow the list to the New Issues introduced during the New Code Period, by selecting `New Code` in **Creation Date** facet. | |||
| ### How can I see the project structure and code? | |||
| The project-level **Code** menu item takes you to an outline of your project structure. Drill down to see files in a directory, and choose a file to see its code. | |||
| If your project is too large for easy exploration via drilling, the search feature on this page will help. While the global search in the main menu returns results from throughout the {instance} instance, the localized search on the code page is restricted to files and directories in the current project. | |||
| ### How can I see the project activity / history? | |||
| The project-level **Activity** menu item takes you to the full list of code scans performed on your project since it was created in {instance}. By going there you can follow the evolution of the Quality Gate, see the changes of Quality Profiles and know when a given version of your code has been scanned. | |||
| ### How can I easily spot the risks in a project? | |||
| Visualizations allow you to compare project components and quickly spot the ones that represent the greatest risks. The **Activity** page offers several pre-defined visualizations, and you can also create Custom visualizations with the metrics of your choice. | |||
| ### How can I promote the health of my project to peers ? | |||
| If your project is publicly visible, then you can further promote its status in external tools and websites using native Project Badges. The **Get project badges** button on the homepage of a public project lets you choose/fine-tune your badge and gives you the URL for it. | |||
+ 0
- 138
server/sonar-docs/src/pages/user-guide/rules.md
View File
| @@ -1,138 +0,0 @@ | |||
| --- | |||
| title: Rules | |||
| url: /user-guide/rules/ | |||
| --- | |||
| ## Table of Contents | |||
| ## Overview | |||
| In SonarQube, analyzers contribute rules which are executed on source code to generate issues. There are four types of rules: | |||
| * Code Smell (Maintainability domain) | |||
| * Bug (Reliability domain) | |||
| * Vulnerability (Security domain) | |||
| * Security Hotspot (Security domain) | |||
| For Code Smells and Bugs, zero false-positives are expected. At least this is the target so that developers don't have to wonder if a fix is required. | |||
| For Vulnerabilities, the target is to have more than 80% of the issues to be true-positives. | |||
| Security Hotspot rules are purposefully designed to draw attention to code is security-sensitive. It is expected that more than 80% of the issues will be quickly resolved as "Won't Fix" after review by a Security Auditor. | |||
| The Rules page is the entry point where you can discover all the existing rules or create new ones based on provided templates. | |||
| ## Rules | |||
| By default, when entering the top menu item "Rules", you will see all the available rules brought by the analyzers installed on your SonarQube instance. You have the ability to narrow the selection based on search criteria in the left pane: | |||
| * **Language**: the language to which a rule applies. | |||
| * **Type**: Bug, Vulnerability, Code Smell or Security Hotspot rules. | |||
| * **Tag**: it is possible to add tags to rules in order to classify them and to help discover them more easily. | |||
| * **Repository**: the engine/analyzer that contributes rules to SonarQube. | |||
| * **Default Severity**: the original severity of the rule - as defined by the analyzer that contributes this rule. | |||
| * **Status**: rules can have 3 different statuses: | |||
| * **Beta**: The rule has been recently implemented and we haven't gotten enough feedback from users yet, so there may be false positives or false negatives. | |||
| * **Deprecated**: The rule should no longer be used because a similar, but more powerful and accurate rule exists. | |||
| * **Ready**: The rule is ready to be used in production. | |||
| * **Available Since**: date when a rule was first added on the SonarQube instance. This is useful to list all the new rules since the last upgrade of a plugin for instance. | |||
| * **Template**: display rule templates that allow to create custom rules (see later on this page). | |||
| * **Quality Profile**: inclusion in or exclusion from a specific profile | |||
| If a quality profile is selected, it is also possible to check for its active severity and whether it is inherited or not. See the Quality Profile documentation for more. | |||
| ## Rule Details | |||
| To see the details of a rule, either click on it, or use the right arrow key. Along with basic rule data, you'll also be able to see which, if any, profiles it's active in and how many open issues have been raised with it. | |||
| The 2 following actions are available only if you have the right permissions ("Administer Quality Profiles and Gates"): | |||
| * **Add/Remove Tags**: | |||
| * It is possible to add existing tags on a rule, or to create new ones (just enter a new name while typing in the text field). | |||
| * Note that some rules have built-in tags that you cannot remove - they are provided by the plugins which contribute the rules. | |||
| * **Extend Description**: | |||
| * Extending rule descriptions is useful to let users know how your organization is using a particular rule for instance or to give more insight on a rule. | |||
| * Note that the extension will be available to non-admin users as a normal part of the rule details. | |||
| <!-- sonarqube --> | |||
| ## Rule Templates and Custom Rules | |||
| Rule Templates are provided by plugins to allow users to define their own rules in SonarQube. For instance, the template "Architectural Constraint" can be used to create any kind of rule that checks forbidden access from a set of file to another set of files. | |||
| Rule templates are like cookie cutters from which you can stamp out new, "custom rules". To find templates, use the template facet: | |||
|  | |||
| To create a custom rule from a template, you will have to fill the following information: | |||
| * Name | |||
| * Key (auto-suggested) | |||
| * Description (Markdown format is supported) | |||
| * Default Severity | |||
| * Status | |||
| * The parameters specified by the template | |||
| It's easy to navigate from a template to the custom rules defined from it: just click on the link in the "Custom Rules" section and you will end up on the details of the given rule. | |||
|  | |||
| ### Custom Rules | |||
| Custom Rules are considered like any other rule, except that they can be fully edited or even deleted: | |||
|  | |||
| Note that when deleting a custom rule, it is not physically removed from the SonarQube instance but rather its status is set to "REMOVED". This allows current or old issues related to this rule to be displayed properly in SonarQube until they are fully removed. | |||
| ## Extending Coding Rules | |||
| Custom coding rules can be added. See [Adding Coding Rules](https://docs.sonarqube.org/display/DEV/Adding+Coding+Rules) for detailed information and tutorials. | |||
| <!-- sonarqube --> | |||
| ## Rule Types and Severities | |||
| ### How are rules categorized? | |||
| The SonarQube Quality Model divides rules into four categories: Bugs, Vulnerabilities, Security Hotspots and Code Smells. Rules are assigned to categories based on the answers to these questions: | |||
| **Is the rule about code that is demonstrably wrong, or more likely wrong than not?** | |||
| If the answer is "yes", then it's a Bug rule. | |||
| If not... | |||
| **Is the rule about code that could be exploited by a hacker?** | |||
| If so, then it's a Vulnerability rule. | |||
| If not... | |||
| **Is the rule about code that is security-sensitive?** | |||
| If so, then it's a Security Hotspot rule. | |||
| If not... | |||
| **Is the rule neither a Bug nor a Vulnerability?** | |||
| If so, then it's a Code Smell rule. | |||
| ## How are severities assigned? | |||
| To assign severity to a rule, we ask a further series of questions. The first one is basically: | |||
| **What's the worst thing that could happen?** | |||
| In answering this question, we try to factor in Murphy's Law without predicting Armageddon. | |||
| Then we assess whether the impact and likelihood of the Worst Thing (see _How are severity and likelihood decided?_, below) are high or low, and plug the answers into a truth table: | |||
| | | Impact | Likelihood | | |||
| | -------- | ---------------------- | ---------------------- | | |||
| | Blocker |  |  | | |||
| | Critical |  |  | | |||
| | Major |  |  | | |||
| | Minor |  |  | | |||
| ## How are severity and likelihood decided? | |||
| To assess the severity of a rule, we start from the Worst Thing (see _How are severities assigned?_, above) and ask category-specific questions. | |||
| ### Bugs | |||
| Impact: **Could the Worst Thing cause the application to crash or to corrupt stored data?** | |||
| Likelihood: **What's the probability that the Worst Thing will happen?** | |||
| ### Vulnerabilities | |||
| Impact: **Could the exploitation of the Worst Thing result in significant damage to your assets or your users?** | |||
| Likelihood: **What is the probability that a hacker will be able to exploit the Worst Thing?** | |||
| ### Security Hotspots | |||
| Security Hotspots are not assigned severities as it is unknown whether there is truly an issue until review by a Security Auditor. When an auditor converts a Security Hotspot into a Vulnerability, severity is assigned based on the identified Vulnerability (see above). | |||
+ 0
- 3
server/sonar-docs/src/pages/user-guide/security-reports.md
View File
| @@ -16,9 +16,6 @@ Security Hotspots are security-sensitive pieces of code that should be carefully | |||
| The main goal of Security Hotspots is to help focus the efforts of the security auditors who manually review application source code. The second goal is to educate developers and to increase their security-awareness. | |||
| Having a Hotspot in your application does not mean there is a problem. What it does mean is that a human, preferably a security auditor/expert should look over the code to see if the sensitive piece of code is being used in the safest manner. | |||
| ## Why are some Hotspot and Vulnerability rules very similar? | |||
| They are overlapping on purpose. The Hotspot rule is supposed to include all matches of the Vulnerability rules, and cases where the taint analysis engine is not able to detect vulnerabilities. For example, switching from one language to another (XML, JNI, etc...) or using some third party libraries will prevent the taint analysis from finding vulnerabilities. A Vulnerability rule highlights security threats only when it has a high level of confidence, which means that it will always miss some of them. Whereas a Hotspot rule guides secure code reviews by showing code where those issues might lurk, even if it could not detect any vulnerability. | |||
| ## Why don't I see any Hotspots? | |||
| They are three reasons you might not see any Hotspots: | |||
| * it is possible you really have none of them because the code has been written without using any security-sensitive API. | |||
+ 0
- 59
server/sonar-docs/src/pages/user-guide/security-rules.md
View File
| @@ -1,59 +0,0 @@ | |||
| --- | |||
| title: Security-related Rules | |||
| url: /user-guide/security-rules/ | |||
| --- | |||
| The {instance} Quality Model has three different types of rules: Reliability (bug), Vulnerability (security), and Maintainability (code smell) rules. But divided another way, there are only two types: security rules, and all the rest. The distinction between these two groups is not so much in what they catch but in where they come from and in the standards imposed on them. | |||
| ## What to expect from security-related rules | |||
| To be clear, the standard for most rules implemented in {instance} language plugins is very strict: no false positives. For normal rules, you should be able to be confident that whatever is reported to you as an issue really is an issue. | |||
| But for security-related rules, the story is a little different. For instance, a lot of security guidelines talk about how "sensitive" data should be handled (e.g. not logged, not stored un-encrypted, &etc.). But since it's not really possible in a rule to tell which data is sensitive and which isn't, the choice becomes: maintain the no-false-positives standard and don't implement security-related rules, or implement security-related rules with a different standard. | |||
| That's why security-related rules cast a wider net than you may be used to seeing. The idea is that the rule will flag anything suspicious, and leave it to the human security auditor to cull the false positives and sent the real issues for remediation. | |||
| Security Hotspots are a special type of issue that identify sensitive areas of code that should be reviewed by a Security Auditor to determine if they are truly Vulnerabilities. See Security Audits and Reports for detail on Security Hotspots and the audit process. | |||
| ## Where security-related rules come from | |||
| The vast majority of security-related rules originate from established standards: [CWE](http://cwe.mitre.org/), [SANS Top 25](http://www.sans.org/top25-software-errors/), and [OWASP Top 10](https://www.owasp.org/index.php/Top_10-2017_Top_10). To find rules that relate to any of these standards, you can search rules either by tag or by text. The standards that a rule relates to will be listed in the **See** section at the bottom of the rule description. | |||
| ### CWE | |||
| CWE stands for Common Weakness Enumeration. According to the [CWE FAQ](http://cwe.mitre.org/about/faq.html#A.1): | |||
| > Common Weakness Enumeration (CWE™) is a formal list or dictionary of common software weaknesses that can occur in software's architecture, design, code or implementation that can lead to exploitable security vulnerabilities. CWE was created to serve as a common language for describing software security weaknesses; serve as a standard measuring stick for software security tools targeting these weaknesses; and to provide a common baseline standard for weakness identification, mitigation, and prevention efforts. | |||
| The CWE is a hierarchy of weakness descriptions. The lowest level in the hierarchy is a "Weakness Base", which describes a granular weakness. Above Weakness Bases, are Weakness Classes and Categories. In general, rules are linked to Weakness Bases or Classes. | |||
| Tools which meet certain requirements can be certified as [CWE Compatible](http://cwe.mitre.org/compatible/). Those requirements are: | |||
| * You must be able to search for CWE-related rules using a CWE identifier. To do so in the {instance} platform, simply drop the CWE identifier (e.g. CWE-595) in the search text input on the rules page and run the search. | |||
| * Rules must be accurately linked to their related CWE items. To see the CWE mapping for a {instance} rule, consult the rule's See section at the bottom of the rule description. | |||
| * You must be able to identify the relevant CWE from an Issue. To do so in the {instance} platform, consult the related rule. | |||
| * The product documentation must include a description of CWE and CWE Compatibility. | |||
| * The version of CWE supported must be listed. The {instance} langauge plugins support version 2.8. | |||
| * In addition to searching rules by CWE id's, you can also search by the "cwe" rule tag. | |||
| To see which CWE items are covered for a language, consult the links below. | |||
| * [C](https://rules.sonarsource.com/c/tag/cwe)/[C++](https://rules.sonarsource.com/cpp/tag/cwe) | |||
| * [Java](https://rules.sonarsource.com/java/tag/cwe) | |||
| * [Objective-C](https://rules.sonarsource.com/objective-c/tag/cwe) | |||
| ### SANS Top 25 | |||
| The [SANS Top 25](http://www.sans.org/top25-software-errors/) list is a collection of the 25-most dangerous errors listed in the CWE, as compiled by the [SANS organization](http://www.sans.org/). The current SANS list is divided into three categories: Insecure Interaction Between Components, Risky Resource Management, and Porous Defenses. | |||
| The tags used for SANS correspond to its categories: sans-top25-insecure, sans-top25-risky, sans-top25-porous. | |||
| To find rules relating to SANS Top 25, you can perform a text search for the category, or the relevant CWE item, or perform a rule tag search. | |||
| ### OWASP Top 10 | |||
| OWASP stands for Open Web Application Security Project. According to its site, it is: | |||
| > A [501(c)(3)](http://www.irs.gov/Charities-&-Non-Profits/Charitable-Organizations/Exemption-Requirements-Section-501(c)(3)-Organizations) worldwide not-for-profit charitable organization focused on improving the security of software. Our mission is to make software security [visible](https://www.owasp.org/index.php/Category:OWASP_Video), so that ]individuals and organizations](https://www.owasp.org/index.php/Industry:Citations) worldwide can make informed decisions about true software security risks. | |||
| The [OWASP Top 10](https://www.owasp.org/index.php/Top_10-2017_Top_10) is a list of broad categories of weaknesses, each of which can map to many individual rules. | |||
| The tags used for OWASP correspond to the weakness categories: owasp-a1, owasp-a2, owasp-a3, owasp-a4, owasp-a5, owasp-a6, owasp-a7, owasp-a8, owasp-a9, owasp-a10. | |||
| To find rules relating to OWASP Top 10, you can perform a text search for the category, or perform a rule tag search. | |||
+ 0
- 21
server/sonar-docs/src/pages/user-guide/user-token.md
View File
| @@ -1,21 +0,0 @@ | |||
| --- | |||
| title: User Token | |||
| url: /user-guide/user-token/ | |||
| --- | |||
| Each user has the ability to generate tokens that can be used to run analyses or invoke web services without access to the user's actual credentials. | |||
| ## How to Generate a Token | |||
| To generate a token, to go User > My Account > Security. Your existing tokens are listed here, each with a Revoke button. | |||
| The form at the bottom of the page allows you to generate new tokens. Once you click the generate button, you will see the token value. Copy it immediately; once you dismiss the notification you will not be able to retrieve it. | |||
| ## How to Use a Token | |||
| User tokens have to be used as a replacement of your usual login: | |||
| * when running analyses on your code: replace your login by the token in the sonar.login property. | |||
| * when invoking web services: just pass the token instead of your login while doing the basic authentication. | |||
| In both cases, you don't need to provide a password (so when running analyses on your code, the property sonar.password is optional). | |||
+ 15
- 37
server/sonar-docs/static/SonarCloudNavigationTree.json
View File
| @@ -1,29 +1,23 @@ | |||
| [ | |||
| { | |||
| "title": "Getting Started", | |||
| "children": [ | |||
| "/analyze-a-project/" | |||
| ] | |||
| }, | |||
| { | |||
| "title": "Integrations", | |||
| "children": [ | |||
| "/integrations/bitbucketcloud/", | |||
| "/integrations/github/", | |||
| "/integrations/vsts/" | |||
| ] | |||
| }, | |||
| "/privacy/", | |||
| "/security/", | |||
| "/sonarcloud-pricing/", | |||
| "/analyze-a-project/", | |||
| { | |||
| "title": "Analyzing Source Code", | |||
| "children": [ | |||
| "/analysis/overview/", | |||
| "/analysis/analysis-parameters/", | |||
| "/analysis/background-tasks/", | |||
| "/analysis/generic-issue/", | |||
| "/analysis/generic-test/", | |||
| "/analysis/pull-request/" | |||
| "/analysis/pull-request/", | |||
| "/analysis/scm-integration/" | |||
| ] | |||
| }, | |||
| { | |||
| "title": "Integrations", | |||
| "children": ["/integrations/bitbucketcloud/", "/integrations/github/", "/integrations/vsts/"] | |||
| }, | |||
| { | |||
| "title": "Branches", | |||
| "children": [ | |||
| @@ -37,40 +31,24 @@ | |||
| "title": "User Guide", | |||
| "children": [ | |||
| "/user-guide/fixing-the-water-leak/", | |||
| "/user-guide/project-page/", | |||
| "/user-guide/issues/", | |||
| "/user-guide/rules/", | |||
| "/user-guide/security-rules/", | |||
| "/user-guide/built-in-rule-tags/", | |||
| "/user-guide/keyboard-shortcuts/", | |||
| "/user-guide/quality-gates/", | |||
| "/instance-administration/quality-profiles/", | |||
| "/user-guide/metric-definitions/", | |||
| "/user-guide/security-reports/", | |||
| "/user-guide/user-account/", | |||
| "/user-guide/keyboard-shortcuts/" | |||
| "/user-guide/user-account/" | |||
| ] | |||
| }, | |||
| { | |||
| "title": "Project Admin Guide", | |||
| "children": [ | |||
| "/project-administration/webhooks/", | |||
| "/project-administration/narrowing-the-focus/" | |||
| ] | |||
| "title": "Project Administration", | |||
| "children": ["/project-administration/webhooks/"] | |||
| }, | |||
| { | |||
| "title": "Organization Admin Guide", | |||
| "title": "Organizations", | |||
| "children": [ | |||
| "/organizations/overview/", | |||
| "/organizations/manage-team/", | |||
| "/organizations/organization-visibility/" | |||
| ] | |||
| }, | |||
| { | |||
| "title": "Appendices", | |||
| "children": [ | |||
| "/sonarcloud-pricing/", | |||
| "/privacy/", | |||
| "/security/" | |||
| ] | |||
| } | |||
| ] | |||
+ 4
- 33
server/sonar-docs/static/SonarQubeNavigationTree.json
View File
| @@ -1,17 +1,8 @@ | |||
| [ | |||
| { | |||
| "title": "Requirements", | |||
| "children": [ | |||
| "/requirements/requirements/", | |||
| "/requirements/benchmark/", | |||
| "/requirements/hardware-recommendations/" | |||
| ] | |||
| }, | |||
| { | |||
| "title": "Analyzing Source Code", | |||
| "children": [ | |||
| "/analysis/overview/", | |||
| "/analysis/analysis-parameters/", | |||
| "/analysis/background-tasks/", | |||
| "/analysis/generic-issue/", | |||
| "/analysis/generic-test/", | |||
| @@ -32,44 +23,24 @@ | |||
| "title": "User Guide", | |||
| "children": [ | |||
| "/user-guide/fixing-the-water-leak/", | |||
| "/user-guide/project-page/", | |||
| "/user-guide/applications/", | |||
| "/user-guide/portfolios/", | |||
| "/user-guide/issues/", | |||
| "/user-guide/rules/", | |||
| "/user-guide/security-rules/", | |||
| "/user-guide/built-in-rule-tags/", | |||
| "/user-guide/keyboard-shortcuts/", | |||
| "/user-guide/quality-gates/", | |||
| "/user-guide/metric-definitions/", | |||
| "/user-guide/security-reports/", | |||
| "/user-guide/user-account/", | |||
| "/user-guide/keyboard-shortcuts/" | |||
| "/user-guide/user-account/" | |||
| ] | |||
| }, | |||
| { | |||
| "title": "Project Administration", | |||
| "children": [ | |||
| "/project-administration/project-existence/", | |||
| "/project-administration/managing-project-history/", | |||
| "/project-administration/narrowing-the-focus/", | |||
| "/project-administration/portfolio-pdf-configuration/", | |||
| "/project-administration/project-settings/", | |||
| "/project-administration/webhooks/" | |||
| ] | |||
| "children": ["/project-administration/webhooks/"] | |||
| }, | |||
| { | |||
| "title": "Instance Administration", | |||
| "children": [ | |||
| "/instance-administration/configuring-portfolios-and-applications/", | |||
| "/instance-administration/custom-measures/", | |||
| "/instance-administration/git-integration/", | |||
| "/instance-administration/project-move/", | |||
| "/instance-administration/housekeeping/", | |||
| "/instance-administration/look-and-feel/", | |||
| "/instance-administration/quality-profiles/", | |||
| "/instance-administration/security/", | |||
| "/instance-administration/delegated-auth/", | |||
| "/instance-administration/system-info/" | |||
| "/instance-administration/quality-profiles/" | |||
| ] | |||
| } | |||
| ] | |||
+ 6
- 57
server/sonar-docs/static/StaticNavigationTree.json
View File
| @@ -1,37 +1,16 @@ | |||
| [ | |||
| { | |||
| "title": "Architecture and Integration", | |||
| "children": [ | |||
| "/architecture/architecture-integration/" | |||
| ] | |||
| }, | |||
| { | |||
| "title": "Requirements", | |||
| "children": [ | |||
| "/requirements/requirements/", | |||
| "/requirements/benchmark/", | |||
| "/requirements/hardware-recommendations/" | |||
| ] | |||
| "children": [] | |||
| }, | |||
| { | |||
| "title": "Setup and Upgrade", | |||
| "children": [ | |||
| "/setup/overview/", | |||
| "/setup/get-started-2-minutes/", | |||
| "/setup/install-server/", | |||
| "/setup/operate-server/", | |||
| "/setup/install-plugin/", | |||
| "/setup/install-cluster/", | |||
| "/setup/upgrading/", | |||
| "/setup/upgrade-notes/", | |||
| "/setup/troubleshooting/" | |||
| ] | |||
| "children": [] | |||
| }, | |||
| { | |||
| "title": "Analyzing Source Code", | |||
| "children": [ | |||
| "/analysis/overview/", | |||
| "/analysis/analysis-parameters/", | |||
| "/analysis/background-tasks/", | |||
| "/analysis/generic-issue/", | |||
| "/analysis/generic-test/", | |||
| @@ -52,54 +31,24 @@ | |||
| "title": "User Guide", | |||
| "children": [ | |||
| "/user-guide/fixing-the-water-leak/", | |||
| "/user-guide/project-page/", | |||
| "/user-guide/applications/", | |||
| "/user-guide/portfolios/", | |||
| "/user-guide/issues/", | |||
| "/user-guide/rules/", | |||
| "/user-guide/security-rules/", | |||
| "/user-guide/built-in-rule-tags/", | |||
| "/user-guide/keyboard-shortcuts/", | |||
| "/user-guide/quality-gates/", | |||
| "/user-guide/metric-definitions/", | |||
| "/user-guide/security-reports/", | |||
| "/user-guide/user-account/", | |||
| "/user-guide/keyboard-shortcuts/" | |||
| "/user-guide/user-account/" | |||
| ] | |||
| }, | |||
| { | |||
| "title": "Project Administration", | |||
| "children": [ | |||
| "/project-administration/project-existence/", | |||
| "/project-administration/managing-project-history/", | |||
| "/project-administration/narrowing-the-focus/", | |||
| "/project-administration/portfolio-pdf-configuration/", | |||
| "/project-administration/project-settings/", | |||
| "/project-administration/webhooks/" | |||
| ] | |||
| "children": ["/project-administration/webhooks/"] | |||
| }, | |||
| { | |||
| "title": "Instance Administration", | |||
| "children": [ | |||
| "/instance-administration/configuring-portfolios-and-applications/", | |||
| "/instance-administration/custom-measures/", | |||
| "/instance-administration/git-integration/", | |||
| "/instance-administration/project-move/", | |||
| "/instance-administration/housekeeping/", | |||
| "/instance-administration/look-and-feel/", | |||
| "/instance-administration/quality-profiles/", | |||
| "/instance-administration/security/", | |||
| "/instance-administration/delegated-auth/", | |||
| "/instance-administration/system-info/" | |||
| "/instance-administration/quality-profiles/" | |||
| ] | |||
| }, "/previous-versions/" | |||
| , { | |||
| "title": "Scanners", | |||
| "url": "https://docs.sonarqube.org/display/SCAN" | |||
| }, { | |||
| "title": "Plugins", | |||
| "url": "https://docs.sonarqube.org/display/PLUG" | |||
| }, { | |||
| "title": "Extension", | |||
| "url": "https://docs.sonarqube.org/display/DEV" | |||
| } | |||
| ] | |||
Loading…