Add latest changes from gitlab-org/gitlab@master

app/assets/javascripts/error_tracking/store/details/actions.js

@@ -18,7 +18,6 @@ export function startPollingDetails({ commit }, endpoint) {
     data: { endpoint },
     successCallback: ({ data }) => {
       if (!data) {
-        detailPoll.restart();
         return;
       }
@@ -43,7 +42,6 @@ export function startPollingStacktrace({ commit }, endpoint) {
     data: { endpoint },
     successCallback: ({ data }) => {
       if (!data) {
-        stackTracePoll.restart();
         return;
       }
       commit(types.SET_STACKTRACE_DATA, data.error);

app/views/groups/_create_chat_team.html.haml

@@ -6,7 +6,7 @@
       Mattermost
   .col-sm-10
     .form-check.js-toggle-container
-      .js-toggle-button.form-check-input= f.check_box(:create_chat_team, { checked: true }, true, false)
+      .js-toggle-button.form-check-input= f.check_box(:create_chat_team, { checked: false }, true, false)
       = f.label :create_chat_team, class: 'form-check-label' do
         = _('Create a Mattermost team for this group')
       %br

changelogs/unreleased/18530-disable-automatic-team-creation-mattermost.yml

+---
+title: Default the `creation of a Mattermost team` checkbox to false
+merge_request: 23329
+author: briankabiro
+type: changed

changelogs/unreleased/bw-fix-rake-descriptions.yml

+---
+title: Make rake -T output more consistent
+merge_request: 23550
+author:
+type: other

changelogs/unreleased/tr-fix-frontend-polling.yml

+---
+title: Ensure that error tracking frontend only polls when required
+merge_request: 23305
+author:
+type: fixed

doc/administration/file_hooks.md

@@ -105,7 +105,7 @@ bundle exec rake file_hooks:validate RAILS_ENV=production
 Example of output:
-```
+```plaintext
 Validating file hooks from /plugins directory
 * /home/git/gitlab/plugins/save_to_file.clj succeed (zero exit code)
 * /home/git/gitlab/plugins/save_to_file.rb failure (non-zero exit code)

doc/administration/geo/replication/faq.md

@@ -45,7 +45,7 @@ query.
 ## Can I `git push` to a **secondary** node?
-Yes!  Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+Yes!  Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 ## How long does it take to have a commit replicated to a **secondary** node?

doc/administration/geo/replication/index.md

@@ -63,7 +63,7 @@ Keep in mind that:
   - Get user data for logins (API).
   - Replicate repositories, LFS Objects, and Attachments (HTTPS + JWT).
 - Since GitLab Premium 10.0, the **primary** node no longer talks to **secondary** nodes to notify for changes (API).
-- Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+- Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 - There are [limitations](#current-limitations) in the current implementation.
 ### Architecture

doc/administration/geo/replication/security_review.md

@@ -2,8 +2,8 @@
 The following security review of the Geo feature set focuses on security aspects of
 the feature as they apply to customers running their own GitLab instances. The review
-questions are based in part on the [OWASP Application Security Verification Standard Project](https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project)
-from [owasp.org](https://www.owasp.org/index.php/Main_Page).
+questions are based in part on the [OWASP Application Security Verification Standard Project](https://owasp.org/www-project-application-security-verification-standard/)
+from [owasp.org](https://www.owasp.org/).
 ## Business Model

doc/administration/geo/replication/using_a_geo_server.md

@@ -4,7 +4,7 @@
 After you set up the [database replication and configure the Geo nodes][req], use your closest GitLab node as you would a normal standalone GitLab instance.
-Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS) was [introduced](https://about.gitlab.com/blog/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
+Pushing directly to a **secondary** node (for both HTTP, SSH including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3.
 Example of the output you will see when pushing to a **secondary** node:

doc/administration/pages/source.md

@@ -98,7 +98,7 @@ The Pages daemon doesn't listen to the outside world.
 1. Install the Pages daemon:
-   ```
+   ```bash
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -160,7 +160,7 @@ outside world.
 1. Install the Pages daemon:
-   ```
+   ```bash
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -225,7 +225,7 @@ world. Custom domains are supported, but no TLS.
 1. Install the Pages daemon:
-   ```
+   ```bash
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -290,7 +290,7 @@ world. Custom domains and TLS are supported.
 1. Install the Pages daemon:
-   ```
+   ```bash
    cd /home/git
    sudo -u git -H git clone https://gitlab.com/gitlab-org/gitlab-pages.git
    cd gitlab-pages
@@ -353,20 +353,20 @@ not remove the backslashes.
 If your GitLab Pages domain is `example.io`, replace:
-```bash
+```nginx
 server_name ~^.*\.YOUR_GITLAB_PAGES\.DOMAIN$;
 ```
 with:
-```
+```nginx
 server_name ~^.*\.example\.io$;
 ```
 If you are using a subdomain, make sure to escape all dots (`.`) except from
 the first one with a backslash (\). For example `pages.example.io` would be:
-```
+```nginx
 server_name ~^.*\.pages\.example\.io$;
 ```

doc/administration/raketasks/check.md

@@ -33,7 +33,7 @@ integrity check described previously.
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake gitlab:git:fsck
 ```
@@ -58,7 +58,7 @@ Currently, integrity checks are supported for the following types of file:
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake gitlab:artifacts:check
 sudo gitlab-rake gitlab:lfs:check
 sudo gitlab-rake gitlab:uploads:check
@@ -90,7 +90,7 @@ sudo gitlab-rake gitlab:uploads:check BATCH=100 ID_FROM=50 ID_TO=250
 Example output:
-```
+```bash
 $ sudo gitlab-rake gitlab:uploads:check
 Checking integrity of Uploads
 - 1..1350: Failures: 0
@@ -107,7 +107,7 @@ Done!
 Example verbose output:
-```
+```bash
 $ sudo gitlab-rake gitlab:uploads:check VERBOSE=1
 Checking integrity of Uploads
 - 1..1350: Failures: 0

doc/administration/raketasks/geo.md

@@ -11,7 +11,7 @@ This is equivalent of running `git repack -d` on a _bare_ repository.
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake geo:git:housekeeping:incremental_repack
 ```
@@ -29,7 +29,7 @@ when this is enabled in GitLab.
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake geo:git:housekeeping:full_repack
 ```
@@ -46,7 +46,7 @@ a reachability bitmap index when this is enabled in GitLab.
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake geo:git:housekeeping:gc
 ```
@@ -63,7 +63,7 @@ can remove them using the rake task `geo:run_orphaned_project_registry_cleaner`:
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake geo:run_orphaned_project_registry_cleaner
 ```

doc/administration/raketasks/ldap.md

@@ -9,7 +9,7 @@ using the command below.
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake gitlab:ldap:check
 ```
@@ -41,7 +41,7 @@ instead.
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake gitlab:ldap:group_sync
 ```
@@ -101,7 +101,7 @@ sudo gitlab-rake gitlab:ldap:rename_provider[ldapmain,ldapmycompany]
 Example output:
-```
+```plaintext
 100 users with provider 'ldapmain' will be updated to 'ldapmycompany'.
 If the new provider is incorrect, users will be unable to sign in.
 Do you want to continue (yes/no)? yes
@@ -128,7 +128,7 @@ bundle exec rake gitlab:ldap:rename_provider RAILS_ENV=production
 **Example output:**
-```
+```plaintext
 What is the old provider? Ex. 'ldapmain': ldapmain
 What is the new provider? Ex. 'ldapcustom': ldapmycompany
 ```

doc/administration/raketasks/maintenance.md

@@ -6,19 +6,19 @@ This command gathers information about your GitLab installation and the System i
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake gitlab:env:info
 ```
 **Source Installation**
-```
+```bash
 bundle exec rake gitlab:env:info RAILS_ENV=production
 ```
 Example output:
-```
+```plaintext
 System information
 System:           Debian 7.8
 Current User:     git
@@ -66,13 +66,13 @@ You may also have a look at our Troubleshooting Guides:
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake gitlab:check
 ```
 **Source Installation**
-```
+```bash
 bundle exec rake gitlab:check RAILS_ENV=production
 ```
@@ -80,7 +80,7 @@ NOTE: Use `SANITIZE=true` for `gitlab:check` if you want to omit project names f
 Example output:
-```
+```plaintext
 Checking Environment ...
 Git configured for git user? ... yes
@@ -129,18 +129,18 @@ In some case it is necessary to rebuild the `authorized_keys` file.
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake gitlab:shell:setup
 ```
 **Source Installation**
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
 ```
-```
+```plaintext
 This will rebuild an authorized_keys file.
 You will lose any data stored in authorized_keys file.
 Do you want to continue (yes/no)? yes
@@ -153,13 +153,13 @@ clear Redis' cache.
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake cache:clear
 ```
 **Source Installation**
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake cache:clear RAILS_ENV=production
 ```
@@ -174,7 +174,7 @@ Omnibus packages.
 **Source Installation**
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:assets:compile RAILS_ENV=production
 ```
@@ -194,13 +194,13 @@ in the GitLab Performance Monitoring database.
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake gitlab:track_deployment
 ```
 **Source Installation**
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:track_deployment RAILS_ENV=production
 ```
@@ -213,13 +213,13 @@ is included to help you with this:
 **Omnibus Installation**
-```
+```bash
 sudo gitlab-rake gitlab:tcp_check[example.com,80]
 ```
 **Source Installation**
-```
+```bash
 cd /home/git/gitlab
 sudo -u git -H bundle exec rake gitlab:tcp_check[example.com,80] RAILS_ENV=production
 ```
@@ -279,6 +279,6 @@ This could be as a result of [updating existing metrics](../../development/prome
 To re-import the metrics you can run:
-```sh
+```bash
 sudo gitlab-rake metrics:setup_common_metrics
 ```

doc/topics/autodevops/index.md

@@ -659,8 +659,6 @@ procfile exec` to replicate the environment where your application will run.
 #### Workers
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/30628) in GitLab 12.6, `.gitlab/auto-deploy-values.yaml` will be used by default for Helm upgrades.
-
 Some web applications need to run extra deployments for "worker processes". For
 example, it is common in a Rails application to have a separate worker process
 to run background tasks like sending emails.
@@ -683,17 +681,8 @@ need to:
   ensure it's passed into your deployments.
 Once you have configured your worker to respond to health checks, run a Sidekiq
-worker for your Rails application. For:
-
-- GitLab 12.6 and later, either:
-  - Add a file named `.gitlab/auto-deploy-values.yaml` to your repository. It will
-    be automatically used if found.
-  - Add a file with a different name or path to the repository, and override the value of the
-    `HELM_UPGRADE_VALUES_FILE` variable with the path and name.
-- GitLab 12.5 and earlier, run the worker with the `--values` parameter that specifies
-  a file in the repository.
-
-In any case, the file must contain the following:
+worker for your Rails application. You can enable workers by setting the
+following in the [`.gitlab/auto-deploy-values.yaml` file](#customize-values-for-helm-chart):
 ```yml
 workers:
@@ -927,8 +916,21 @@ repo or by specifying a project variable:
 - **Project variable** - Create a [project variable](../../ci/variables/README.md#gitlab-cicd-environment-variables)
   `AUTO_DEVOPS_CHART` with the URL of a custom chart to use or create two project variables `AUTO_DEVOPS_CHART_REPOSITORY` with the URL of a custom chart repository and `AUTO_DEVOPS_CHART` with the path to the chart.
-You can also make use of the `HELM_UPGRADE_EXTRA_ARGS` environment variable to override the default values in the `values.yaml` file in the [default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app).
-To apply your own `values.yaml` file to all Helm upgrade commands in Auto Deploy set `HELM_UPGRADE_EXTRA_ARGS` to `--values my-values.yaml`.
+### Customize values for Helm Chart
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/30628) in GitLab 12.6, `.gitlab/auto-deploy-values.yaml` will be used by default for Helm upgrades.
+
+You can override the default values in the `values.yaml` file in the [default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app).
+This can be achieved by either:
+
+- Adding a file named `.gitlab/auto-deploy-values.yaml` to your repository. It will
+  be automatically used if found.
+- Adding a file with a different name or path to the repository, and set the
+  `HELM_UPGRADE_VALUES_FILE` [environment variable](#environment-variables) with the path and name.
+
+NOTE: **Note:**
+For GitLab 12.5 and earlier, the `HELM_UPGRADE_EXTRA_ARGS` environment variable can be used to override the default chart values.
+To do so, set `HELM_UPGRADE_EXTRA_ARGS` to `--values my-values.yaml`.
 ### Custom Helm chart per environment

doc/user/project/clusters/serverless/aws.md

@@ -78,7 +78,7 @@ service: gitlab-example
 provider:
   name: aws
   runtime: nodejs10.x
-  
+
 functions:
   hello:
     handler: src/handler.hello
@@ -222,7 +222,7 @@ From there, you can reference them in your functions as well.
 Remember to add `A_VARIABLE` to your GitLab CI variables under **Settings > CI/CD > Variables**, and it will get picked up and deployed with your function.
 NOTE: **Note:**
-Anyone with access to the AWS environemnt may be able to see the values of those
+Anyone with access to the AWS environment may be able to see the values of those
 variables persisted in the lambda definition.
 ### Setting up CORS

doc/user/project/integrations/prometheus_library/cloudwatch.md

@@ -12,9 +12,9 @@ The [Prometheus service](../prometheus.md) must be enabled.
 | Name | Query |
 | ---- | ----- |
-| Throughput (req/sec) | sum(aws_elb_request_count_sum{%{environment_filter}}) / 60 |
-| Latency (ms) | avg(aws_elb_latency_average{%{environment_filter}}) * 1000 |
-| HTTP Error Rate (%) | sum(aws_elb_httpcode_backend_5_xx_sum{%{environment_filter}}) / sum(aws_elb_request_count_sum{%{environment_filter}}) |
+| Throughput (req/sec) | `sum(aws_elb_request_count_sum{%{environment_filter}}) / 60` |
+| Latency (ms) | `avg(aws_elb_latency_average{%{environment_filter}}) * 1000` |
+| HTTP Error Rate (%) | `sum(aws_elb_httpcode_backend_5_xx_sum{%{environment_filter}}) / sum(aws_elb_request_count_sum{%{environment_filter}})` |
 ## Configuring Prometheus to monitor for Cloudwatch metrics

doc/user/project/issues/csv_export.md

@@ -62,8 +62,8 @@ Data will be encoded with a comma as the column delimiter, with `"` used to quot
 | Confidential | `Yes` or `No` |
 | Locked | `Yes` or `No` |
 | Due Date | Formated as `YYYY-MM-DD` |
-| Created At (UTC) | Formated as `YYYY-MM-DD HH:MM:SS` |
-| Updated At (UTC) | Formated as `YYYY-MM-DD HH:MM:SS` |
+| Created At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
+| Updated At (UTC) | Formatted as `YYYY-MM-DD HH:MM:SS` |
 | Milestone | Title of the issue milestone |
 | Weight | Issue weight |
 | Labels | Title of any labels joined with a `,` |

doc/user/project/merge_requests/creating_merge_requests.md

@@ -17,7 +17,7 @@ or through the GitLab UI.
 This document describes the several ways to create a merge request.
-When you start a new merge request, regarless of the method,
+When you start a new merge request, regardless of the method,
 you'll be taken to the [**New Merge Request** page](#new-merge-request-page)
 to fill it with information about the merge request.
@@ -29,9 +29,9 @@ button and start a merge request from there.
 On the **New Merge Request** page, start by filling in the title
 and description for the merge request. If there are are already
-commits on the branch, the title will be pre-filled with the first
+commits on the branch, the title will be prefilled with the first
 line of the first commit message, and the description will be
-pre-filled with any additional lines in the commit message.
+prefilled with any additional lines in the commit message.
 The title is the only field that is mandatory in all cases.
 From there, you can fill it with information (title, description,