Add latest changes from gitlab-org/gitlab@master

.gitlab/CODEOWNERS

@@ -131,6 +131,15 @@
 /doc/user/project/settings/import_export.md @aqualls
 /doc/user/snippets.md @aqualls
 
+[Docs Growth]
+/doc/administration/instance_review.md @aqualls
+/doc/api/invitations.md @aqualls
+/doc/api/experiments.md @aqualls 
+/doc/development/experiment_guide/ @aqualls
+/doc/development/snowplow.md @aqualls
+/doc/development/usage_ping/ @aqualls
+/doc/user/admin_area/license.md @aqualls
+
 [Frontend]
 *.scss @annabeldunstone @gitlab-org/maintainers/frontend
 *.js @gitlab-org/maintainers/frontend

app/services/merge_requests/merge_service.rb

@@ -107,8 +107,7 @@ module MergeRequests
       log_info("Post merge finished on JID #{merge_jid} with state #{state}")
 
       if delete_source_branch?
-        ::Branches::DeleteService.new(@merge_request.source_project, branch_deletion_user)
+        MergeRequests::DeleteSourceBranchWorker.perform_async(@merge_request.id, @merge_request.source_branch_sha, branch_deletion_user.id)
-          .execute(merge_request.source_branch)
       end
     end
 

app/views/admin/application_settings/_usage.html.haml

@@ -33,7 +33,7 @@
             %pre.usage-data.js-syntax-highlight.code.highlight.mt-2.d-none{ class: payload_class, data: { endpoint: usage_data_admin_application_settings_path(format: :html) } }
           - else
             = _('The usage ping is disabled, and cannot be configured through this form.')
-            - deactivating_usage_ping_path = help_page_path('development/usage_ping', anchor: 'disable-usage-ping')
+            - deactivating_usage_ping_path = help_page_path('development/usage_ping/index.md', anchor: 'disable-usage-ping')
             - deactivating_usage_ping_link_start = '<a href="%{url}" target="_blank" rel="noopener noreferrer">'.html_safe % { url: deactivating_usage_ping_path }
             = s_('For more information, see the documentation on %{deactivating_usage_ping_link_start}deactivating the usage ping%{deactivating_usage_ping_link_end}.').html_safe % { deactivating_usage_ping_link_start: deactivating_usage_ping_link_start, deactivating_usage_ping_link_end: '</a>'.html_safe }
 

app/views/admin/dev_ops_report/_report.html.haml

@@ -4,7 +4,7 @@
   = render 'callout'
 
 - if !usage_ping_enabled
-  #js-devops-empty-state{ data: { is_admin: current_user&.admin.to_s, empty_state_svg_path: image_path('illustrations/convdev/convdev_no_index.svg'), enable_usage_ping_link: metrics_and_profiling_admin_application_settings_path(anchor: 'js-usage-settings'), docs_link: help_page_path('development/usage_ping') } }
+  #js-devops-empty-state{ data: { is_admin: current_user&.admin.to_s, empty_state_svg_path: image_path('illustrations/convdev/convdev_no_index.svg'), enable_usage_ping_link: metrics_and_profiling_admin_application_settings_path(anchor: 'js-usage-settings'), docs_link: help_page_path('development/usage_ping/index.md') } }
 - elsif @metric.blank?
   = render 'no_data'
 - else

app/workers/all_queues.yml

@@ -1808,6 +1808,14 @@
   :weight: 1
   :idempotent: true
   :tags: []
+- :name: merge_requests_delete_source_branch
+  :feature_category: :source_code_management
+  :has_external_dependencies:
+  :urgency: :high
+  :resource_boundary: :unknown
+  :weight: 1
+  :idempotent: true
+  :tags: []
 - :name: metrics_dashboard_prune_old_annotations
   :feature_category: :metrics
   :has_external_dependencies:

app/workers/merge_requests/delete_source_branch_worker.rb

