kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2021-03-02 09:10:43 +00:00
parent e0a63a4b4d
commit 26a21ebddb
26 changed files with 1532 additions and 1454 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

9
.gitlab/CODEOWNERS
View file

@ -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

3
app/services/merge_requests/merge_service.rb
View file

@ -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)
.execute(merge_request.source_branch)
MergeRequests::DeleteSourceBranchWorker.perform_async(@merge_request.id, @merge_request.source_branch_sha, branch_deletion_user.id)
end
end

2
app/views/admin/application_settings/_usage.html.haml
View file

@ -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 }

2
app/views/admin/dev_ops_report/_report.html.haml
View file

@ -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

8
app/workers/all_queues.yml
View file

@ -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:

21
app/workers/merge_requests/delete_source_branch_worker.rb Normal file
View file

@ -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

5
changelogs/unreleased/id-move-delete-branch-to-workers.yml Normal file
View file

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

2
config/sidekiq_queues.yml
View file

@ -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

1
doc/api/settings.md
View file

@ -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 |

2
doc/development/README.md
View file

@ -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

228
doc/development/documentation/site_architecture/release_process.md
View file

@ -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
single Docker image, and update some files so that the dropdown works correctly.
When a new GitLab version is released on the 22nd, we need to release the published documentation
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
products, we need to add a
[version mapping](https://docs.gitlab.com/charts/installation/version_mappings.html):
- The published documentation includes the three most recent minor releases of the current major
version, and the most recent minor releases of the last two major versions. For example 13.9,
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.
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.
Each documentation release:
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.
In that case, when a new GitLab version is released, you don't have to repeat
this first step.
If you have time, add anticipated future mappings to `content/_data/chart_versions.yaml`. This saves
a step for the next GitLab release.
## 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
this needs to happen when the stable branches for all products have been created.
To create a stable branch and Docker image for the release:
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
have the branches variables updated into a new branch. They are automatically
committed.
A branch for the release is created, a new `Dockerfile.13.9` is created, and `.gitlab-ci.yml`
has branches variables updated into a new branch. These files are automatically committed.
1. Push the newly created branch, but **don't create a merge request**.
After you push, the `image:docs-single` job creates a new Docker image
tagged with the branch name you created in the first step. In the end, the
image is uploaded in the [Container Registry](https://gitlab.com/gitlab-org/gitlab-docs/container_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).
1. Push the newly created branch, but **don't create a merge request**. After you push, the
`image:docs-single` job creates a new Docker image tagged with the name of the branch you created
earlier. You can see the Docker image in the `registry` environment at
<https://gitlab.com/gitlab-org/gitlab-docs/-/environments/folders/registry>.
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
docker build -t docs:12.0 -f Dockerfile.12.0 .
docker run -it --rm -p 4000:4000 docs:12.0
```
Optionally, you can test locally by:
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
version and rotates the old one:
To create the release merge request for the release:
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
the upstream master branches (docs for GitLab.com) and the three latest
stable versions.
- Add the latest version to the `online:` section.
- Move the oldest version in `online:` to the `offline:` section. There should now be three
versions in `online:`.
Edit `content/_data/versions.yaml` and rotate the versions to reflect the
new changes:
1. Update these Dockerfiles:
- `online`: The 3 latest stable versions.
- `offline`: All the previous versions offered as an offline archive.
- `dockerfiles/Dockerfile.archives`: Add the latest version to the top of the list.
- `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:**
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:
1. Commit and push to create the merge request. For example:
```shell
git add content/ Dockerfile.master dockerfiles/Dockerfile.archives
git commit -m "Release 12.0"
git push origin release-12-0
git commit -m "Release 13.9"
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
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.
## Update dropdown for online versions
The content of `content/_data/versions.yaml` needs to change for all online
versions (stable branches `X.Y` of the `gitlab-docs` project):
To update`content/_data/versions.yaml` for all online versions (stable branches `X.Y` of the
`gitlab-docs` project):
1. Run the Rake task that creates all the respective merge requests needed to
update the dropdowns. Set these to automatically be merged when their
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.
1. Run the Rake task that creates all of the necessary merge requests to update the dropdowns. For
example, for the 13.9 release:
```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
following and final step.
to check that their pipelines pass. After all MRs are merged, proceed to the following and final
step.
NOTE:
In case a pipeline fails, see [troubleshooting](#troubleshooting).
## Merge release merge request and run Docker image builds
## 5. Merge the release merge request
The dropdown merge requests should have now been merged into their respective
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:
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
complete, then:
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
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.
As the last step in the scheduled pipeline, the documentation site deploys with all new versions.

4
doc/development/product_analytics/usage_ping.md
View file

@ -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 -->

2
doc/development/query_performance.md
View file

@ -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.

2
doc/development/snowplow.md
View file

@ -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:

1296
doc/development/usage_ping.md
View file

File diff suppressed because it is too large Load diff

1296
doc/development/usage_ping/index.md Normal file
View file

File diff suppressed because it is too large Load diff

2
doc/development/usage_ping/metrics_dictionary.md
View file

@ -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.

6
doc/development/usage_ping/product_intelligence_review.md
View file

@ -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`.

2
doc/raketasks/index.md
View file

@ -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. |

2
doc/user/admin_area/settings/usage_statistics.md
View file

@ -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

4
package.json
View file

@ -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",

4
spec/requests/api/merge_requests_spec.rb
View file

@ -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 }

13
spec/services/merge_requests/merge_service_spec.rb
View file

@ -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)
.with(merge_request.source_project, merge_request.author)
.and_call_original
expect(::MergeRequests::DeleteSourceBranchWorker).to receive(:perform_async).with(merge_request.id, merge_request.source_branch_sha, merge_request.author.id)
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)
.with(merge_request.source_project, user)
.and_call_original
expect(::MergeRequests::DeleteSourceBranchWorker).to receive(:perform_async).with(merge_request.id, merge_request.source_branch_sha, user.id)
service.execute(merge_request)
end
end

52
spec/workers/merge_requests/delete_source_branch_worker_spec.rb Normal file
View file

@ -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

2
spec/workers/merge_worker_spec.rb
View file

@ -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(

16
yarn.lock
View file

@ -897,20 +897,20 @@
stylelint-declaration-strict-value "1.7.7"
stylelint-scss "3.18.0"
"@gitlab/svgs@1.183.0":
version "1.183.0"
resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-1.183.0.tgz#58a3f49d2355531bfc073f35cbd71855b4a0f9da"
integrity sha512-cOcFlgmTkRhfljT+0arKFtkYMLFMXLk0q74WtMqb9YFRtuPmthqfH0zZd47XZ2yFTSvbEJfcyAXXrPIuX8f8Rg==
"@gitlab/svgs@1.184.0":
version "1.184.0"
resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-1.184.0.tgz#7fe90309999b987362eb1649aa91df24748d3df1"
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":
version "27.14.0"
resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-27.14.0.tgz#f80c11df3650380f66aa763867afa32d1901d407"
integrity sha512-cQaMN4pjcV0lCic3w1eiZUru9kV8XHwI3ZRT3LOWoBRQEbK0r3qv71SNKzEGDOtVPYq+WBl0/PRDlThk9H+CAg==
"@gitlab/ui@27.15.0":
version "27.15.0"
resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-27.15.0.tgz#79fde9dd314f45aa4c061dc1bee8254f1101f79d"
integrity sha512-xkEu/ewbcGkqHcbS7LdQoygKPpt2hUFgFHTOJ2VirgnA810/wvb5N7MrwQvKX2dy8kAdGwIbYyOZQXt3DIKzYA==
dependencies:
"@babel/standalone" "^7.0.0"
"@gitlab/vue-toasted" "^1.3.0"