Add latest changes from gitlab-org/gitlab@master

data/deprecations/16-0-security_report_schemas_v14-x-x.yml

@@ -0,0 +1,27 @@
+#
+# REQUIRED FIELDS
+#
+- name: "Security report schemas version 14.x.x"  # (required) the name of the feature being removed. Avoid the words `deprecation`, `deprecate`, `removal`, and `remove` in this field because these are implied.
+  announcement_milestone: "15.8"  # (required) The milestone when this feature was deprecated.
+  announcement_date: "2023-01-22"  # (required) The date of the milestone release when this feature was deprecated. This should almost always be the 22nd of a month (YYYY-MM-DD), unless you did an out of band blog post.
+  removal_milestone: "16.0"  # (required) The milestone when this feature is being removed.
+  removal_date: "2023-05-22"  # (required) This should almost always be the 22nd of a month (YYYY-MM-DD), the date of the milestone release when this feature will be removed.
+  breaking_change: true  # (required) Change to true if this removal is a breaking change.
+  reporter: matt_wilson  # (required) GitLab username of the person reporting the removal
+  stage: Secure  # (required) String value of the stage that the feature was created in. e.g., Growth
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/366477  # (required) Link to the deprecation issue in GitLab
+  body: |  # (required) Do not modify this line, instead modify the lines below.
+    All [security report schema](https://gitlab.com/gitlab-org/security-products/security-report-schemas) versions before 15.0.0 are considered deprecated in GitLab %15.8. Specifically, all [schemas](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/lib/ee/gitlab/ci/parsers/security/validators/schemas) that match 14.*.* will be deprecated.
+
+    Please note that any [security report scanner integration](https://docs.gitlab.com/ee/development/integrations/secure.html) with GitLab using a deprecated schema version will result in a deprecation warning as a result of [report validation](https://docs.gitlab.com/ee/development/integrations/secure.html#report-validation).
+
+    See [Security report validation](https://docs.gitlab.com/ee/user/application_security/#security-report-validation) for more information.
+#
+# OPTIONAL FIELDS
+#
+  end_of_support_milestone: "15.8" # (optional) Use "XX.YY" format. The milestone when support for this feature will end.
+  end_of_support_date: "2023-01-22" # (optional) The date of the milestone release when support for this feature will end.
+  tiers: [Ultimate] # (optional - may be required in the future) An array of tiers that the feature is available in currently.  e.g., [Free, Silver, Gold, Core, Premium, Ultimate]
+  documentation_url:  # (optional) This is a link to the current documentation page
+  image_url:  # (optional) This is a link to a thumbnail image depicting the feature
+  video_url:  # (optional) Use the youtube thumbnail URL with the structure of https://img.youtube.com/vi/UNIQUEID/hqdefault.jpg

db/post_migrate/20220802114351_reschedule_backfill_container_registry_size_into_project_statistics.rb

@@ -0,0 +1,37 @@
+# frozen_string_literal: true
+
+class RescheduleBackfillContainerRegistrySizeIntoProjectStatistics < Gitlab::Database::Migration[2.0]
+  restrict_gitlab_migration gitlab_schema: :gitlab_main
+
+  DELAY_INTERVAL = 2.minutes.to_i
+  BATCH_SIZE = 500
+  MIGRATION_CLASS = 'BackfillProjectStatisticsContainerRepositorySize'
+  BATCH_CLASS_NAME = 'BackfillProjectStatisticsWithContainerRegistrySizeBatchingStrategy'
+  SUB_BATCH_SIZE = 100
+
+  disable_ddl_transaction!
+
+  def up
+    return unless Gitlab.dev_or_test_env? || Gitlab.com?
+
+    # remove the original migration
+    delete_batched_background_migration(MIGRATION_CLASS, :container_repositories, :project_id, [])
+
+    # reschedule the migration
+    queue_batched_background_migration(
+      MIGRATION_CLASS,
+      :container_repositories,
+      :project_id,
+      job_interval: DELAY_INTERVAL,
+      batch_size: BATCH_SIZE,
+      batch_class_name: BATCH_CLASS_NAME,
+      sub_batch_size: SUB_BATCH_SIZE
+    )
+  end
+
+  def down
+    return unless Gitlab.dev_or_test_env? || Gitlab.com?
+
+    delete_batched_background_migration(MIGRATION_CLASS, :container_repositories, :project_id, [])
+  end
+end

db/schema_migrations/20220802114351

@@ -0,0 +1 @@
+c314412f0c5d4ad9447671a8e03e94af1a1b79718479769f763e20a689ce7d2f

doc/development/code_review.md

@@ -287,10 +287,20 @@ This saves reviewers time and helps authors catch mistakes earlier.
 
 ### The responsibility of the reviewer
 
+Reviewers are responsible for reviewing the specifics of the chosen solution.
+
 [Review the merge request](#reviewing-a-merge-request) thoroughly.
 
 Verify that the merge request meets all [contribution acceptance criteria](contributing/merge_request_workflow.md#contribution-acceptance-criteria).
 
+Some merge requests may require domain experts to help with the specifics.
+Reviewers, if they are not a domain expert in the area, can do any of the following:
+
+- Review the merge request and loop in a domain expert for another review. This expert
+  can either be another reviewer or a maintainer.
+- Pass the review to another reviewer they deem more suitable.
+- If no domain experts are available, review on a best-effort basis.
+
 You should guide the author towards splitting the merge request into smaller merge requests if it is:
 
 - Too large.
@@ -468,6 +478,8 @@ experience, refactors the existing code). Then:
 - Offer alternative implementations, but assume the author already considered
   them. ("What do you think about using a custom validator here?")
 - Seek to understand the author's perspective.
+- Check out the branch, and test the changes locally. You can decide how much manual testing you want to perform.
+  Your testing might result in opportunities to add automated tests.
 - If you don't understand a piece of code, _say so_. There's a good chance
   someone else would be confused by it as well.
 - Ensure the author is clear on what is required from them to address/resolve the suggestion.

doc/install/next_steps.md

@@ -28,7 +28,7 @@ installation.
 
 ## Security
 
-- [Secure GitLab](../security/index.md#securing-your-gitlab-installation):
+- [Secure GitLab](../security/index.md):
   Recommended practices to secure your GitLab instance.
 - Sign up for the GitLab [Security Newsletter](https://about.gitlab.com/company/preference-center/) to get notified for security updates upon release.
 

doc/security/index.md

@@ -28,8 +28,6 @@ type: index
 - [Project Import decompressed archive size limits](project_import_decompressed_archive_size_limits.md)
 - [Responding to security incidents](responding_to_security_incidents.md)
 
-## Securing your GitLab installation
+To harden your GitLab instance and minimize the risk of unwanted user account creation, consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md) .
 
-Consider access control features like [Sign up restrictions](../user/admin_area/settings/sign_up_restrictions.md) and [Authentication options](../topics/authentication/index.md) to harden your GitLab instance and minimize the risk of unwanted user account creation.
-
-Self-hosting GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance.
+Self-managed GitLab customers and administrators are responsible for the security of their underlying hosts, and for keeping GitLab itself up to date. It is important to [regularly patch GitLab](../policy/maintenance.md), patch your operating system and its software, and harden your hosts in accordance with vendor guidance.

doc/update/deprecations.md

@@ -45,6 +45,30 @@ sole discretion of GitLab Inc.
 
 <div class="announcement-milestone">
 
+## Announced in 15.8
+
+<div class="deprecation removal-160 breaking-change">
+
+### Security report schemas version 14.x.x
+
+End of Support: GitLab <span class="removal-milestone">15.8</span> (2023-01-22)
+Planned removal: GitLab <span class="removal-milestone">16.0</span> (2023-05-22)
+
+WARNING:
+This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
+Review the details carefully before upgrading.
+
+All [security report schema](https://gitlab.com/gitlab-org/security-products/security-report-schemas) versions before 15.0.0 are considered deprecated in GitLab %15.8. Specifically, all [schemas](https://gitlab.com/gitlab-org/gitlab/-/tree/master/ee/lib/ee/gitlab/ci/parsers/security/validators/schemas) that match 14.*.* will be deprecated.
+
+Please note that any [security report scanner integration](https://docs.gitlab.com/ee/development/integrations/secure.html) with GitLab using a deprecated schema version will result in a deprecation warning as a result of [report validation](https://docs.gitlab.com/ee/development/integrations/secure.html#report-validation).
+
+See [Security report validation](https://docs.gitlab.com/ee/user/application_security/#security-report-validation) for more information.
+
+</div>
+</div>
+
+<div class="announcement-milestone">
+
 ## Announced in 15.3
 
 <div class="deprecation removal-160 breaking-change">

doc/user/project/integrations/webhooks.md

@@ -137,7 +137,7 @@ For example, to test `push events`, your project should have at least one commit
 
 To test a webhook:
 
-1. In your project, on the left sidebar, select **Settings > Webhooks**.
+1. In your project or group, on the left sidebar, select **Settings > Webhooks**.
 1. Scroll down to the list of configured webhooks.
 1. From the **Test** dropdown list, select the type of event to test.
 
@@ -236,12 +236,14 @@ For more information about supported events for Webhooks, go to [Webhook events]
 
 ## Troubleshoot webhooks
 
+> **Recent events** for group webhooks [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/325642) in GitLab 15.3.
+
 GitLab records the history of each webhook request.
 You can view requests made in the last 2 days in the **Recent events** table.
 
 To view the table:
 
-1. In your project, on the left sidebar, select **Settings > Webhooks**.
+1. In your project or group, on the left sidebar, select **Settings > Webhooks**.
 1. Scroll down to the webhooks.
 1. Each [failing webhook](#failing-webhooks) has a badge listing it as:
 
@@ -261,10 +263,6 @@ The table includes the following details about each request:
 
 ![Recent deliveries](img/webhook_logs.png)
 
-NOTE:
-The **Recent events** table is unavailable for group-level webhooks. For more information, read
-[issue #325642](https://gitlab.com/gitlab-org/gitlab/-/issues/325642).
-
 Each webhook event has a corresponding **Details** page. This page details the data that GitLab sent (request headers and body) and received (response headers and body).
 To view the **Details** page, select **View details** for the webhook event.
 

doc/user/project/merge_requests/status_checks.md

@@ -10,6 +10,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/user/project/merge_requests/statu
 
 > - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/3869) in GitLab 14.0, disabled behind the `:ff_external_status_checks` feature flag.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/320783) in GitLab 14.1.
+> - `failed` status [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/329636) in GitLab 14.9.
 
 You can create a status check that sends merge request data to third-party tools.
 When users create, change, or close merge requests, GitLab sends a notification. The users or automated workflows
@@ -50,9 +51,8 @@ Merge requests return a `409 Conflict` error to any responses that do not refer
 External status checks have the following states:
 
 - `pending` - The default state. No response can been received by the merge request from the external service.
-- `response received` - A response from the external service has been received and approved by it.
-
-Support for adding a `failed` state is tracked [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/338827).
+- `passed` - A response from the external service has been received and approved by it.
+- `failed` - A response from the external service has been received and denied by it.
 
 If something changes outside of GitLab, you can [set the status of an external status check](../../../api/status_checks.md#set-status-of-an-external-status-check)
 using the API. You don't need to wait for a merge request webhook payload to be sent first.
@@ -138,24 +138,18 @@ the status check and it **will not** be recoverable.
 
 ## Status checks widget
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327634) in GitLab 14.1.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/327634) in GitLab 14.1.
+> - UI [updated](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91504) in GitLab 15.2.
 
-The status checks widget displays in merge requests and shows the status of external
-status checks:
+The status checks widget displays in merge requests and displays the following statuses:
 
-![Status checks widget](img/status_checks_widget_passed_v14_0.png)
+- **pending** (**{status-neutral}**), while GitLab waits for a response from an external status check.
+- **success** (**{status-success}**) or **failed** (**{status-failed}**), when GitLab receives a response from an external status check.
 
 An organization might have a policy that does not allow merging merge requests if
 external status checks do not pass. However, the details in the widget are for informational
 purposes only. GitLab does not prevent merging of merge requests that fail status checks.
-
-While GitLab waits for a response from the external status check, the widget shows
-the status checks as `pending`:
-
-![Status checks widget pending](img/status_checks_widget_pending_v14_0.png)
-
-After GitLab [receives a response](../../../api/status_checks.md#set-status-of-an-external-status-check)
-from the external status check, the widget updates accordingly.
+Support to allow merges to be blocked when external status checks fail is proposed in epic [&8516](https://gitlab.com/groups/gitlab-org/-/epics/8516).
 
 NOTE:
 GitLab cannot guarantee that the external status checks are properly processed by

locale/gitlab.pot

@@ -18234,9 +18234,6 @@ msgstr ""
 msgid "Group"
 msgstr ""
 
-msgid "Group \"%{group_name}\" was successfully updated."
-msgstr ""
-
 msgid "Group %{group_name} couldn't be exported."
 msgstr ""
 

spec/migrations/20220802114351_reschedule_backfill_container_registry_size_into_project_statistics_spec.rb

@@ -0,0 +1,41 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+require_migration!
+
+RSpec.describe RescheduleBackfillContainerRegistrySizeIntoProjectStatistics do
+  let_it_be(:batched_migration) { described_class::MIGRATION_CLASS }
+
+  it 'does not schedule background jobs when Gitlab.com is false' do
+    allow(Gitlab).to receive(:com?).and_return(false)
+    allow(Gitlab).to receive(:dev_or_test_env?).and_return(false)
+
+    reversible_migration do |migration|
+      migration.before -> {
+        expect(batched_migration).not_to have_scheduled_batched_migration
+      }
+
+      migration.after -> {
+        expect(batched_migration).not_to have_scheduled_batched_migration
+      }
+    end
+  end
+
+  it 'schedules background jobs for each batch of container_repository' do
+    allow(Gitlab).to receive(:com?).and_return(true)
+
+    reversible_migration do |migration|
+      migration.before -> {
+        expect(batched_migration).not_to have_scheduled_batched_migration
+      }
+
+      migration.after -> {
+        expect(batched_migration).to have_scheduled_batched_migration(
+          table_name: :container_repositories,
+          column_name: :project_id,
+          interval: described_class::DELAY_INTERVAL
+        )
+      }
+    end
+  end
+end