@@ -0,0 +1,21 @@
+# frozen_string_literal: true
+
+class MergeRequests::DeleteSourceBranchWorker
+  include ApplicationWorker
+
+  feature_category :source_code_management
+  urgency :high
+  idempotent!
+
+  def perform(merge_request_id, source_branch_sha, user_id)
+    merge_request = MergeRequest.find(merge_request_id)
+    user = User.find(user_id)
+
+    # Source branch changed while it's being removed
+    return if merge_request.source_branch_sha != source_branch_sha
+
+    ::Branches::DeleteService.new(merge_request.source_project, user)
+      .execute(merge_request.source_branch)
+  rescue ActiveRecord::RecordNotFound
+  end
+end

changelogs/unreleased/id-move-delete-branch-to-workers.yml

@@ -0,0 +1,5 @@
+---
+title: Move branch deletion on merge to async worker
+merge_request: 55390
+author:
+type: performance

config/sidekiq_queues.yml

@@ -204,6 +204,8 @@
   - 1
 - - merge_request_reset_approvals
   - 1
+- - merge_requests_delete_source_branch
+  - 1
 - - metrics_dashboard_prune_old_annotations
   - 1
 - - metrics_dashboard_sync_dashboards

doc/api/settings.md

@@ -308,6 +308,7 @@ listed in the descriptions of the relevant settings.
 | `in_product_marketing_emails_enabled`    | boolean          | no                                   | Enable in-product marketing emails. Enabled by default. |
 | `invisible_captcha_enabled`              | boolean          | no                                   | <!-- vale gitlab.Spelling = NO --> Enable Invisible Captcha <!-- vale gitlab.Spelling = YES --> spam detection during sign-up. Disabled by default. |
 | `issues_create_limit`                    | integer          | no                                   | Max number of issue creation requests per minute per user. Disabled by default.|
+| `keep_latest_artifact`                   | boolean          | no                                   | Prevent the deletion of the artifacts from the most recent successful jobs, regardless of the expiry time. Enabled by default. |
 | `local_markdown_version`                 | integer          | no                                   | Increase this value when any cached Markdown should be invalidated. |
 | `maintenance_mode_message`               | string           | no                                   | **(PREMIUM)** Message displayed when instance is in maintenance mode |
 | `maintenance_mode`                       | boolean          | no                                   | **(PREMIUM)** When instance is in maintenance mode, non-administrative users can sign in with read-only access and make read-only API requests |

doc/development/README.md

