Merge branch 'docs-repo-merge-redux-3-misc' into 'master'

Docs: Realigning scattered EE docs into CE

See merge request gitlab-org/gitlab-ce!28102

doc/administration/index.md

@@ -72,7 +72,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [Branded login page](../customization/branded_login_page.md): Customize the login page with your own logo, title, and description.
 - [Welcome message](../customization/welcome_message.md): Add a custom welcome message to the sign-in page.
 - ["New Project" page](../customization/new_project_page.md): Customize the text to be displayed on the page that opens whenever your users create a new project.
-- [Additional custom email text](https://docs.gitlab.com/ee/user/admin_area/settings/email.html#custom-additional-text): Add additional custom text to emails sent from GitLab. **[PREMIUM ONLY]**
+- [Additional custom email text](https://docs.gitlab.com/ee/user/admin_area/settings/email.html#custom-additional-text-premium-only): Add additional custom text to emails sent from GitLab. **[PREMIUM ONLY]**
 
 ### Maintaining GitLab
 

doc/administration/operations/extra_sidekiq_processes.md

@@ -93,11 +93,11 @@ This tells the additional processes how often to check for enqueued jobs.
 ## Starting extra processes via command line
 
 Starting extra Sidekiq processes can be done using the command
-`/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster`. This command
+`/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster`. This command
 takes arguments using the following syntax:
 
 ```bash
-/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]
+/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster [QUEUE,QUEUE,...] [QUEUE, ...]
 ```
 
 Each separate argument denotes a group of queues that have to be processed by a
@@ -115,14 +115,14 @@ For example, say you want to start 2 extra processes: one to process the
 done as follows:
 
 ```bash
-/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit post_receive
+/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit post_receive
 ```
 
 If you instead want to start one process processing both queues you'd use the
 following syntax:
 
 ```bash
-/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit,post_receive
+/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive
 ```
 
 If you want to have one Sidekiq process process the "process_commit" and
@@ -130,7 +130,7 @@ If you want to have one Sidekiq process process the "process_commit" and
 you'd use the following:
 
 ```bash
-/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit,post_receive gitlab_shell
+/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive gitlab_shell
 ```
 
 ### Monitoring
@@ -162,7 +162,7 @@ file is written, but this can be changed by passing the `--pidfile` option to
 `sidekiq-cluster`. For example:
 
 ```bash
-/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit
+/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster --pidfile /var/run/gitlab/sidekiq_cluster.pid process_commit
 ```
 
 Keep in mind that the PID file will contain the PID of the `sidekiq-cluster`
@@ -199,7 +199,7 @@ one thread per queue up to a maximum of 50. If you wish to change the cap, use
 the `-m N` option. For example, this would cap the maximum number of threads to 1:
 
 ```bash
-/opt/gitlab/embedded/service/gitlab-rails/bin/sidekiq-cluster process_commit,post_receive -m 1
+/opt/gitlab/embedded/service/gitlab-rails/ee/bin/sidekiq-cluster process_commit,post_receive -m 1
 ```
 
 For each queue group, the concurrency factor will be set to min(number of

doc/ci/metrics_reports.md

@@ -34,6 +34,7 @@ For example:
 metrics:
   script:
     - echo 'metric_name metric_value' > metrics.txt
-  reports:
-    metrics: metrics.txt
+  artifacts:
+    reports:
+      metrics: metrics.txt
 ```

doc/development/README.md

@@ -104,6 +104,10 @@ description: 'Learn how to contribute to GitLab.'
 - [Query Count Limits](query_count_limits.md)
 - [Database helper modules](database_helpers.md)
 
+## Integration guides
+
+- [Jira Connect app](integrations/jira_connect.md)
+
 ## Testing guides
 
 - [Testing standards and style guidelines](testing_guide/index.md)

doc/development/geo.md

@@ -2,10 +2,48 @@
 
 Geo connects GitLab instances together. One GitLab instance is
 designated as a **primary** node and can be run with multiple
-**secondary** nodes. Geo orchestrates quite a few components that are
-described in more detail below.
+**secondary** nodes. Geo orchestrates quite a few components that can be seen on
+the diagram below and are described in more detail within this document.
 
-## Database replication
+![Geo Architecture Diagram](../administration/geo/replication/img/geo_architecture.png)
+
+## Replication layer
+
+Geo handles replication for different components:
+- [Database](#database-replication): includes the entire application, except cache and jobs.
+- [Git repositories](#repository-replication): includes both projects and wikis.
+- [Uploaded blobs](#uploads-replication): includes anything from images attached on issues
+to raw logs and assets from CI.
+
+With the exception of the Database replication, on a *secondary* node, everything is coordinated
+by the [Geo Log Cursor](#geo-log-cursor). 
+
+### Geo Log Cursor daemon
+
+The [Geo Log Cursor daemon](#geo-log-cursor-daemon) is a separate process running on
+each **secondary** node. It monitors the [Geo Event Log](#geo-event-log)
+for new events and creates background jobs for each specific event type.
+
+For example when a repository is updated, the Geo **primary** node creates
+a Geo event with an associated repository updated event. The Geo Log Cursor daemon
+picks the event up and schedules a `Geo::ProjectSyncWorker` job which will
+use the `Geo::RepositorySyncService` and `Geo::WikiSyncService` classes
+to update the repository and the wiki respectively.
+
+The Geo Log Cursor daemon can operate in High Availability mode automatically. 
+The daemon will try to acquire a lock from time to time and once acquired, it 
+will behave as the *active* daemon.
+
+Any additional running daemons on the same node, will be in standby
+mode, ready to resume work if the *active* daemon releases its lock.
+
+We use the [`ExclusiveLease`](https://www.rubydoc.info/github/gitlabhq/gitlabhq/Gitlab/ExclusiveLease) lock type with a small TTL, that is renewed at every
+pooling cycle. That allows us to implement this global lock with a timeout.
+
+At the end of the pooling cycle, if the daemon can't renew and/or reacquire
+the lock, it switches to standby mode.
+
+### Database replication
 
 Geo uses [streaming replication](#streaming-replication) to replicate
 the database from the **primary** to the **secondary** nodes. This
@@ -13,7 +51,7 @@ replication gives the **secondary** nodes access to all the data saved
 in the database. So users can log in on the **secondary** and read all
 the issues, merge requests, etc. on the **secondary** node.
 
-## Repository replication
+### Repository replication
 
 Geo also replicates repositories. Each **secondary** node keeps track of
 the state of every repository in the [tracking database](#tracking-database).
@@ -23,7 +61,7 @@ There are a few ways a repository gets replicated by the:
 - [Repository Sync worker](#repository-sync-worker).
 - [Geo Log Cursor](#geo-log-cursor).
 
-### Project Registry
+#### Project Registry
 
 The `Geo::ProjectRegistry` class defines the model used to track the
 state of repository replication. For each project in the main
@@ -32,15 +70,15 @@ database, one record in the tracking database is kept.
 It records the following about repositories:
 
 - The last time they were synced.
-- The last time they were synced successfully.
+- The last time they were successfully synced.
 - If they need to be resynced.
-- When retry should be attempted.
+- When a retry should be attempted.
 - The number of retries.
-- If and when the they were verified.
+- If and when they were verified.
 
 It also stores these attributes for project wikis in dedicated columns.
 
-### Repository Sync worker
+#### Repository Sync worker
 
 The `Geo::RepositorySyncWorker` class runs periodically in the
 background and it searches the `Geo::ProjectRegistry` model for
@@ -59,26 +97,12 @@ times, Geo does a so-called _redownload_. It will do a clean clone
 into the `@geo-temporary` directory in the root of the storage. When
 it's successful, we replace the main repo with the newly cloned one.
 
-### Geo Log Cursor
-
-The [Geo Log Cursor](#geo-log-cursor) is a separate process running on
-each **secondary** node. It monitors the [Geo Event Log](#geo-event-log)
-and handles all of the events. When it sees an unhandled event, it
-starts a background worker to handle that event, depending on the type
-of event.
-
-When a repository receives an update, the Geo **primary** node creates
-a Geo event with an associated repository updated event. The cursor
-picks that up, and schedules a `Geo::ProjectSyncWorker` job which will
-use the `Geo::RepositorySyncService` class and `Geo::WikiSyncService`
-class to update the repository and the wiki.
-
-## Uploads replication
+### Uploads replication
 
 File uploads are also being replicated to the **secondary** node. To
 track the state of syncing, the `Geo::FileRegistry` model is used.
 
-### File Registry
+#### File Registry
 
 Similar to the [Project Registry](#project-registry), there is a
 `Geo::FileRegistry` model that tracks the synced uploads.
@@ -86,7 +110,7 @@ Similar to the [Project Registry](#project-registry), there is a
 CI Job Artifacts are synced in a similar way as uploads or LFS
 objects, but they are tracked by `Geo::JobArtifactRegistry` model.
 
-### File Download Dispatch worker
+#### File Download Dispatch worker
 
 Also similar to the [Repository Sync worker](#repository-sync-worker),
 there is a `Geo::FileDownloadDispatchWorker` class that is run
@@ -113,7 +137,7 @@ Authorization: GL-Geo <access_key>:<JWT payload>
 ```
 
 The **primary** node uses the `access_key` field to look up the
-corresponding Geo **secondary** node and decrypts the JWT payload,
+corresponding **secondary** node and decrypts the JWT payload,
 which contains additional information to identify the file
 request. This ensures that the **secondary** node downloads the right
 file for the right database ID. For example, for an LFS object, the
@@ -133,6 +157,28 @@ NOTE: **Note:**
 JWT requires synchronized clocks between the machines
 involved, otherwise it may fail with an encryption error.
 
+## Git Push to Geo secondary
+
+The Git Push Proxy exists as a functionality built inside the `gitlab-shell` component.
+It is active on a **secondary** node only. It allows the user that has cloned a repository
+from the secondary node to push to the same URL.
+
+Git `push` requests directed to a **secondary** node will be sent over to the **primary** node, 
+while `pull` requests will continue to be served by the **secondary** node for maximum efficiency.
+
+HTTPS and SSH requests are handled differently:
+
+- With HTTPS, we will give the user a `HTTP 302 Redirect` pointing to the project on the **primary** node.
+The git client is wise enough to understand that status code and process the redirection.
+- With SSH, because there is no equivalent way to perform a redirect, we have to proxy the request.
+This is done inside [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell), by first translating the request 
+to the HTTP protocol, and then proxying it to the **primary** node.
+
+The [`gitlab-shell`](https://gitlab.com/gitlab-org/gitlab-shell) daemon knows when to proxy based on the response 
+from `/api/v4/allowed`. A special `HTTP 300` status code is returned and we execute a "custom action", 
+specified in the response body. The response contains additional data that allows the proxied `push` operation 
+to happen on the **primary** node.
+
 ## Using the Tracking Database
 
 Along with the main database that is replicated, a Geo **secondary**

doc/development/integrations/jira_connect.md

+# Setting up a development environment
+
+The following are required to install and test the app:
+
+1. A Jira Cloud instance
+
+   Atlassian provides free instances for development and testing. [Click here to sign up](http://go.atlassian.com/cloud-dev).
+
+1. A GitLab instance available over the internet
+
+   For the app to work, Jira Cloud should be able to connect to the GitLab instance through the internet.
+
+   To easily expose your local development environment, you can use tools like [serveo](https://serveo.net) or [ngrok](https://ngrok.com).
+   These also take care of SSL for you because Jira requires all connections to the app host to be over SSL.
+
+> This feature is currently behind the `:jira_connect_app` feature flag
+
+# Installing the app in Jira
+
+1. Enable Jira development mode to install apps that are not from the Atlassian Marketplace
+
+   1. Navigate to **Jira settings** (cog icon) > **Apps** > **Manage apps**.
+   1. Scroll to the bottom of the **Manage apps** page and click **Settings**.
+   1. Select **Enable development mode** and click **Apply**.
+
+1. Install the app
+
+   1. Navigate to Jira, then choose **Jira settings** (cog icon) > **Apps** > **Manage apps**.
+   1. Click **Upload app**.
+   1. In the **From this URL** field, provide a link to the app descriptor. The host and port must point to your GitLab instance.
+
+      For example:
+      ```
+      https://xxxx.serveo.net/-/jira_connect/app_descriptor.json
+      ```
+   1. Click **Upload**.
+
+   If the install was successful, you should see the **GitLab for Jira** app under **Manage apps**.
+   You can also click **Getting Started** to open the configuration page rendered from your GitLab instance.
+
+   _Note that any changes to the app descriptor requires you to uninstall then reinstall the app._

doc/user/admin_area/geo_nodes.md

@@ -11,37 +11,38 @@ All Geo nodes have the following settings:
 
 | Setting | Description |
 | --------| ----------- |
-| Primary | This marks a Geo Node as primary. There can be only one primary, make sure that you first add the primary node and then all the others. |
-| URL     | The instance's full URL, in the same way it is configured in  `/etc/gitlab/gitlab.rb` (Omnibus GitLab installations) or `gitlab.yml` (source based installations). |
+| Primary | This marks a Geo Node as **primary** node. There can be only one **primary** node; make sure that you first add the **primary** node and then all the others. |
+| Name    | The unique identifier for the Geo node. Must match the setting `gitlab_rails[geo_node_name]` in `/etc/gitlab/gitlab.rb`. The setting defaults to `external_url` with a trailing slash. |
+| URL     | The instance's user-facing URL. |
 
 The node you're reading from is indicated with a green `Current node` label, and
-the primary is given a blue `Primary` label. Remember that you can only make
-changes on the primary!
+the **primary** node is given a blue `Primary` label. Remember that you can only make
+changes on the **primary** node!
 
-## Secondary node settings
+## **Secondary** node settings
 
-Secondaries have a number of additional settings available:
+**Secondary** nodes have a number of additional settings available:
 
 | Setting                   | Description |
 |---------------------------|-------------|
- Selective synchronization | Enable Geo [selective sync](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization) for this **secondary** node. |
+| Selective synchronization | Enable Geo [selective sync](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization) for this **secondary** node. |
 | Repository sync capacity  | Number of concurrent requests this **secondary** node will make to the **primary** node when backfilling repositories. |
 | File sync capacity        | Number of concurrent requests this **secondary** node will make to the **primary** node when backfilling files. |
 
 ## Geo backfill
 
-Secondaries are notified of changes to repositories and files by the primary,
+**Secondary** nodes are notified of changes to repositories and files by the **primary** node,
 and will always attempt to synchronize those changes as quickly as possible.
 
-Backfill is the act of populating the secondary with repositories and files that
-existed *before* the secondary was added to the database. Since there may be
+Backfill is the act of populating the **secondary** node with repositories and files that
+existed *before* the **secondary** node was added to the database. Since there may be
 extremely large numbers of repositories and files, it's infeasible to attempt to
 download them all at once, so GitLab places an upper limit on the concurrency of
 these operations.
 
 How long the backfill takes is a function of the maximum concurrency, but higher
-values place more strain on the primary node. From [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3107),
-the limits are configurable - if your primary node has lots of surplus capacity,
+values place more strain on the **primary** node. From [GitLab 10.2](https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3107),
+the limits are configurable. If your **primary** node has lots of surplus capacity,
 you can increase the values to complete backfill in a shorter time. If it's
 under heavy load and backfill is reducing its availability for normal requests,
 you can decrease them.
@@ -55,3 +56,15 @@ which is used by users. Internal URL does not need to be a private address.
 
 Internal URL defaults to External URL, but you can customize it under
 **Admin area > Geo Nodes**.
+
+## Multiple secondary nodes behind a load balancer
+
+In GitLab 11.11, **secondary** nodes can use identical external URLs as long as
+a unique `name` is set for each Geo node. The `gitlab.rb` setting
+`gitlab_rails[geo_node_name]` must:
+
+- Be set for each GitLab instance that runs `unicorn`, `sidekiq`, or `geo_logcursor`.
+- Match a Geo node name.
+
+The load balancer must use sticky sessions in order to avoid authentication
+failures and cross site request errors.

doc/user/application_security/dependency_scanning/index.md

@@ -201,6 +201,7 @@ dependency_scanning:
       --env DS_ANALYZER_IMAGE_PREFIX \
       --env DS_ANALYZER_IMAGE_TAG \
       --env DS_DEFAULT_ANALYZERS \
+      --env DS_EXCLUDED_PATHS \
       --env DEP_SCAN_DISABLE_REMOTE_CHECKS \
       --env DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT \
       --env DS_PULL_ANALYZER_IMAGE_TIMEOUT \

doc/user/application_security/sast/index.md

@@ -171,6 +171,8 @@ sast:
         --env SAST_ANALYZER_IMAGE_PREFIX \
         --env SAST_ANALYZER_IMAGE_TAG \
         --env SAST_DEFAULT_ANALYZERS \
+        --env SAST_EXCLUDED_PATHS \
+        --env SAST_BANDIT_EXCLUDED_PATHS \
         --env SAST_BRAKEMAN_LEVEL \
         --env SAST_GOSEC_LEVEL \
         --env SAST_FLAWFINDER_LEVEL \

doc/user/project/labels.md

@@ -24,7 +24,7 @@ in the label’s title, using the format `key::value`. For example:
 
 ![A sample scoped label](img/key_value_labels.png)
 
-Two scoped labels with the same key but a different value cannot simultaneeously
+Two scoped labels with the same key but a different value cannot simultaneously
 apply to an issue, epic, or merge request. For example, if an issue already has `priority::3`
 and you apply `priority::2` to it, `priority::3` is automatically removed from the issue.