пре 3 година · ddcc6985db
--- a/server/sonar-docs/src/pages/analysis/branch-pr-analysis-overview.md
+++ b/server/sonar-docs/src/pages/analysis/branch-pr-analysis-overview.md
@@ -5,23 +5,23 @@ url: /analysis/branch-pr-analysis-overview/

 _Merge and Pull Request analysis is available as part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html) and [above](https://www.sonarsource.com/plans-and-pricing/)._

 SonarScanners running in GitLab CI/CD and Jenkins can automatically detect branches and Merge or Pull Requests by using environment variables set in the jobs.
 SonarScanners running in GitLab CI/CD, Cirrus CI, and Jenkins with a Branch Source plugin configured can automatically detect branches and merge or pull requests by using environment variables set in the jobs.

 [[warning]]
 | This automatic configuration is disabled if any Branch or Pull Request properties have been set manually.
 | Automatic configuration is disabled if any branch or pull request properties have been set manually.

 ## Keeping your "master" branch history when upgrading from Community Edition to a commercial edition

 In Community Edition, your analyzed branch is named "master" by default. 

 When upgrading to a current commercial edition version, automatic branch and Pull Request configuration creates branches based on their names in your code repository. If the name of your Main Branch (master) in SonarQube doesn't match the branch's name in your code repository, the history of your Main Branch won't be taken on by the branch you analyze. 
 When upgrading to a current commercial edition version, automatic branch and pull request configuration creates branches based on their names in your code repository. If the name of your Main Branch (master) in SonarQube doesn't match the branch's name in your code repository, the history of your Main Branch won't be taken on by the branch you analyze. 

 **Before running analysis**, you can keep your branch history by renaming the Main Branch in SonarQube with the name of the branch in your code repository at **Project Settings > Branches and Pull Requests**. 

 For example, if your Main Branch is named "master" in SonarQube but "develop" in your code repository, rename your Main Branch "develop" in SonarQube.

 ## GitLab CI/CD
 - For GitLab CI/CD configuration, see [GitLab CI/CD](/analysis/gitlab-cicd/).
 - For GitLab CI/CD configuration, see the [GitLab ALM integration](/analysis/gitlab-integration/) page.

 ## Jenkins
 - For Jenkins configuration, see [Jenkins](/analysis/jenkins/).
--- a/server/sonar-docs/src/pages/analysis/gitlab-cicd.md
+++ b/server/sonar-docs/src/pages/analysis/gitlab-cicd.md
@@ -1,115 +0,0 @@
 ---
 title: GitLab CI/CD
 url: /analysis/gitlab-cicd/
 ---
 _Merge Request analysis is available starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html)._

 SonarScanners running in GitLab CI/CD jobs can automatically detect branches or Merge Requests being built so you don't need to specifically pass them as parameters to the scanner.

 [[warning]]
 | You need to disable git shallow clone to make sure the scanner has access to all of your history when running analysis with GitLab CI/CD. For more information, see [Git shallow clone](https://docs.gitlab.com/ee/user/project/pipelines/settings.html#git-shallow-clone).

 ## Activating builds  
 Set up your build according to your SonarQube edition as described below.

 ### Community Edition
 Because Community Edition doesn't support multiple branches, you should only analyze your main branch. You can restrict analysis to your main branch by adding the branch name to the `only` parameter.

 ### Developer Edition and above
 By default, GitLab will build all branches but not Merge Requests. To build Merge Requests, you need to update the `.gitlab-ci.yml` file by adding `merge_requests` to the `only` parameter. See the example configurations below for more information.

 ## Analyzing your repository

 ### Setting environment variables 
 You can set environment variables securely for all pipelines in GitLab's settings. See [Creating a Custom Environment Variable](https://docs.gitlab.com/ee/ci/variables/#creating-a-custom-environment-variable) for more information.
 
 You need to set the following environment variables in GitLab for analysis:
 
 - `SONAR_TOKEN` – Generate a SonarQube [token](/user-guide/user-token/) for GitLab and create a custom environment variable in GitLab with `SONAR_TOKEN` as the **Key** and the token you generated as the **Value**. 

 - `SONAR_HOST_URL` – Create a custom environment variable with `SONAR_HOST_URL` as the **Key** and your SonarQube server URL as the **Value**.

 ### Configuring your `gitlab-ci.yml` file
 The following examples show you how to configure your GitLab CI/CD `gitlab-ci.yml` file. 

 In the following examples, the `allow_failure` parameter allows a job to fail without impacting the rest of the CI suite.

 Click your scanner below to expand the example configuration:

 [[collapse]]
 | ## SonarScanner for Gradle
 | ```
 | sonarqube-check:
 |   image: gradle:jre11-slim
 |   variables:
 |     SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
 |     GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
 |   cache:
 |     key: "${CI_JOB_NAME}"
 |     paths:
 |       - .sonar/cache
 |   script: gradle sonarqube -Dsonar.qualitygate.wait=true
 |   allow_failure: true
 |   only:
 |     - merge_requests
 |     - master
 |     - develop
 | ```
 
 [[collapse]]
 | ## SonarScanner for Maven
 | 
 | ```
 | sonarqube-check:
 |   image: maven:3.6.3-jdk-11
 |   variables:
 |     SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
 |     GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
 |   cache:
 |     key: "${CI_JOB_NAME}"
 |     paths:
 |       - .sonar/cache
 |   script:
 |     - mvn verify sonar:sonar -Dsonar.qualitygate.wait=true
 |   allow_failure: true
 |   only:
 |     - merge_requests
 |     - master
 |     - develop
 | ```

 [[collapse]]
 | ## SonarScanner CLI
 | 
 | ```
 | sonarqube-check:
 |   image:
 |     name: sonarsource/sonar-scanner-cli:latest
 |     entrypoint: [""]
 |   variables:
 |     SONAR_USER_HOME: "${CI_PROJECT_DIR}/.sonar"  # Defines the location of the analysis task cache
 |     GIT_DEPTH: "0"  # Tells git to fetch all the branches of the project, required by the analysis task
 |   cache:
 |     key: "${CI_JOB_NAME}"
 |     paths:
 |       - .sonar/cache
 |   script:
 |     - sonar-scanner -Dsonar.qualitygate.wait=true
 |   allow_failure: true
 |   only:
 |     - merge_requests
 |     - master
 |     - develop
 | ```
 |
 | **Note:** A project key has to be provided through `sonar-project.properties` or through the command line parameter. For more information, see the [SonarScanner](/analysis/scan/sonarscanner/) documentation.

 ### Failing the pipeline job when the SonarQube Quality Gate fails
 In order for the Quality Gate to fail on the GitLab side when the Quality Gate fails on the SonarQube side, the scanner needs to wait for the SonarQube Quality Gate status. To enable this, set the `sonar.qualitygate.wait=true` parameter in the `.gitlab-ci.yml` file. 

 You can set the `sonar.qualitygate.timeout` property to an amount of time (in seconds) that the scanner should wait for a report to be processed. The default is 300 seconds. 

 See the example configurations below for more information.

 ## For more information
 For more information on configuring your build with GitLab CI/CD, see the [GitLab CI/CD Pipeline Configuration Reference](https://gitlab.com/help/ci/yaml/README.md).
--- a/server/sonar-docs/src/pages/analysis/pr-decoration.md
+++ b/server/sonar-docs/src/pages/analysis/pr-decoration.md
@@ -1,179 +0,0 @@
 ---
 title: Decorating Pull Requests
 url: /analysis/pr-decoration/
 ---

 _Pull Request decoration is available starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html)._

 You can add SonarQube analysis and a Quality Gate to your Pull Requests in your ALM provider's interface.

 [[info]]
 | To decorate Pull Requests, a SonarQube analysis needs to be run on your code. You can find the additional parameters required for Pull Request analysis on the [Pull Request Analysis](/analysis/pull-request/) page.

 ## Pull Request Decoration by provider

 Click your ALM provider below to expand the instructions on configuring SonarQube for Pull Request decoration.

 [[collapse]]
 | ## GitHub Enterprise and GitHub.com
 |
 |*Minimum GitHub Enterprise version is 2.15*
 |
 | ### Creating a GitHub App
 |
 | You can add Pull Request decoration under the GitHub **Checks** tab and/or **Conversation** tab. To do this, an instance administrator needs to first create a GitHub App:
 |
 | 1. Follow Steps 1–4 [here](https://developer.github.com/apps/building-github-apps/creating-a-github-app/) to start creating your GitHub App.
 | 1. Under **GitHub App name**, give your app a name, such as SonarQubePRChecks.
 | 1. Add a **Homepage URL**. GitHub requires this, but it isn't important for Pull Request decoration. You can use any URL, such as `https://www.sonarqube.org/`.
 | 1. Enter your **User authorization callback URL**. Set this to your instance's base URL. For example, `yourinstance.sonarqube.com`.
 | 1. Add a **Webhook URL**. Set this to your instance's base URL. For example, `yourinstance.sonarqube.com`.
 | 1. Grant access for the following **Permissions**:
 |
 |	| Permission          | Access       |
 |	|---------------------|--------------|
 |	| Checks              | Read & write |
 |	| **GitHub Enterprise:** Repository metadata <br/> **GitHub.com:** Metadata | Read-only    |
 |	| Pull Requests       | Read & write |
 |	| Commit statuses     | Read-only    |
 |
 | 1. Under "Where can this GitHub App be installed?," select **Any account**.  
 | 2. Click **Create GitHub App**. This will take you to your new GitHub App's page.  
 | 3. Scroll down to the bottom of your app page and click **Generate Private Key**. This downloads a `.pem` file that you'll use in the **Setting your global settings** section.  
 |
 | ### Installing your app 
 |
 | Install your GitHub App from the app's settings page. See the [GitHub instructions](https://developer.github.com/apps/installing-github-apps/) for more information.
 |
 | ### Setting your global settings
 |
 | To set your global settings in SonarQube, navigate to **Administration > Configuration > General Settings > ALM Integrations** and select the **GitHub** tab.
 |
 | From here, set your:
 |
 | - **Configuration Name** – If you're using Enterprise Edition or above, create a configuration name that is succinct and easily recognizable as it will be used at the project level to identify the correct ALM configuration. If you're using Developer Edition, your configuration will be named based on your ALM.
 | - **GitHub URL** – Add the GitHub URL. For example, `https://github.company.com/api/v3` for GitHub Enterprise or `https://api.github.com/` for GitHub.com.
 | - **GitHub App ID** – The App ID is found on your GitHub App's page on GitHub at **Settings > Developer Settings > GitHub Apps**. 
 | - **Client ID** – the Client ID is found below the GitHub App ID on your GitHub App's page.
 | - **Client secret** – the Client secret is found below the Client ID on your GitHub App's page.
 | - **Private Key** – Your GitHub App's private key from the `.pem` file that was generated above in the **Creating a GitHub App** section.
 |
 | ### Setting your project settings
 |
 | #### **Projects imported from a GitHub repository**
 | If you create a project by importing it from a GitHub repository, SonarQube automatically configures your project settings for Pull Request decoration.
 |
 | #### **Manually created projects and existing projects**
 | 
 | If you're creating a new project **Manually** or want to add Pull Request decoration to an existing project, set your project settings at **Project Settings > General Settings > Pull Request Decoration**. 
 |
 | From here, set your: 
 | - **Configuration name** – The configuration name that corresponds to your ALM instance. 
 | - **Repository identifier** – The path of your repository URL.
 |
 | #### **Enable analysis summary under the GitHub Conversation tab**
 | By default, **Enable analysis summary under the GitHub Conversation tab** is on and your Pull Request analysis will be shown under the **Conversation** and **Checks** tabs in GitHub. Turning this setting off will make it so Pull Request analysis is only shown under the **Checks** tab.

 [[collapse]]
 | ## Bitbucket Server
 |
 | *Minimum BitBucket Server version 5.15*
 |
 | A Bitbucket Server user account is used to decorate Pull Requests. We recommend using a dedicated Bitbucket Server account with Administrator permissions. You need a [Personal Access Token](https://confluence.atlassian.com/bitbucketserver0515/personal-access-tokens-961275199.html) from this account with **Write** permission for the repositories that will be analyzed.
 |
 | ### Setting your global settings
 |
 | To set your global settings in SonarQube, navigate to **Administration > Configuration > General Settings > ALM Integrations** and select the **Bitbucket Server** tab.
 |
 | From here, set your:
 |- **Configuration Name** – If you're using Enterprise Edition or above, create a configuration name that is succinct and easily recognizable as it will be used at the project level to identify the correct ALM configuration. If you're using Developer Edition, your configuration will be named based on your ALM.
 | - **Bitbucket Server URL** 
 | - **Personal Access Token** - Token from the account you're using to decorate your Pull Requests.
 |
 | ### Setting your project settings
 |
 | #### **Projects imported from a Bitbucket Server repository**
 |
 | If you create a project by importing it from a Bitbucket server repository, SonarQube automatically configures your project settings for Pull Request decoration. When creating your project, you'll need to provide a personal access token from your user account with `Read` permissions for both projects and repositories. This personal access token will be stored in SonarQube until you revoke it on the Bitbucket Server side.
 |
 | #### **Manually created projects and existing projects**
 |
 | If you create a new project **Manually** or want to add Pull Request decoration to an existing project, you need to set your project settings at **Project Settings > General Settings > Pull Request Decoration**. 
 |
 | From here, set your:
 | - **Configuration name** – The configuration name that corresponds to your ALM instance.
 | - **Project Key** – Part of your BitBucket Server repository URL (.../projects/**{KEY}**/repos/{SLUG}/browse).
 | - **Repo Slug** – Part of your BitBucket Server repository URL (.../projects/{KEY}/repos/**{SLUG}**/browse).
 |
 | ### Blocking Pull Request merges
 |*Blocking Pull Request merges is available starting with version 6.9 of Bitbucket Server*
 |
 | After setting up Pull Request analysis, you can block Pull Requests from being merged if they don't meet your quality standards and the Quality Gate is failing. To do this:
 | 
 | 1. From Bitbucket Server, navigate to **Repository settings > Code Insights**. 
 | 1. Add a Required report called `com.sonarsource.sonarqube`, select **Must pass** as the Required status, and **Must not have any annotations** as the Annotation requirements.

 [[collapse]]
 | ## Azure DevOps Server
 |
 | An Azure DevOps Server user account is used to decorate Pull Requests. We recommend using a dedicated Azure DevOps Server account with Administrator permissions. You need a [personal access token](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=tfs-2017&tabs=preview-page) from this account with the scope authorized for **Code > Read & Write** for the repositories that will be analyzed.
 |
 | To add Pull Request decoration on Azure DevOps Server, you also need to update your global and project settings. 
 |
 | ### Setting your global settings
 |
 | To set your global settings in SonarQube, navigate to **Administration > Configuration > General Settings > ALM Integrations** and select the **Azure DevOps Server** tab.
 |
 | From here, set your:
 | - **Configuration name** – If you're using Enterprise Edition or above, create a configuration name that is succinct and easily recognizable as it will be used at the project level to identify the correct ALM configuration. If you're using Developer Edition, your configuration will be named based on your ALM.
 | - **Personal Access Token** – Token from the account you're using to decorate your Pull Requests.
 |
 | **Note:** Make sure the Configuration name is succinct and easily recognizable as it will be used at the project level to identify the correct ALM configuration.
 |
 | ### Setting your project settings
 |
 | Go to **Project Settings > General Settings > Pull Request Decoration** and select your **Configuration name**.

 [[collapse]]
 | ## GitLab Self-Managed and GitLab.com
 |
 |*For GitLab Self-Managed, the minimum version is 11.7*
 |
 | A GitLab user account is used to decorate Merge Requests. We recommend using a dedicated GitLab account with at least **Reporter** [permissions](https://docs.gitlab.com/ee/user/permissions.html) (the account needs permission to leave comments). You need a personal access token from this account with the scope authorized for **api** for the repositories that will be analyzed.
 |
 | To add Merge Request decoration to GitLab, you also need to update your global and project settings.
 |
 | ### Setting your global settings
 |
 | To set your global settings in SonarQube, navigate to **Administration > Configuration > General Settings > ALM Integrations** and select the **GitLab** tab.  
 |
 | From here, set your:  
 | - **Configuration name** – If you're using Enterprise Edition or above, create a configuration name that is succinct and easily recognizable as it will be used at the project level to identify the correct ALM configuration. If you're using Developer Edition, your configuration will be named based on your ALM.
 | - **GitLab URL** – The GitLab API URL.
 | - **Personal Access Token** – Token from the account you're using to decorate your Pull Requests.
 |
 | **Note:** Make sure the Configuration name is succinct and easily recognizable as it will be used at the project level to identify the correct ALM configuration.
 |
 | ### Setting your project settings
 |
 | #### **Projects imported from a GitLab repository**
 |
 | If you create a project by importing it from a GitLab repository, SonarQube automatically configures your project settings for Merge Request decoration. When creating your project, you'll need to provide a personal access token from your user account with the **read_api** scope. This personal access token will be stored in SonarQube until you revoke it on the GitLab side.
 |
 | #### **Manually created projects and existing projects**
 |
 | If you create a new project **Manually** or want to add Merge Request decoration to an existing project, you need to set your project settings at **Project Settings > General Settings > Pull Request Decoration** and select your GitLab **Configuration name** and provide the GitLab **Project ID**.

 ## Multiple ALM instances

 It's possible to decorate Pull Requests from multiple ALM instances. To do this, you can create a configuration (as shown in the previous section) for each of your ALM instances. That instance configuration can then be assigned to the appropriate projects.

 As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each ALM. 

 As part of [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html) and [above](https://www.sonarsource.com/plans-and-pricing/), you can create multiple configurations for each ALM.

 [[warning]]
 | If you have multiple configurations of the same ALM connected to SonarQube, you cannot create a project by importing it from the ALM and will have to create projects manually.

 ## Issue links
 During pull request decoration, individual issues will be linked to their SonarQube counterparts automatically. However, for this to work correctly, the instance's **Server base URL** (**[Administration > Configuration > General Settings > General > General](/#sonarqube-admin#/admin/settings/)**) must be set correctly. Otherwise, the links will default to `localhost`.
--- a/server/sonar-docs/src/pages/analysis/pull-request.md
+++ b/server/sonar-docs/src/pages/analysis/pull-request.md
@@ -1,5 +1,5 @@
 ---
 title: Overview
 title: Pull Request Analysis
 url: /analysis/pull-request/
 ---

@@ -15,18 +15,22 @@ Pull Request analysis shows your Pull Request's Quality Gate and analysis in the

 Before analyzing your Pull Requests, make sure the Pull Request branch is checked out. Avoid any attempt at previewing the merge or actions involving your main branch.

 ## Pull Request Decoration
 You can also add Pull Request decoration that shows the Pull Request analysis and Quality Gate directly in your ALM's interface. See [Decorating Pull Requests](/analysis/pr-decoration/) for more information on setting it up.
 ## Pull request decoration
 You can also add pull request decoration that shows the Pull Request analysis and Quality Gate directly in your ALM's interface. To set up pull request decoration, see the ALM integration page that corresponds with your ALM:
 - [GitHub Enterprise and GitHub.com](/analysis/github-integration/)
 - [GitLab Self-Managed and GitLab.com](/analysis/gitlab-integration/)
 - [Bitbucket Server](/analysis/bitbucket-integration/)
 - [Azure DevOps Server](/analysis/azuredevops-integration)

 ## Pull Request Quality Gate
 ## Pull request Quality Gate

 A [Quality Gate](/user-guide/quality-gates/) lets you ensure you are meeting your organization's quality policy and that you can merge your Pull Request. The Pull Request Quality Gate:
 A [Quality Gate](/user-guide/quality-gates/) lets you ensure you are meeting your organization's quality policy and that you can merge your pull request. The pull request uses your project Quality Gate as follows:
 * **Focuses on new code** – The Pull Request quality gate only uses your project's quality gate conditions that apply to "on New Code" metrics.
 * **Assigns a status** – Each Pull Request shows a quality gate status reflecting whether it Passed or Failed.

 Pull Request analyses on SonarQube are deleted automatically after 30 days with no analysis. This can be updated in **Administration > Configuration > General Settings > Housekeeping > Number of days before purging inactive branches**. 
 Pull request analyses on SonarQube are deleted automatically after 30 days with no analysis. This can be updated in **Administration > Configuration > General Settings > Housekeeping > Number of days before purging inactive branches**. 

 ## Analysis Parameters
 ## Analysis parameters

 The following parameters enable PR analysis.

--- a/server/sonar-docs/src/pages/analysis/scan/sonarscanner-for-azure-devops.md
+++ b/server/sonar-docs/src/pages/analysis/scan/sonarscanner-for-azure-devops.md
@@ -161,7 +161,7 @@ SonarQube can analyze the code of the new features and annotate your pull reques

 Pull request analysis is supported for any type of Git repositories. To activate it:

 1. Follow the instructions for activating [Pull Request Decoration for Azure DevOps](/analysis/pr-decoration/) on your SonarQube server and project
 1. Follow the instructions on the [Azure DevOps integration](/analysis/azuredevops-integration/) page for pull request decoration.
 1. In the **Branch policies** page of your main development branches (e.g. "master"), add a build policy that runs your build definition

 Next time some code is pushed in the branch of a pull request, the build definition will execute a scan on the code and publish the results in SonarQube which will decorate the pull request in Azure DevOps.
--- a/server/sonar-docs/src/pages/includes/advanced-pr-decor-section.md
+++ b/server/sonar-docs/src/pages/includes/advanced-pr-decor-section.md
@@ -0,0 +1,11 @@
 [[collapse]]
 | ## **Configuring Multiple ALM instances**
 |You can decorate pull requests from multiple ALM instances by creating a configuration for each ALM instance and then assigning that instance configuration to the appropriate projects. 
 |
 |- As part of [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can create one configuration for each ALM. 
 |
 |- Starting in [Enterprise Edition](https://redirect.sonarsource.com/editions/enterprise.html), you can create multiple configurations for each ALM. If you have multiple configurations of the same ALM connected to SonarQube, you have to create projects manually.

 [[collapse]]
 | ## **Linking issues**
 | During pull request decoration, individual issues will be linked to their SonarQube counterparts automatically. For this to work correctly, you need to set the instance's **Server base URL** (**[Administration > Configuration > General Settings > General > General](/#sonarqube-admin#/admin/settings/)**) correctly. Otherwise, the links will default to `localhost`.
--- a/server/sonar-docs/src/pages/includes/authentication-steps.md
+++ b/server/sonar-docs/src/pages/includes/authentication-steps.md
@@ -0,0 +1,7 @@
 Navigate to **Administration > Configuration > General Settings > ALM Integrations > GitHub > GitHub Authentication** and update the following:

 1. **Enabled** – set the switch to `true`.
 1. **Client ID** – the Client ID is found below the GitHub App ID on your GitHub App's page.
 1. **Client Secret** – the Client secret is found below the Client ID on your GitHub App's page.
  
 Now, from the login page, your users can connect their GitHub accounts with the new "Log in with GitHub" button.
--- a/server/sonar-docs/src/pages/instance-administration/delegated-auth.md
+++ b/server/sonar-docs/src/pages/instance-administration/delegated-auth.md
@@ -33,47 +33,10 @@ All the parameters required to activate and configure this feature are available

 Using Http header authentication is an easy way integrate your SonarQube deployment with an in-house SSO implementation.

 ## GitHub Authentication
 You can delegate authentication to GitHub Enterprise and GitHub.com using a dedicated GitHub OAuth application. Alternately, if you're using the pull request decoration provided starting in [Developer Edition](https://redirect.sonarsource.com/editions/developer.html), you can harness the [GitHub application needed for PR decoration](/analysis/pr-decoration/) to also provide authentication.

 ### Dedicated GitHub OAuth application
 1. You'll need to first create a GitHub OAuth application. Click [here](https://developer.github.com/apps/building-oauth-apps/creating-an-oauth-app/) for general instructions:
   1. "Homepage URL" is the public URL to your SonarQube server, for example "https://sonarqube.mycompany.com". For security reasons HTTP is not supported. HTTPS must be used. The public URL is configured in SonarQube at **[Administration > General > Server base URL](/#sonarqube-admin#/admin/settings)**
   1. For **GitHub Enterprise** "Authorization callback URL" and for **GitHub.com** "User authorization callback URL" is <Homepage URL>/oauth2/callback, for example "https://sonarqube.mycompany.com/oauth2/callback"
 1. In SonarQube, navigate to **Administration > Configuration > General Settings > ALM Integrations > GitHub**:
   1. Set **Enabled** to `true`
   1. Set the **Client ID** to the value provided by the GitHub developer application
   1. Set the **Client Secret** to the value provided by the GitHub developer application
  
 On the login form, the new "Log in with GitHub" button allows users to connect with their GitHub Enterprise accounts. 

 ### Re-use GitHub PR decoration application
 1. In the GitHub app, in **Permission & events > User permissions**: Add **Read-only** access in **Emails**.
 1. In SonarQube settings, update the **Client ID** and **Client Secret** and use values defined in the GitHub app.

 If you previously used a dedicated GitHub OAuth application for authentication, it can be removed.

 ## GitLab Authentication  
 You can delegate authentication to GitLab using a dedicated GitLab OAuth application.

 Create a GitLab OAuth application from your GitLab account. Click [here](https://docs.gitlab.com/ee/integration/oauth_provider.html) for general instructions.

   1. In the **Name** text box, name your app SonarQube.
   1. In the **Redirect URI** text box, enter your SonarQube URL with the path `/oauth2/callback/gitlab`. For example, `https://sonarqube.mycompany.com/oauth2/callback/gitlab`.
   1. Under **Scopes**, select **api** if you plan to enable group synchronization. You can instead select **read_user** if you only plan to delegate authentication.

 After saving your application, GitLab gives you your **Application ID** and **Secret**. Keep these at hand, open your SonarQube instance, and navigate to **Administration > Configuration > General Settings > ALM Integrations > GitLab** to finish setting up GitLab authentication:

 1. Set **Enabled** to `true`.
 1. Enter the Application ID provided by GitLab in the **Application ID** text box.
 1. Enter the Secret provided by GitLab in the **Secret** text box.

 On the login form, the new "Log in with GitLab" button allows users to connect with their GitLab accounts.

 ### GitLab group synchronization
 Setting **Synchronize user groups** to `true` at **Administration > Configuration > General Settings > ALM Integrations > GitLab** associates GitLab groups with SonarQube groups of the same name (if they exist). GitLab users inherit membership to subgroups from parent groups so a user that is a member of a group will also be a member of the group's subgroups. 

 To synchronize a GitLab group or subgroup with a SonarQube group, name the SonarQube group with the full path of the of the GitLab group or subgroup URL. For example, say you have a GitLab group named "My Group" with a subgroup named "My Subgroup" and the subgroup URL is `https://YourGitLabURL.com/my-group/my-subgroup`. You would name your SonarQube group `my-group/my-subgroup` to synchronize it with your GitLab subgroup.
 ## GitHub and GitLab Authentication
 You can delegate authentication to GitHub Enterprise and GitHub.com or GitLab Self-Managed and GitLab.com. See the corresponding ALM integration page for more information:
 - [GitHub Enterprise and GitHub.com](/analysis/github-integration/)
 - [GitLab Self-Managed and GitLab.com](/analysis/gitlab-integration/)

 ## SAML Authentication  
 You can delegate authentication to a SAML 2.0 Identity Provider using SAML Authentication.
--- a/server/sonar-docs/static/SonarQubeNavigationTree.json
+++ b/server/sonar-docs/static/SonarQubeNavigationTree.json
@@ -63,13 +63,7 @@
      },
      "/analysis/background-tasks/",
      "/analysis/generic-test/",
      {
        "title": "Pull Request Analysis",
        "children": [
 		  "/analysis/pull-request/",
 		  "/analysis/pr-decoration/"
 		]
      },
 	  "/analysis/pull-request/",
      {
        "title": "Branches",
        "children": [
@@ -81,14 +75,22 @@
        "title": "CI Integration",
        "children": [
          "/analysis/branch-pr-analysis-overview/",
 		  "/analysis/gitlab-cicd/",
          "/analysis/jenkins/"
 		  "/analysis/jenkins/"
        ]
      },
      "/analysis/scm-integration/",
      "/analysis/security_configuration/"
    ]
  },
  {
    "title": "ALM Integration",
    "children": [
      "/analysis/github-integration/",
 	  "/analysis/gitlab-integration/",
 	  "/analysis/bitbucket-integration/",
 	  "/analysis/azuredevops-integration/"
 	 ]
  },
  {
    "title": "User Guide",
    "children": [
--- a/server/sonar-docs/static/StaticNavigationTree.json
+++ b/server/sonar-docs/static/StaticNavigationTree.json
@@ -84,13 +84,7 @@
      },
      "/analysis/background-tasks/",
      "/analysis/generic-test/",
 	  {
        "title": "Pull Request Analysis",
        "children": [
 		  "/analysis/pull-request/",
 		  "/analysis/pr-decoration/"
 		]
      },
 	  "/analysis/pull-request/",
      {
        "title": "Branches",
        "children": [
@@ -102,14 +96,22 @@
        "title": "CI Integration",
        "children": [
          "/analysis/branch-pr-analysis-overview/",
 		  "/analysis/gitlab-cicd/",
          "/analysis/jenkins/"
 		  "/analysis/jenkins/"
        ]
 	  },
      "/analysis/scm-integration/",
      "/analysis/security_configuration/"
    ]
  },
  {
    "title": "ALM Integration",
    "children": [
      "/analysis/github-integration/",
 	  "/analysis/gitlab-integration/",
 	  "/analysis/bitbucket-integration/",
 	  "/analysis/azuredevops-integration/"
 	 ]
  },
  {
    "title": "User Guide",
    "children": [