@@ -261,7 +261,7 @@ See [database guidelines](database/index.md).
 ## Product Intelligence guides
 
 - [Product Intelligence guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
-- [Usage Ping guide](usage_ping.md)
+- [Usage Ping guide](usage_ping/index.md)
 - [Snowplow guide](snowplow.md)
 
 ## Experiment guide

doc/development/documentation/site_architecture/release_process.md

@@ -4,191 +4,165 @@ group: unassigned
 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
 ---
 
-# GitLab Docs monthly release process
+# Monthly release process
 
-When a new GitLab version is released on the 22nd, we need to create the respective
+When a new GitLab version is released on the 22nd, we need to release the published documentation
-single Docker image, and update some files so that the dropdown works correctly.
+for the new version.
 
-## 1. Add the chart version
+This should be done as soon as possible after the GitLab version is announced, so that:
 
-Since the charts use a different version number than all the other GitLab
+- The published documentation includes the three most recent minor releases of the current major
-products, we need to add a
+  version, and the most recent minor releases of the last two major versions. For example 13.9,
-[version mapping](https://docs.gitlab.com/charts/installation/version_mappings.html):
+  13.8, 13.7, 12.10, and 11.11.
+- Documentation updates after the 22nd are for the next release. The versions drop down
+  should have the current milestone with `-pre` appended to it, for example `13.10-pre`.
 
-The charts stable branch is not created automatically like the other products.
+Each documentation release:
-There's an [issue to track this](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1442).
-It is usually created on the 21st or the 22nd.
 
-To add a new charts version:
+- Has a dedicated branch, named in the format `XX.yy`.
+- Has a Docker image that contains a build of that branch.
+
+For example:
+
+- For [GitLab 13.9](https://docs.gitlab.com/13.9/index.html), the
+  [stable branch](https://gitlab.com/gitlab-org/gitlab-docs/-/tree/13.9) and Docker image:
+  [`registry.gitlab.com/gitlab-org/gitlab-docs:13.9`](https://gitlab.com/gitlab-org/gitlab-docs/container_registry/631635).
+- For [GitLab 13.8](https://docs.gitlab.com/13.8/index.html), the
+  [stable branch](https://gitlab.com/gitlab-org/gitlab-docs/-/tree/13.8) and Docker image:
+  [`registry.gitlab.com/gitlab-org/gitlab-docs:13.8`](https://gitlab.com/gitlab-org/gitlab-docs/container_registry/631635).
+
+To set up a documentation release, follow these steps:
+
+1. [Add the charts version](#add-chart-version), so that the documentation is built using the
+   [version of the charts project that maps to](https://docs.gitlab.com/charts/installation/version_mappings.html)
+   the GitLab release. This step may have been completed already.
+1. [Create a stable branch and Docker image](#create-stable-branch-and-docker-image-for-release) for
+   the new version.
+1. [Create a release merge request](#create-release-merge-request) for the new version, which
+   updates the version dropdown menu for the current documentation and adds the release to the
+   Docker configuration. For example, the
+   [release merge request for 13.9](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/1555).
+1. [Update the three online versions](#update-dropdown-for-online-versions), so that they display the new release on their
+   version dropdown menus. For example:
+   - The merge request to [update the 13.9 version dropdown menu for the 13.9 release](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/1556).
+   - The merge request to [update the 13.8 version dropdown menu for the 13.9 release](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/1557).
+   - The merge request to [update the 13.7 version dropdown menu for the 13.9 release](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/1558).
+1. [Merge the release merge request and run the necessary Docker image builds](#merge-release-merge-request-and-run-docker-image-builds).
+
+## Add chart version
+
+To add a new charts version for the release:
 
 1. Make sure you're in the root path of the `gitlab-docs` repository.
 1. Open `content/_data/chart_versions.yaml` and add the new stable branch version using the
-   version mapping. Note that only the `major.minor` version is needed.
+   [version mapping](https://docs.gitlab.com/charts/installation/version_mappings.html). Only the
+   `major.minor` version is needed.
 1. Create a new merge request and merge it.
 
 NOTE:
-It can be handy to create the future mappings since they are pretty much known.
+If you have time, add anticipated future mappings to `content/_data/chart_versions.yaml`. This saves
-In that case, when a new GitLab version is released, you don't have to repeat
+a step for the next GitLab release.
-this first step.
 
-## 2. Create an image for a single version
+## Create stable branch and Docker image for release
 
-The single docs version must be created before the release merge request, but
+To create a stable branch and Docker image for the release:
-this needs to happen when the stable branches for all products have been created.
 
 1. Make sure you're in the root path of the `gitlab-docs` repository.
-1. Run the Rake task to create the single version:
+1. Run the Rake task to create the single version. For example, to create the 13.9 release branch
+   and perform others tasks:
 
    ```shell
-   ./bin/rake "release:single[12.0]"
+   ./bin/rake "release:single[13.9]"
    ```
 
-    A new `Dockerfile.12.0` should have been created and `.gitlab-ci.yml` should
+    A branch for the release is created, a new `Dockerfile.13.9` is created, and `.gitlab-ci.yml`
-    have the branches variables updated into a new branch. They are automatically
+    has branches variables updated into a new branch. These files are automatically committed.
-    committed.
 
-1. Push the newly created branch, but **don't create a merge request**.
+1. Push the newly created branch, but **don't create a merge request**. After you push, the
-   After you push, the `image:docs-single` job creates a new Docker image
+   `image:docs-single` job creates a new Docker image tagged with the name of the branch you created
-   tagged with the branch name you created in the first step. In the end, the
+   earlier. You can see the Docker image in the `registry` environment at
-   image is uploaded in the [Container Registry](https://gitlab.com/gitlab-org/gitlab-docs/container_registry)
+   <https://gitlab.com/gitlab-org/gitlab-docs/-/environments/folders/registry>.
-   and it is listed under the `registry` environment folder at
-   `https://gitlab.com/gitlab-org/gitlab-docs/-/environments/folders/registry` (must
-   have developer access).
 
-Optionally, you can test locally by building the image and running it:
+For example, see [the 13.9 release pipeline](https://gitlab.com/gitlab-org/gitlab-docs/-/pipelines/260288747).
 
-```shell
+Optionally, you can test locally by:
-docker build -t docs:12.0 -f Dockerfile.12.0 .
-docker run -it --rm -p 4000:4000 docs:12.0
-```
 
-Visit `http://localhost:4000/12.0/` to see if everything works correctly.
+1. Building the image and running it. For example, for GitLab 13.9 documentation:
 
-## 3. Create the release merge request
+   ```shell
+   docker build -t docs:13.9 -f Dockerfile.13.9 .
+   docker run -it --rm -p 4000:4000 docs:13.9
+   ```
+
+1. Visiting <http://localhost:4000/13.9/> to see if everything works correctly.
+
+## Create release merge request
 
 NOTE:
-To be [automated](https://gitlab.com/gitlab-org/gitlab-docs/-/issues/750).
+An [epic is open](https://gitlab.com/groups/gitlab-org/-/epics/4361) to automate this step.
 
-Now it's time to create the monthly release merge request that adds the new
+To create the release merge request for the release:
-version and rotates the old one:
 
 1. Make sure you're in the root path of the `gitlab-docs` repository.
-1. Create a branch `release-X-Y`:
+1. Create a branch `release-X-Y`. For example:
 
    ```shell
    git checkout master
-   git checkout -b release-12-0
+   git checkout -b release-13-9
    ```
 
-1. **Rotate the online and offline versions:**
+1. Edit `content/_data/versions.yaml` and update the lists of versions to reflect the new release:
 
-   At any given time, there are 4 browsable online versions: one pulled from
+   - Add the latest version to the `online:` section.
-   the upstream master branches (docs for GitLab.com) and the three latest
+   - Move the oldest version in `online:` to the `offline:` section. There should now be three
-   stable versions.
+     versions in `online:`.
 
-   Edit `content/_data/versions.yaml` and rotate the versions to reflect the
+1. Update these Dockerfiles:
-   new changes:
 
-   - `online`: The 3 latest stable versions.
+   - `dockerfiles/Dockerfile.archives`: Add the latest version to the top of the list.
-   - `offline`: All the previous versions offered as an offline archive.
+   - `Dockerfile.master`: Remove the oldest version, and add the newest version to the
+     top of the list.
 
-1. **Update the `:latest` and `:archives` Docker images:**
+1. Commit and push to create the merge request. For example:
-
-   The following two Dockerfiles need to be updated:
-
-   1. `dockerfiles/Dockerfile.archives` - Add the latest version at the top of
-      the list.
-   1. `Dockerfile.master` - Rotate the versions (oldest gets removed and latest
-       is added at the top of the list).
-
-1. In the end, there should be four files in total that have changed.
-   Commit and push to create the merge request using the "Release" template:
 
    ```shell
    git add content/ Dockerfile.master dockerfiles/Dockerfile.archives
-   git commit -m "Release 12.0"
+   git commit -m "Release 13.9"
-   git push origin release-12-0
+   git push origin release-13-9
    ```
 
-## 4. Update the dropdown for all online versions
+Do not merge the release merge request yet.
 
-The versions dropdown is in a way "hardcoded". When the site is built, it looks
+## Update dropdown for online versions
-at the contents of `content/_data/versions.yaml` and based on that, the dropdown
-is populated. Older branches have different content, which means the
-dropdown list is one or more releases behind. Remember that the new changes of
-the dropdown are included in the unmerged `release-X-Y` branch.
 
-The content of `content/_data/versions.yaml` needs to change for all online
+To update`content/_data/versions.yaml` for all online versions (stable branches `X.Y` of the
-versions (stable branches `X.Y` of the `gitlab-docs` project):
+`gitlab-docs` project):
 
-1. Run the Rake task that creates all the respective merge requests needed to
+1. Run the Rake task that creates all of the necessary merge requests to update the dropdowns. For
-   update the dropdowns. Set these to automatically be merged when their
+   example, for the 13.9 release:
-   pipelines succeed:
-
-   NOTE:
-   The `release-X-Y` branch needs to be present locally,
-   and you need to have switched to it, otherwise the Rake task fails.
 
    ```shell
-   git checkout release-X-Y
+   git checkout release-13-9
    ./bin/rake release:dropdowns
    ```
 
+   These merge requests are set to automatically merge.
+
 1. [Visit the merge requests page](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests?label_name%5B%5D=release)
-   to check that their pipelines pass, and once all are merged, proceed to the
+   to check that their pipelines pass. After all MRs are merged, proceed to the following and final
-   following and final step.
+   step.
 
-NOTE:
+## Merge release merge request and run Docker image builds
-In case a pipeline fails, see [troubleshooting](#troubleshooting).
 
-## 5. Merge the release merge request
+The merge requests for the dropdowns should now all be merged into their respective stable branches.
-
+Each merge triggers a new pipeline for each stable branch. Wait for the stable branch pipelines to
-The dropdown merge requests should have now been merged into their respective
+complete, then:
-version (stable `X.Y` branch), which triggers another pipeline. At this point,
-you need to only babysit the pipelines and make sure they don't fail:
 
 1. Check the [pipelines page](https://gitlab.com/gitlab-org/gitlab-docs/pipelines)
    and make sure all stable branches have green pipelines.
-1. After all the pipelines of the online versions succeed, merge the release merge request.
+1. After all the pipelines succeed, merge the [release merge request](#create-release-merge-request).
 1. Finally, run the
    [`Build docker images weekly` pipeline](https://gitlab.com/gitlab-org/gitlab-docs/pipeline_schedules)
    that builds the `:latest` and `:archives` Docker images.
 
-Once the scheduled pipeline succeeds, the docs site is deployed with all
+As the last step in the scheduled pipeline, the documentation site deploys with all new versions.
-new versions online.
-
-## Troubleshooting
-
-Releasing a new version is a long process that involves many moving parts.
-
-### `test_internal_links_and_anchors` failing on dropdown merge requests
-
-WARNING:
-We now pin versions in the `.gitlab-ci.yml` of the respective branch,
-so the steps below are deprecated.
-
-When [updating the dropdown for the stable versions](#4-update-the-dropdown-for-all-online-versions),
-there may be cases where some links might fail. The process of how the
-dropdown MRs are created have a caveat, and that is that the tests run by
-pulling the master branches of all products, instead of the respective stable
-ones.
-
-In a real world scenario, the [Update 12.2 dropdown to match that of 12.4](https://gitlab.com/gitlab-org/gitlab-docs/-/merge_requests/604)
-merge request failed because of the [`test_internal_links_and_anchors` test](https://gitlab.com/gitlab-org/gitlab-docs/-/jobs/328042431).
-
-This happened because there has been a rename of a product (`gitlab-monitor` to `gitlab-exporter`)
-and the old name was still referenced in the 12.2 docs. If the respective stable
-branches for 12.2 were used, this wouldn't have failed, but as we can see from
-the [`compile_dev` job](https://gitlab.com/gitlab-org/gitlab-docs/-/jobs/328042427),
-the `master` branches were pulled.
-
-To fix this, re-run the pipeline (`https://gitlab.com/gitlab-org/gitlab-docs/pipelines/new`)
-for the `update-12-2-for-release-12-4` branch, by including the following CI/CD variables:
-
-- `BRANCH_CE` set to `12-2-stable`
-- `BRANCH_EE` set to `12-2-stable-ee`
-- `BRANCH_OMNIBUS` set to `12-2-stable`
-- `BRANCH_RUNNER` set to `12-2-stable`
-- `BRANCH_CHARTS` set to `2-2-stable`
-
-This should make the MR pass.

doc/development/product_analytics/usage_ping.md

@@ -1,8 +1,8 @@
 ---
-redirect_to: '../usage_ping.md'
+redirect_to: '../usage_ping/index.md'
 ---
 
-This document was moved to [another location](../usage_ping.md).
+This document was moved to [another location](../usage_ping/index.md).
 
 <!-- This redirect file can be deleted after April 1, 2021. -->
 <!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->

doc/development/query_performance.md

@@ -21,7 +21,7 @@ When you are optimizing your SQL queries, there are two dimensions to pay attent
 | Queries in a migration | `100ms` | This is different than the total [migration time](database_review.md#timing-guidelines-for-migrations). |
 | Concurrent operations in a migration | `5min` | Concurrent operations do not block the database, but they block the GitLab update. This includes operations such as `add_concurrent_index` and `add_concurrent_foreign_key`. |
 | Background migrations | `1s` |  |
-| Usage Ping | `1s` | See the [usage ping docs](usage_ping.md#developing-and-testing-usage-ping) for more details. |
+| Usage Ping | `1s` | See the [usage ping docs](usage_ping/index.md#developing-and-testing-usage-ping) for more details. |
 
 - When analyzing your query's performance, pay attention to if the time you are seeing is on a [cold or warm cache](#cold-and-warm-cache). These guidelines apply for both cache types.
 - When working with batched queries, change the range and batch size to see how it effects the query timing and caching.

doc/development/snowplow.md

@@ -11,7 +11,7 @@ This guide provides an overview of how Snowplow works, and implementation detail
 For more information about Product Intelligence, see:
 
 - [Product Intelligence Guide](https://about.gitlab.com/handbook/product/product-intelligence-guide/)
-- [Usage Ping Guide](usage_ping.md)
+- [Usage Ping Guide](usage_ping/index.md)
 
 More useful links:
 

doc/development/usage_ping/metrics_dictionary.md

@@ -96,6 +96,6 @@ create  ee/config/metrics/counts_7d/issues.yml
 
 ## Metrics added dynamic to Usage Ping payload
 
-The [Redis HLL metrics](../usage_ping.md#known-events-are-added-automatically-in-usage-data-payload) are added automatically to Usage Ping payload.
+The [Redis HLL metrics](index.md#known-events-are-added-automatically-in-usage-data-payload) are added automatically to Usage Ping payload.
 
 A YAML metric definition is required for each metric.

doc/development/usage_ping/product_intelligence_review.md

@@ -13,7 +13,7 @@ general best practices for code reviews, refer to our [code review guide](../cod
 
 ## Resources for Product Intelligence reviewers
 
-- [Usage Ping Guide](../usage_ping.md)
+- [Usage Ping Guide](index.md)
 - [Snowplow Guide](../snowplow.md)
 - [Metrics Dictionary](metrics_dictionary.md)
 
@@ -64,13 +64,13 @@ Any of the Product Intelligence engineers can be assigned for the Product Intell
 
 ### How to review for Product Intelligence
 
-- Check the [metrics location](../usage_ping.md#1-naming-and-placing-the-metrics) in
+- Check the [metrics location](index.md#1-naming-and-placing-the-metrics) in
   the Usage Ping JSON payload.
 - Add `~database` label and ask for [database review](../database_review.md) for
   metrics that are based on Database.
 - For tracking using Redis HLL (HyperLogLog):
   - Check the Redis slot.
-  - Check if a [feature flag is needed](../usage_ping.md#recommendations).
+  - Check if a [feature flag is needed](index.md#recommendations).
 - Metrics YAML definitions:
   - Check the metric `description`.
   - Check the metrics `key_path`.

doc/raketasks/index.md

@@ -42,7 +42,7 @@ The following are available Rake tasks:
 | [Repository storage](../administration/raketasks/storage.md)                                        | List and migrate existing projects and attachments from legacy storage to hashed storage. |
 | [Uploads migrate](../administration/raketasks/uploads/migrate.md)                                   | Migrate uploads between storage local and object storage.                                 |
 | [Uploads sanitize](../administration/raketasks/uploads/sanitize.md)                                 | Remove EXIF data from images uploaded to earlier versions of GitLab.                      |
-| [Usage data](../administration/troubleshooting/gitlab_rails_cheat_sheet.md#generate-usage-ping)     | Generate and troubleshoot [Usage Ping](../development/usage_ping.md).|
+| [Usage data](../administration/troubleshooting/gitlab_rails_cheat_sheet.md#generate-usage-ping)     | Generate and troubleshoot [Usage Ping](../development/usage_ping/index.md).|
 | [User management](user_management.md)                                                               | Perform user management tasks.                                                            |
 | [Webhooks administration](web_hooks.md)                                                             | Maintain project Webhooks.                                                                |
 | [X.509 signatures](x509_signatures.md)                                                              | Update X.509 commit signatures, useful if certificate store has changed.                  |

doc/user/admin_area/settings/usage_statistics.md

@@ -61,7 +61,7 @@ sequenceDiagram
 
 ## Usage Ping **(FREE SELF)**
 
-See [Usage Ping guide](../../../development/usage_ping.md).
+See [Usage Ping guide](../../../development/usage_ping/index.md).
 
 ## Instance-level analytics availability
 

package.json

@@ -56,9 +56,9 @@
     "@babel/preset-env": "^7.10.1",
     "@gitlab/at.js": "1.5.7",
     "@gitlab/favicon-overlay": "2.0.0",
-    "@gitlab/svgs": "1.183.0",
+    "@gitlab/svgs": "1.184.0",
     "@gitlab/tributejs": "1.0.0",
-    "@gitlab/ui": "27.14.0",
+    "@gitlab/ui": "27.15.0",
     "@gitlab/visual-review-tools": "1.6.1",
     "@rails/actioncable": "^6.0.3-4",
     "@rails/ujs": "^6.0.3-4",

spec/requests/api/merge_requests_spec.rb

@@ -2537,7 +2537,7 @@ RSpec.describe API::MergeRequests do
       end
     end
 
-    describe "the should_remove_source_branch param" do
+    describe "the should_remove_source_branch param", :sidekiq_inline do
       let(:source_repository) { merge_request.source_project.repository }
       let(:source_branch) { merge_request.source_branch }
 
@@ -2552,7 +2552,7 @@ RSpec.describe API::MergeRequests do
       end
     end
 
-    context "with a merge request that has force_remove_source_branch enabled" do
+    context "with a merge request that has force_remove_source_branch enabled", :sidekiq_inline do
       let(:source_repository) { merge_request.source_project.repository }
       let(:source_branch) { merge_request.source_branch }
 

spec/services/merge_requests/merge_service_spec.rb

@@ -258,9 +258,8 @@ RSpec.describe MergeRequests::MergeService do
           end
 
           it 'removes the source branch using the author user' do
-            expect(::Branches::DeleteService).to receive(:new)
+            expect(::MergeRequests::DeleteSourceBranchWorker).to receive(:perform_async).with(merge_request.id, merge_request.source_branch_sha, merge_request.author.id)
-              .with(merge_request.source_project, merge_request.author)
+
-              .and_call_original
             service.execute(merge_request)
           end
 
@@ -268,7 +267,8 @@ RSpec.describe MergeRequests::MergeService do
             let(:service) { described_class.new(project, user, merge_params.merge('should_remove_source_branch' => false)) }
 
             it 'does not delete the source branch' do
-              expect(::Branches::DeleteService).not_to receive(:new)
+              expect(::MergeRequests::DeleteSourceBranchWorker).not_to receive(:perform_async)
+
               service.execute(merge_request)
             end
           end
@@ -280,9 +280,8 @@ RSpec.describe MergeRequests::MergeService do
           end
 
           it 'removes the source branch using the current user' do
-            expect(::Branches::DeleteService).to receive(:new)
+            expect(::MergeRequests::DeleteSourceBranchWorker).to receive(:perform_async).with(merge_request.id, merge_request.source_branch_sha, user.id)
-              .with(merge_request.source_project, user)
+
-              .and_call_original
             service.execute(merge_request)
           end
         end

spec/workers/merge_requests/delete_source_branch_worker_spec.rb

@@ -0,0 +1,52 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+
+RSpec.describe MergeRequests::DeleteSourceBranchWorker do
+  let_it_be(:merge_request) { create(:merge_request) }
+  let_it_be(:user) { create(:user) }
+
+  let(:sha) { merge_request.source_branch_sha }
+  let(:worker) { described_class.new }
+
+  describe '#perform' do
+    context 'with a non-existing merge request' do
+      it 'does nothing' do
+        expect(::Branches::DeleteService).not_to receive(:new)
+
+        worker.perform(non_existing_record_id, sha, user.id)
+      end
+    end
+
+    context 'with a non-existing user' do
+      it 'does nothing' do
+        expect(::Branches::DeleteService).not_to receive(:new)
+
+        worker.perform(merge_request.id, sha, non_existing_record_id)
+      end
+    end
+
+    context 'with existing user and merge request' do
+      it 'calls service to delete source branch' do
+        expect_next_instance_of(::Branches::DeleteService) do |instance|
+          expect(instance).to receive(:execute).with(merge_request.source_branch)
+        end
+
+        worker.perform(merge_request.id, sha, user.id)
+      end
+
+      context 'source branch sha does not match' do
+        it 'does nothing' do
+          expect(::Branches::DeleteService).not_to receive(:new)
+
+          worker.perform(merge_request.id, 'new-source-branch-sha', user.id)
+        end
+      end
+    end
+
+    it_behaves_like 'an idempotent worker' do
+      let(:merge_request) { create(:merge_request) }
+      let(:job_args) { [merge_request.id, sha, user.id] }
+    end
+  end
+end

spec/workers/merge_worker_spec.rb

@@ -14,7 +14,7 @@ RSpec.describe MergeWorker do
       source_project.repository.expire_branches_cache
     end
 
-    it 'clears cache of source repo after removing source branch' do
+    it 'clears cache of source repo after removing source branch', :sidekiq_inline do
       expect(source_project.repository.branch_names).to include('markdown')
 
       described_class.new.perform(

yarn.lock

@@ -897,20 +897,20 @@
     stylelint-declaration-strict-value "1.7.7"
     stylelint-scss "3.18.0"
 
-"@gitlab/svgs@1.183.0":
+"@gitlab/svgs@1.184.0":
-  version "1.183.0"
+  version "1.184.0"
-  resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-1.183.0.tgz#58a3f49d2355531bfc073f35cbd71855b4a0f9da"
+  resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-1.184.0.tgz#7fe90309999b987362eb1649aa91df24748d3df1"
-  integrity sha512-cOcFlgmTkRhfljT+0arKFtkYMLFMXLk0q74WtMqb9YFRtuPmthqfH0zZd47XZ2yFTSvbEJfcyAXXrPIuX8f8Rg==
+  integrity sha512-K8r5jhnjWR4347j2ADFek7yLgs+MDGqm9cjvwT04aa1vSfhvheLqyKGUy1yz8v7RzXC0Mev6+RT1AbK7m6Ay+w==
 
 "@gitlab/tributejs@1.0.0":
   version "1.0.0"
   resolved "https://registry.yarnpkg.com/@gitlab/tributejs/-/tributejs-1.0.0.tgz#672befa222aeffc83e7d799b0500a7a4418e59b8"
   integrity sha512-nmKw1+hB6MHvlmPz63yPwVs1qQkycHwsKgxpEbzmky16Y6mL4EJMk3w1b8QlOAF/AIAzjCERPhe/R4MJiohbZw==
 
-"@gitlab/ui@27.14.0":
+"@gitlab/ui@27.15.0":
-  version "27.14.0"
+  version "27.15.0"
-  resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-27.14.0.tgz#f80c11df3650380f66aa763867afa32d1901d407"
+  resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-27.15.0.tgz#79fde9dd314f45aa4c061dc1bee8254f1101f79d"
-  integrity sha512-cQaMN4pjcV0lCic3w1eiZUru9kV8XHwI3ZRT3LOWoBRQEbK0r3qv71SNKzEGDOtVPYq+WBl0/PRDlThk9H+CAg==
+  integrity sha512-xkEu/ewbcGkqHcbS7LdQoygKPpt2hUFgFHTOJ2VirgnA810/wvb5N7MrwQvKX2dy8kAdGwIbYyOZQXt3DIKzYA==
   dependencies:
     "@babel/standalone" "^7.0.0"
     "@gitlab/vue-toasted" "^1.3.0"