Add latest changes from gitlab-org/gitlab@15-4-stable-ee

9 files changed, 244 insertions, 8 deletions

diff --git a/app/services/projects/update_pages_service.rb b/app/services/projects/update_pages_service.rb
index bf90783fcbe..6a963e7fcd1 100644
--- a/app/services/projects/update_pages_service.rb
+++ b/app/services/projects/update_pages_service.rb
@@ -66,7 +66,8 @@ module Projects
       GenericCommitStatus.new(
         user: build.user,
         ci_stage: stage,
-        name: 'pages:deploy'
+        name: 'pages:deploy',
+        stage: 'deploy'
       )
     end
 
diff --git a/data/whats_new/202209220001_15_04.yml b/data/whats_new/202209220001_15_04.yml
new file mode 100644
index 00000000000..056826c6457
--- /dev/null
+++ b/data/whats_new/202209220001_15_04.yml
@@ -0,0 +1,103 @@
+- name: "Suggested Reviewers open beta" # Match the release post entry
+  description: |  # Do not modify this line, instead modify the lines below.
+    Deciding the right person to [review your merge request](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/) isn't always straightforward or obvious. Choosing the wrong reviewer can cause delays, low quality reviews, back and forth reassigning reviewers, or even no review at all.
+
+    Now, GitLab can recommend a reviewer with [Suggested Reviewers](https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#suggested-reviewers). Using the changes in a merge request and a project's contribution graph, machine learning powered suggestions appear in the [reviewer dropdown](https://docs.gitlab.com/ee/user/project/merge_requests/getting_started.html#reviewer) in the merge request sidebar.
+
+    This feature is currently in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#open-beta) behind a [feature flag](https://gitlab.com/gitlab-org/gitlab/-/issues/368356). It will be rolling out to all Ultimate GitLab.com customers over the next week.
+  stage: create # String value of the stage that the feature was created in. e.g., Growth
+  self-managed: false # Boolean value (true or false)
+  gitlab-com: true # Boolean value (true or false)
+  available_in: [Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Premium, Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/user/project/merge_requests/reviews/#suggested-reviewers' # This is the documentation URL, but can be a URL to a video if there is one
+  image_url: https://about.gitlab.com/images/15_4/create-code-review-suggested-reviewers.png # This should be a full URL, generally taken from the release post content. If a video, use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  published_at: 2022-09-22 # YYYY-MM-DD
+  release: 15.4 # XX.Y
+- name: "Improved CI/CD integration in VS Code" # Match the release post entry
+  description: |  # Do not modify this line, instead modify the lines below.
+    When you're constructing complicated GitLab CI configurations that may contain `include:` or `extends:` keywords, it's challenging to ensure the configuration is valid and the resulting file has your expected configuration. Use [GitLab Workflow](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) for Visual Studio Code to preview your merged GitLab CI/CD configuration file directly in VS Code. You can view your changes locally, and ensure your configuration is as you expect, before you commit and push.
+
+    GitLab Workflow [v3.50.0](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/blob/main/CHANGELOG.md#3500-2022-09-09) also provides more CI/CD pipeline interactions to help you avoid context-switching:
+
+     * Download artifacts: [commit `f4d027c`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/commit/f4d027c616c884bef9fc42e5f20dfac43b811134), [merge request `!635`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/635)
+     * Retry or cancel an existing pipeline: [commit `c2caee4`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/commit/c2caee40cfcbfb5d13cc790f9a2d1cfcf6c6a7ab), [merge request `!637`](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/merge_requests/637)
+  stage: create # String value of the stage that the feature was created in. e.g., Growth
+  self-managed: true # Boolean value (true or false)
+  gitlab-com: false # Boolean value (true or false)
+  available_in: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Premium, Ultimate]
+  documentation_link: 'https://gitlab.com/gitlab-org/gitlab-vscode-extension#show-merged-gitlab-cicd-configuration' # This is the documentation URL, but can be a URL to a video if there is one
+  image_url: https://about.gitlab.com/images/15_4/create-vs-code-cicd-improvements.png # This should be a full URL, generally taken from the release post content. If a video, use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  published_at: 2022-09-22 # YYYY-MM-DD
+  release: 15.4 # XX.Y
+- name: "Users on verified domains can bypass email validation" # Match the release post entry
+  description: |  # Do not modify this line, instead modify the lines below.
+    New GitLab users created using SAML or SCIM that belong to a [verified domain](https://docs.gitlab.com/ee/user/project/pages/custom_domains_ssl_tls_certification/#1-add-a-custom-domain) no longer receive the GitLab account verification e-mail.
+
+    This reduces account activation friction. Accounts generated through a provisioning process are already verified, so users should not have to individually verify them manually.
+  stage: manage # String value of the stage that the feature was created in. e.g., Growth
+  self-managed: false # Boolean value (true or false)
+  gitlab-com: true # Boolean value (true or false)
+  available_in: [Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Premium, Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/user/group/saml_sso/index.html#bypass-user-verification-with-verified-domains' # This is the documentation URL, but can be a URL to a video if there is one
+  image_url: https://about.gitlab.com/images/15_4/domain-verification.png # This should be a full URL, generally taken from the release post content. If a video, use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  published_at: 2022-09-22 # YYYY-MM-DD
+  release: 15.4 # XX.Y
+- name: "Sortable, filterable data-driven tables in Markdown" # Match the release post entry
+  description: |  # Do not modify this line, instead modify the lines below.
+    Working with tables in Markdown can be a bit cumbersome. Not only is it difficult to figure out the correct number of pipes and empty cells, but the table output is static when you save your document. If you have to sort the table by the third column in an ascending order, you end up rewriting the whole thing.
+
+    Now you can insert data-driven tables using JSON syntax as follows:
+
+    1. Write or export a table in JSON.
+    1. Wrap JSON in a code block that starts with triple backticks `\`` followed by `json:table`.
+    1. Save your issue, submit your comment, or publish your page.
+
+    In the rendered table, you can also enable:
+
+    - Sorting for specific fields using `"sortable": true`
+    - Dynamic filtering of data using `"filter" : true`
+
+    Now it's as simple as a click when you have to re-sort that 100-row table and as easy as a web search when you have to find that one issue reference lost in a sea of nearly identical URLs.
+  stage: create # String value of the stage that the feature was created in. e.g., Growth
+  self-managed: true # Boolean value (true or false)
+  gitlab-com: true # Boolean value (true or false)
+  available_in: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Premium, Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/user/markdown.html#json' # This is the documentation URL, but can be a URL to a video if there is one
+  image_url: https://img.youtube.com/vi/12yWKw1AdKY/hqdefault.jpg # This should be a full URL, generally taken from the release post content. If a video, use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  published_at: 2022-09-22 # YYYY-MM-DD
+  release: 15.4 # XX.Y
+- name: "Getting started with GitLab Pages just got easier" # Match the release post entry
+  description: |  # Do not modify this line, instead modify the lines below.
+    We've made it much easier to get started with GitLab Pages. Instead of creating configuration files by hand, build them interactively using the GitLab UI. Just answer a few basic questions on how your app is built, and we'll build the `.gitlab-ci.yml` file to get you started.
+
+    This is the first time we're using our new [Pipeline Wizard](https://docs.gitlab.com/ee/development/cicd/pipeline_wizard.html), a tool that makes it easy to create `.gitlab-ci.yml` files by building them in the GitLab UI. You can look forward to more simplified onboarding helpers like this one.
+  stage: create # String value of the stage that the feature was created in. e.g., Growth
+  self-managed: true # Boolean value (true or false)
+  gitlab-com: true # Boolean value (true or false)
+  available_in: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Premium, Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/user/project/pages/getting_started/pages_ui.html' # This is the documentation URL, but can be a URL to a video if there is one
+  image_url: https://about.gitlab.com/images/15_4/create-pages-onboarding.png # This should be a full URL, generally taken from the release post content. If a video, use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  published_at: 2022-09-22 # YYYY-MM-DD
+  release: 15.4 # XX.Y
+- name: "More powerful Linux machine types for GitLab SaaS runners" # Match the release post entry
+  description: |  # Do not modify this line, instead modify the lines below.
+    When you run jobs on GitLab SaaS Linux runners, you now have access to more powerful machine types: medium and large. With these two machine types, you have more choices for your GitLab SaaS CI/CD jobs. And with 100% job isolation on an ephemeral virtual machine, and security and autoscaling fully managed by GitLab, you can confidently run your critical CI/CD jobs on GitLab SaaS.
+  stage: create # String value of the stage that the feature was created in. e.g., Growth
+  self-managed: false # Boolean value (true or false)
+  gitlab-com: true # Boolean value (true or false)
+  available_in: [Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Premium, Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html' # This is the documentation URL, but can be a URL to a video if there is one
+  image_url: https://about.gitlab.com/images/15_4/select-multiple-gitlab-saas-linux-runners.png # This should be a full URL, generally taken from the release post content. If a video, use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  published_at: 2022-09-22 # YYYY-MM-DD
+  release: 15.4 # XX.Y
+- name: "Limit the maximum number of custom domains per project" # Match the release post entry
+  description: |  # Do not modify this line, instead modify the lines below.
+    You can use GitLab Pages to define custom domains for your website. Too many custom domains, however, can result in slow response times from the Pages API and impact the overall reliability of the service. Now you can limit the maximum number of custom domains per project at the instance level and strike the right balance for your needs. The default value is `0` (unlimited).
+  stage: create # String value of the stage that the feature was created in. e.g., Growth
+  self-managed: true # Boolean value (true or false)
+  gitlab-com: false # Boolean value (true or false)
+  available_in: [Free, Premium, Ultimate] # Array of strings. The Array brackets are required here. e.g., [Free, Premium, Ultimate]
+  documentation_link: 'https://docs.gitlab.com/ee/administration/pages/#set-maximum-number-of-gitlab-pages-custom-domains-for-a-project' # This is the documentation URL, but can be a URL to a video if there is one
+  image_url: https://about.gitlab.com/images/15_4/create-pages-domain-limits.png # This should be a full URL, generally taken from the release post content. If a video, use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg
+  published_at: 2022-09-22 # YYYY-MM-DD
+  release: 15.4 # XX.Y
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index ac03c3ffc02..bfd252a9f42 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -1340,3 +1340,53 @@ value = "ignore"
 key = "receive.fsck.hasDotgit"
 value = "ignore"
 ```
+
+## Configure commit signing for GitLab UI commits
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/19185) in GitLab 15.4.
+
+By default, Gitaly doesn't sign commits made using GitLab UI. For example, commits made using:
+
+- Web editor.
+- Web IDE.
+- Merge requests.
+
+You can configure Gitaly to sign commits made using GitLab UI. The commits show as unverified and signed by an unknown user. Support for improvements is
+proposed in issue [19185](https://gitlab.com/gitlab-org/gitlab/-/issues/19185).
+
+**For Omnibus GitLab**
+
+1. [Create a GPG key](../../user/project/repository/gpg_signed_commits/index.md#create-a-gpg-key)
+   and export it. For optimal performance, consider using an EdDSA key.
+
+   ```shell
+   gpg --export-secret-keys <ID> > signing_key.gpg
+   ```
+
+1. On the Gitaly nodes, copy the key into `/etc/gitlab/gitaly/`.
+1. Edit `/etc/gitlab/gitlab.rb` and configure `gitaly['gpg_signing_key_path']`:
+
+   ```ruby
+   gitaly['gpg_signing_key_path'] = "/etc/gitlab/gitaly/signing_key.gpg"
+   ```
+
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+
+**For installations from source**
+
+1. [Create a GPG key](../../user/project/repository/gpg_signed_commits/index.md#create-a-gpg-key)
+   and export it. For optimal performance, consider using an EdDSA key.
+
+   ```shell
+   gpg --export-secret-keys <ID> > signing_key.gpg
+   ```
+
+1. On the Gitaly nodes, copy the key into `/etc/gitlab`.
+1. Edit `/home/git/gitaly/config.toml` and configure `signing_key`:
+
+   ```toml
+   [git]
+   signing_key = "/etc/gitlab/gitaly/signing_key.gpg"
+   ```
+
+1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
diff --git a/doc/administration/gitaly/reference.md b/doc/administration/gitaly/reference.md
index 91780ec5661..2542848c7a8 100644
--- a/doc/administration/gitaly/reference.md
+++ b/doc/administration/gitaly/reference.md
@@ -129,6 +129,7 @@ The following values can be set in the `[git]` section of the configuration file
 | ---- | ---- | -------- | ----------- |
 | `bin_path` | string | no | Path to Git binary. If not set, is resolved using `PATH`. |
 | `catfile_cache_size` | integer | no | Maximum number of cached [cat-file processes](#cat-file-cache). Default is `100`. |
+| `signing_key` | string | no | Path to [GPG signing key](configure_gitaly.md#configure-commit-signing-for-gitlab-ui-commits). If not set, Gitaly doesn't sign commits made using the UI. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/19185) in GitLab 15.4. |
 
 #### `cat-file` cache
 
diff --git a/doc/user/project/merge_requests/reviews/data_usage.md b/doc/user/project/merge_requests/reviews/data_usage.md
new file mode 100644
index 00000000000..0988e3f0042
--- /dev/null
+++ b/doc/user/project/merge_requests/reviews/data_usage.md
@@ -0,0 +1,44 @@
+---
+stage: ModelOps
+group: Applied ML
+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
+type: index, reference
+---
+
+# Suggested Reviewers Data Usage
+
+## How it works
+
+Suggested Reviewers is the first user-facing GitLab machine learning (ML) powered feature. It leverages a project's contribution graph to generate suggestions. This data already exists within GitLab including merge request metadata, source code files, and GitLab user account metadata. 
+
+### Enabling the feature
+
+When a Project Maintainer or Owner enables Suggested Reviewers in project settings GitLab kicks off a data extraction job for the project which leverages the Merge Request API to understand pattern of review including recency, domain experience, and frequency to suggest an appropriate reviewer.
+
+This data extraction job can take a few hours to complete (possibly up to a day), which is largely dependent on the size of the project. The process is automated and no action is needed during this process. Once data extraction is complete, you will start getting suggestions in merge requests. 
+
+### Generating suggestions
+
+Once Suggested Reviewers is enabled and the data extraction is complete, new merge requests or new commits to existing merge requests will automatically trigger a Suggested Reviewers ML model inference and generate up to 5 suggested reviewers. These suggestions are contextual to the changes in the merge request. Additional commits to merge requests may change the reviewer suggestions which will automatically update in the reviewer dropdown. 
+
+## Progressive enhancement
+
+This feature is designed as a progressive enhancement to the existing GitLab Reviewers functionality. The GitLab Reviewer UI will only offer suggestions if the ML engine is able to provide a recommendation. In the event of an issue or model inference failure, the feature will gracefully degrade. At no point with the usage of Suggested Reviewers prevent a user from being able to manually set a reviewer. 
+
+## Model Accuracy
+
+Organizations use many different processes for code review. Some focus on senior engineers reviewing junior engineer's code, others have hierarchical organizational structure based reviews. Suggested Reviewers is focused on contextual reviewers based on historical merge request activity by users. While we will continue evolving the underlying ML model to better serve various code review use cases and processes Suggested Reviewers does not replace the usage of other code review features like Code Owners and [Approval Rules](../approvals/rules.md). Reviewer selection is highly subjective therefore, we do not expect Suggested Reviewers to provide perfect suggestions everytime. 
+
+Through analysis of beta customer usage, we find that the Suggested Reviewers ML model provides suggestions that are adopted in 60% of cases. We will be introducing a feedback mechanism into the Suggested Reviewers feature in the future to allow users to flag bad reviewer suggestions to help improve the model. Additionally we will be offering an opt-in feature in the future which will allow the model to use your project's data for training the underlying model.
+
+## Off by default
+
+Suggested Reviewers is off by default and requires a Project Owner or Admin to enable the feature. 
+
+## Data privacy
+
+Suggested Reviewers operates completely within the GitLab.com infrastructure providing the same level of [privacy](https://about.gitlab.com/privacy/) and [security](https://about.gitlab.com/security/) of any other feature of GitLab.com. 
+
+No new additional data is collected to enable this feature, simply GitLab is inferencing your merge request against a trained machine learning model. The content of your source code is not used as training data. Your data also never leaves GitLab.com, all training and inference is done within GitLab.com infrastructure.
+
+[Read more about the security of GitLab.com](https://about.gitlab.com/security/faq/)
diff --git a/doc/user/project/merge_requests/reviews/img/suggested_reviewers_v15_4.png b/doc/user/project/merge_requests/reviews/img/suggested_reviewers_v15_4.png
new file mode 100644
index 00000000000..aae75b0736c
--- /dev/null
+++ b/doc/user/project/merge_requests/reviews/img/suggested_reviewers_v15_4.png
diff --git a/doc/user/project/merge_requests/reviews/index.md b/doc/user/project/merge_requests/reviews/index.md
index 78f82b019b8..227f38ad472 100644
--- a/doc/user/project/merge_requests/reviews/index.md
+++ b/doc/user/project/merge_requests/reviews/index.md
@@ -21,6 +21,26 @@ You can review merge requests from the GitLab interface. If you install the
 [GitLab Workflow VS Code extension](../../repository/vscode.md), you can also
 review merge requests in Visual Studio Code.
 
+## Suggested reviewers **(ULTIMATE SAAS)**
+
+> [Introduced](https://gitlab.com/groups/gitlab-org/modelops/applied-ml/review-recommender/-/epics/3) in GitLab 15.4.
+
+GitLab can recommend reviewers with Suggested Reviewers. Using the changes in a merge request and a project's contribution graph, machine learning powered suggestions appear in the reviewer section of the right merge request sidebar. 
+
+![Suggested Reviewers](img/suggested_reviewers_v15_4.png)
+
+This feature is currently in [Open Beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#open-beta) behind a [feature flag](https://gitlab.com/gitlab-org/gitlab/-/issues/368356).
+
+Learn more about [how suggested reviewers works and data privacy](data_usage.md). 
+
+### Enable suggested reviewers
+
+Project Maintainers or Owners can enable suggested reviewers by visiting the [project settings](../../settings/index.md). 
+
+Enabling suggested reviewers will trigger GitLab to create an ML model for your project that will be used to generate reviewers. The larger your project, the longer this can take, but usually, the model will be ready to generate suggestions within a few hours.
+
+No action is required once the feature is enabled. Once the model is ready, recommendations will populate the Reviewer dropdown in the right-hand sidebar of a merge request with new commits. 
+
 ## Review a merge request
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/4213) in GitLab 11.4.
diff --git a/doc/user/tasks.md b/doc/user/tasks.md
index 15abc77ad47..fce16b012d1 100644
--- a/doc/user/tasks.md
+++ b/doc/user/tasks.md
@@ -120,7 +120,12 @@ To change the assignee on a task:
 
 ## Set a start and due date
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/365399) in GitLab 15.4.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/365399) in GitLab 15.4 [with a flag](../administration/feature_flags.md) named `work_items_mvc_2`. Disabled by default.
+
+FLAG:
+On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../administration/feature_flags.md) named `work_items_mvc_2`.
+On GitLab.com, this feature is not available.
+This feature is not ready for production use.
 
 You can set a [start and due date](project/issues/due_dates.md) on a task.
 
diff --git a/spec/services/projects/update_pages_service_spec.rb b/spec/services/projects/update_pages_service_spec.rb
index eea2ea3271f..a69db3b9970 100644
--- a/spec/services/projects/update_pages_service_spec.rb
+++ b/spec/services/projects/update_pages_service_spec.rb
@@ -19,22 +19,34 @@ RSpec.describe Projects::UpdatePagesService do
 
   subject { described_class.new(project, build) }
 
-  context 'when a deploy stage already exists' do
+  context 'when a deploy stage already exists', :aggregate_failures do
     let!(:stage) { create(:ci_stage, name: 'deploy', pipeline: pipeline) }
 
     it 'assigns the deploy stage' do
-      subject.execute
+      expect { subject.execute }
+        .to change(GenericCommitStatus, :count).by(1)
+        .and change(Ci::Stage.where(name: 'deploy'), :count).by(0)
 
-      expect(GenericCommitStatus.last.ci_stage).to eq(stage)
-      expect(GenericCommitStatus.last.ci_stage.name).to eq('deploy')
+      status = GenericCommitStatus.last
+
+      expect(status.ci_stage).to eq(stage)
+      expect(status.ci_stage.name).to eq('deploy')
+      expect(status.stage_name).to eq('deploy')
+      expect(status.stage).to eq('deploy')
     end
   end
 
   context 'when a deploy stage does not exists' do
     it 'assigns the deploy stage' do
-      subject.execute
+      expect { subject.execute }
+        .to change(GenericCommitStatus, :count).by(1)
+        .and change(Ci::Stage.where(name: 'deploy'), :count).by(1)
+
+      status = GenericCommitStatus.last
 
-      expect(GenericCommitStatus.last.ci_stage.name).to eq('deploy')
+      expect(status.ci_stage.name).to eq('deploy')
+      expect(status.stage_name).to eq('deploy')
+      expect(status.stage).to eq('deploy')
     end
   end