Add latest changes from gitlab-org/gitlab@13-10-stable-eev13.10.0-rc40

4 files changed, 29 insertions, 69 deletions

diff --git a/doc/development/integrations/jenkins.md b/doc/development/integrations/jenkins.md
index 16aba023fab..f54abfd17fd 100644
--- a/doc/development/integrations/jenkins.md
+++ b/doc/development/integrations/jenkins.md
@@ -8,6 +8,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 This is a step by step guide on how to set up [Jenkins](https://www.jenkins.io/) on your local machine and connect to it from your GitLab instance. GitLab triggers webhooks on Jenkins, and Jenkins connects to GitLab using the API. By running both applications on the same machine, we can make sure they are able to access each other.
 
+For configuring an existing Jenkins integration, read [Jenkins CI service](../../integration/jenkins.md).
+
 ## Install Jenkins
 
 Install Jenkins and start the service using Homebrew.
@@ -39,62 +41,20 @@ Jenkins uses the GitLab API and needs an access token.
 
 ## Configure Jenkins
 
-Configure your GitLab API connection in Jenkins.
-
-1. Make sure the GitLab plugin is installed on Jenkins. You can manage plugins in **Manage Jenkins > Manage Plugins**.
-1. Set up the GitLab connection:
-   1. Go to **Manage Jenkins > Configure System**.
-   1. Find the **GitLab** section and check the **Enable authentication for '/project' end-point** checkbox.
-1. To add your credentials, click **Add** then choose **Jenkins Credential Provider**.
-1. Choose **GitLab API token** as the type of token.
-1. Paste your GitLab access token and click **Add**.
-1. Choose your credentials from the dropdown menu.
-1. Add your GitLab host URL. Normally `http://localhost:3000/`.
-1. Click **Save Settings**.
-
-For more details, see [GitLab documentation about Jenkins CI](../../integration/jenkins.md).
+To configure your GitLab API connection in Jenkins, read
+[Configure the Jenkins server](../../integration/jenkins.md#configure-the-jenkins-server).
 
 ## Configure Jenkins Project
 
-Set up the Jenkins project to run your build on. A **Freestyle** project is the easiest
-option because the Jenkins plugin updates the build status on GitLab. In a **Pipeline** project, updating the status on GitLab needs to be configured in a script.
-
-1. On your Jenkins instance, go to **New Item**.
-1. Pick a name, choose **Freestyle** or **Pipeline** and click **ok**.
-1. Choose your GitLab connection from the dropdown.
-1. Check the **Build when a change is pushed to GitLab** checkbox.
-1. Check the following checkboxes:
-
-   - **Accepted Merge Request Events**
-   - **Closed Merge Request Events**
-
-1. If you created a **Freestyle** project, choose **Publish build status to GitLab** in the **Post-build Actions** section.
-
-   If you created a **Pipeline** project, updating the status on GitLab has to be done by the pipeline script. Add GitLab update steps as in this example:
-
-   ```groovy
-   pipeline {
-      agent any
-
-      stages {
-         stage('gitlab') {
-            steps {
-               echo 'Notify GitLab'
-               updateGitlabCommitStatus name: 'build', state: 'pending'
-               updateGitlabCommitStatus name: 'build', state: 'success'
-            }
-         }
-      }
-   }
-   ```
+To set up the Jenkins project you intend to run your build on, read
+[Configure the Jenkins project](../../integration/jenkins.md#configure-the-jenkins-project).
 
 ## Configure your GitLab project
 
-To activate the Jenkins service:
+You can configure your integration between Jenkins and GitLab:
 
-1. Go to your project's page, then **Settings > Integrations > Jenkins CI**.
-1. Check the **Active** checkbox and the triggers for **Push** and **Merge request**.
-1. Fill in your Jenkins host, project name, username and password and click **Test settings and save changes**.
+- With the [recommended approach for Jenkins integration](../../integration/jenkins.md#recommended-jenkins-integration).
+- [Using a webhook](../../integration/jenkins.md#webhook-integration).
 
 ## Test your setup
 
diff --git a/doc/development/integrations/jira_connect.md b/doc/development/integrations/jira_connect.md
index bfe523ee390..860fd88612f 100644
--- a/doc/development/integrations/jira_connect.md
+++ b/doc/development/integrations/jira_connect.md
@@ -4,7 +4,7 @@ group: Ecosystem
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Set up a development environment
+# Set up a development environment **(FREE)**
 
 The following are required to install and test the app:
 
diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index 1d5aced5869..fda75dad119 100644
--- a/doc/development/integrations/secure.md
+++ b/doc/development/integrations/secure.md
@@ -89,7 +89,7 @@ it's declared under the `reports:sast` key in the job definition, not because of
 ### Policies
 
 Certain GitLab workflows, such as [AutoDevOps](../../topics/autodevops/customize.md#disable-jobs),
-define variables to indicate that given scans should be disabled. You can check for this by looking
+define CI/CD variables to indicate that given scans should be disabled. You can check for this by looking
 for variables such as `DEPENDENCY_SCANNING_DISABLED`, `CONTAINER_SCANNING_DISABLED`,
 `SAST_DISABLED`, and `DAST_DISABLED`. If appropriate based on the scanner type, you should then
 disable running the custom scanner.
@@ -97,7 +97,7 @@ disable running the custom scanner.
 GitLab also defines a `CI_PROJECT_REPOSITORY_LANGUAGES` variable, which provides the list of
 languages in the repository. Depending on this value, your scanner may or may not do something different.
 Language detection currently relies on the [`linguist`](https://github.com/github/linguist) Ruby gem.
-See [GitLab CI/CD predefined variables](../../ci/variables/predefined_variables.md).
+See the [predefined CI/CD variables](../../ci/variables/predefined_variables.md).
 
 #### Policy checking example
 
@@ -170,23 +170,23 @@ It also generates text output on the standard output and standard error streams,
 
 ### Variables
 
-All CI variables are passed to the scanner as environment variables.
-The scanned project is described by the [predefined CI variables](../../ci/variables/README.md).
+All CI/CD variables are passed to the scanner as environment variables.
+The scanned project is described by the [predefined CI/CD variables](../../ci/variables/README.md).
 
 #### SAST and Dependency Scanning
 
-SAST and Dependency Scanning scanners must scan the files in the project directory, given by the `CI_PROJECT_DIR` variable.
+SAST and Dependency Scanning scanners must scan the files in the project directory, given by the `CI_PROJECT_DIR` CI/CD variable.
 
 #### Container Scanning
 
 In order to be consistent with the official Container Scanning for GitLab,
 scanners must scan the Docker image whose name and tag are given by
 `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG`, respectively. If the `DOCKER_IMAGE`
-variable is provided, then the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` variables
+CI/CD variable is provided, then the `CI_APPLICATION_REPOSITORY` and `CI_APPLICATION_TAG` variables
 are ignored, and the image specified in the `DOCKER_IMAGE` variable is scanned instead.
 
 If not provided, `CI_APPLICATION_REPOSITORY` should default to
-`$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`, which is a combination of predefined CI variables.
+`$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG`, which is a combination of predefined CI/CD variables.
 `CI_APPLICATION_TAG` should default to `CI_COMMIT_SHA`.
 
 The scanner should sign in the Docker registry
@@ -197,13 +197,13 @@ If these are not defined, then the scanner should use
 #### Configuration files
 
 While scanners may use `CI_PROJECT_DIR` to load specific configuration files,
-it is recommended to expose configuration as environment variables, not files.
+it is recommended to expose configuration as CI/CD variables, not files.
 
 ### Output file
 
-Like any artifact uploaded to the GitLab CI/CD,
+Like any artifact uploaded to GitLab CI/CD,
 the Secure report generated by the scanner must be written in the project directory,
-given by the `CI_PROJECT_DIR` environment variable.
+given by the `CI_PROJECT_DIR` CI/CD variable.
 
 It is recommended to name the output file after the type of scanning, and to use `gl-` as a prefix.
 Since all Secure reports are JSON files, it is recommended to use `.json` as a file extension.
@@ -242,7 +242,7 @@ Also, we recommend prefixing error messages with `[ERRO]`, warnings with `[WARN]
 #### Logging level
 
 The scanner should filter out a log message if its log level is lower than the
-one set in the `SECURE_LOG_LEVEL` variable. For instance, `info` and `warn`
+one set in the `SECURE_LOG_LEVEL` CI/CD variable. For instance, `info` and `warn`
 messages should be skipped when `SECURE_LOG_LEVEL` is set to `error`. Accepted
 values are as follows, listed from highest to lowest:
 
@@ -263,14 +263,14 @@ and what `bundle audit` writes to the standard output.
 If the command line fails, then it should be logged with the `error` log level;
 this makes it possible to debug the problem without having to change the log level to `debug` and rerun the scanning job.
 
-#### common logutil package
+#### common `logutil` package
 
 If you are using [go](https://golang.org/) and
 [common](https://gitlab.com/gitlab-org/security-products/analyzers/common),
-then it is suggested that you use [logrus](https://github.com/Sirupsen/logrus)
-and [common's logutil package](https://gitlab.com/gitlab-org/security-products/analyzers/common/-/tree/master/logutil)
-to configure the formatter for [logrus](https://github.com/Sirupsen/logrus).
-See the [logutil README.md](https://gitlab.com/gitlab-org/security-products/analyzers/common/-/tree/master/logutil/README.md)
+then it is suggested that you use [Logrus](https://github.com/Sirupsen/logrus)
+and [common's `logutil` package](https://gitlab.com/gitlab-org/security-products/analyzers/common/-/tree/master/logutil)
+to configure the formatter for [Logrus](https://github.com/Sirupsen/logrus).
+See the [`logutil` README](https://gitlab.com/gitlab-org/security-products/analyzers/common/-/tree/master/logutil/README.md)
 
 ## Report
 
@@ -548,7 +548,7 @@ of the available SAST Analyzers and what data is currently available.
 
 The `remediations` field of the report is an array of remediation objects.
 Each remediation describes a patch that can be applied to
-[automatically fix](../../user/application_security/#automatic-remediation-for-vulnerabilities)
+[automatically fix](../../user/application_security/#apply-an-automatic-remediation-for-a-vulnerability)
 a set of vulnerabilities.
 
 Here is an example of a report that contains remediations.
diff --git a/doc/development/integrations/secure_partner_integration.md b/doc/development/integrations/secure_partner_integration.md
index 364e18ad015..17bce13583c 100644
--- a/doc/development/integrations/secure_partner_integration.md
+++ b/doc/development/integrations/secure_partner_integration.md
@@ -13,7 +13,7 @@ guidelines so you can build an integration that fits with the workflow GitLab
 users are already familiar with.
 
 This page also provides resources for the technical work associated
-with [onboarding as a partner](https://about.gitlab.com/partners/integrate/).
+with [onboarding as a partner](https://about.gitlab.com/partners/technology-partners/integrate/).
 The steps below are a high-level view of what needs to be done to complete an
 integration as well as linking to more detailed resources for how to do so.
 
@@ -101,7 +101,7 @@ and complete an integration with the Secure stage.
    - Users can interact with the findings from your artifact within their workflow. They can dismiss the findings or accept them and create a backlog issue.
    - To automatically create issues without user interaction, use the [issue API](../../api/issues.md).
 1. Optional: Provide auto-remediation steps:
-   - If you specified `remediations` in your artifact, it is proposed through our [automatic remediation](../../user/application_security/index.md#automatic-remediation-for-vulnerabilities)
+   - If you specified `remediations` in your artifact, it is proposed through our [automatic remediation](../../user/application_security/index.md#apply-an-automatic-remediation-for-a-vulnerability)
      interface.
 1. Demo the integration to GitLab:
    - After you have tested and are ready to demo your integration please