Add latest changes from gitlab-org/gitlab@master

11 files changed, 22 insertions, 67 deletions

diff --git a/doc/administration/package_information/licensing.md b/doc/administration/package_information/licensing.md
index 0e46289a308..ece1597c521 100644
--- a/doc/administration/package_information/licensing.md
+++ b/doc/administration/package_information/licensing.md
@@ -25,8 +25,7 @@ Starting with version 9.2, the Omnibus GitLab package ships a
 `dependency_licenses.json` file containing version and license information of
 all bundled software, including software libraries, Ruby gems that the rails
 application uses, and JavaScript libraries that is required for the frontend
-components. This file, being in JSON format, is easily machine parseable and
-can be used for automated checks or validations. The file may be found at
+components. Because it's in JSON format, GitLab can parse this file easily and use it for automated checks or validations. The file may be found at
 `/opt/gitlab/dependency_licenses.json`.
 
 Starting with version 11.3, we have also made the license information available
diff --git a/doc/install/installation.md b/doc/install/installation.md
index 8e8dd4bc7a3..39fb6e3ae95 100644
--- a/doc/install/installation.md
+++ b/doc/install/installation.md
@@ -616,6 +616,7 @@ Install the gems (if you want to use Kerberos for user authentication, omit
 ```shell
 sudo -u git -H bundle config set --local deployment 'true'
 sudo -u git -H bundle config set --local without 'development test mysql aws kerberos'
+sudo -u git -H bundle config path /home/git/gitlab/vendor/bundle
 sudo -u git -H bundle install
 ```
 
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index a6431ee5d3b..1bf6f419ccc 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -989,7 +989,7 @@ WARNING:
 This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
 Review the details carefully before upgrading.
 
-The feature flag `PUSH_RULES_SUPERSEDE_CODE_OWNERS` is being removed in GitLab 15.0. Upon its removal, push rules will supersede CODEOWNERS. The CODEOWNERS feature will no longer be available for access control.
+The feature flag `PUSH_RULES_SUPERSEDE_CODE_OWNERS` is being removed in GitLab 15.0. Upon its removal, push rules will supersede Code Owners. Even if Code Owner approval is required, a push rule that explicitly allows a specific user to push code supersedes the Code Owners setting.
 
 </div>
 
diff --git a/doc/update/index.md b/doc/update/index.md
index c8a6f9be20d..0ef8457a0d8 100644
--- a/doc/update/index.md
+++ b/doc/update/index.md
@@ -1270,7 +1270,6 @@ This issue is resolved in GitLab 15.3.3, so customers with the following configu
 
 ## Miscellaneous
 
-- [Restoring from backup after a failed upgrade](restore_after_failure.md)
 - [Upgrading PostgreSQL Using Slony](upgrading_postgresql_using_slony.md), for
   upgrading a PostgreSQL database with minimal downtime.
 - [Managing PostgreSQL extensions](../install/postgresql_extensions.md)
diff --git a/doc/update/removals.md b/doc/update/removals.md
index 34f60dec249..f71a21c6453 100644
--- a/doc/update/removals.md
+++ b/doc/update/removals.md
@@ -750,7 +750,7 @@ WARNING:
 This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
 Review the details carefully before upgrading.
 
-The `push_rules_supersede_code_owners` feature flag has been removed in GitLab 15.0. From now on, push rules will supersede the `CODEOWNERS` file. The code owners feature is no longer available for access control.
+The `push_rules_supersede_code_owners` feature flag has been removed in GitLab 15.0. From now on, push rules will supersede the `CODEOWNERS` file. Even if Code Owner approval is required, a push rule that explicitly allows a specific user to push code supersedes the Code Owners setting.
 
 ### `type` and `types` keyword from CI/CD configuration
 
diff --git a/doc/update/restore_after_failure.md b/doc/update/restore_after_failure.md
index cc0b188a0f8..92b68410dca 100644
--- a/doc/update/restore_after_failure.md
+++ b/doc/update/restore_after_failure.md
@@ -2,64 +2,11 @@
 stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+remove_date: '2023-02-28'
+redirect_to: '../raketasks/backup_restore.md'
 ---
 
-# Restoring from backup after a failed upgrade **(FREE SELF)**
+# Restoring from backup after a failed upgrade (removed) **(FREE SELF)**
 
-Upgrades are usually smooth and restoring from backup is a rare occurrence.
-However, it's important to know how to recover when problems do arise.
-
-## Roll back to an earlier version and restore a backup
-
-In some cases after a failed upgrade, the fastest solution is to roll back to
-the previous version you were using. We recommend this path because the failed
-upgrade might have made database changes that cannot be readily reverted.
-
-First, roll back the code or package. For source installations this involves
-checking out the older version (branch or tag). For Omnibus installations this
-means installing the older
-[`.deb` or `.rpm` package](https://packages.gitlab.com/gitlab). Then, restore from a
-backup.
-Follow the instructions in the
-[Backup and Restore](../raketasks/backup_restore.md#restore-gitlab)
-documentation.
-
-## Potential problems on the next upgrade
-
-When a rollback is necessary it can produce problems on subsequent upgrade
-attempts. This is because some tables may have been added during the failed
-upgrade. If these tables are still present after you restore from the
-older backup it can lead to migration failures on future upgrades.
-
-We drop all tables prior to importing the backup to prevent this problem.
-
-Example error:
-
-```plaintext
-== 20151103134857 CreateLfsObjects: migrating =================================
--- create_table(:lfs_objects)
-rake aborted!
-StandardError: An error has occurred, this and all later migrations canceled:
-
-PG::DuplicateTable: ERROR:  relation "lfs_objects" already exists
-```
-
-Copy the version from the error. In this case the version number is
-`20151103134857`.
-
-WARNING:
-Use the following steps only if you are certain you must do them.
-
-1. Pass the version to a database Rake task to manually mark the migration as
-   complete.
-
-   ```shell
-   # Source install
-   sudo -u git -H bundle exec rake gitlab:db:mark_migration_complete[20151103134857] RAILS_ENV=production
-
-   # Omnibus install
-   sudo gitlab-rake gitlab:db:mark_migration_complete[20151103134857]
-   ```
-
-1. After the migration is successfully marked, run the Rake `db:migrate` task again.
-1. Repeat this process until all failed migrations are complete.
+This content was removed in GitLab 15.7.
+Use the [backup and restore](../raketasks/backup_restore.md) documentation instead.
diff --git a/doc/user/admin_area/monitoring/background_migrations.md b/doc/user/admin_area/monitoring/background_migrations.md
index f16cb219f2b..1d9d72c152b 100644
--- a/doc/user/admin_area/monitoring/background_migrations.md
+++ b/doc/user/admin_area/monitoring/background_migrations.md
@@ -150,7 +150,7 @@ version and manually ensuring that the batched migrations complete successfully.
 
 #### Roll back and follow the required upgrade path
 
-1. [Rollback and restore the previously installed version](../../../update/restore_after_failure.md#roll-back-to-an-earlier-version-and-restore-a-backup)
+1. [Rollback and restore the previously installed version](../../../raketasks/backup_restore.md)
 1. Update to either 14.0.5 or 14.1 **before** updating to 14.2+
 1. [Check the status](#check-the-status-of-background-migrations) of the batched background migrations and
 make sure they are all marked as finished before attempting to upgrade again. If any remain marked as active,
diff --git a/doc/user/application_security/policies/index.md b/doc/user/application_security/policies/index.md
index 453b815509e..a214d0d2cec 100644
--- a/doc/user/application_security/policies/index.md
+++ b/doc/user/application_security/policies/index.md
@@ -34,6 +34,10 @@ project and the security policy project, this is not recommended. Keeping the se
 project separate from the development project allows for complete separation of duties between
 security/compliance teams and development teams.
 
+You should not link a security policy project to a development project and to the group
+or sub-group the development project belongs to at the same time. Linking this way will result in
+approval rules from the Scan Result Policy not being applied to merge requests in the development project.
+
 All security policies are stored in the `.gitlab/security-policies/policy.yml` YAML file inside the
 linked security policy project. The format for this YAML is specific to the type of policy that is
 stored there. Examples and schema information are available for the following policy types:
diff --git a/doc/user/packages/npm_registry/index.md b/doc/user/packages/npm_registry/index.md
index f82210c0ef5..b1b5e99707b 100644
--- a/doc/user/packages/npm_registry/index.md
+++ b/doc/user/packages/npm_registry/index.md
@@ -192,6 +192,8 @@ When an npm package is not found in the Package Registry, the request is forward
 
 Administrators can disable this behavior in the [Continuous Integration settings](../../admin_area/settings/continuous_integration.md).
 
+Group owners can disable this behavior in the group Packages and Registries settings.
+
 ### Install npm packages from other organizations
 
 You can route package requests to organizations and users outside of GitLab.
diff --git a/doc/user/permissions.md b/doc/user/permissions.md
index d70a1a4ba1d..ea4d1e374fb 100644
--- a/doc/user/permissions.md
+++ b/doc/user/permissions.md
@@ -412,6 +412,7 @@ The following table lists group permissions available for each role:
 | Pull [packages](packages/index.md)                                                      |       | ✓        | ✓         | ✓          | ✓     |
 | Delete [packages](packages/index.md)                                                    |       |          |           | ✓          | ✓     |
 | Create/edit/delete [Maven and generic package duplicate settings](packages/generic_packages/index.md#do-not-allow-duplicate-generic-packages)                                                    |       |          |           | ✓          | ✓     |
+| Enable/disable package request forwarding                                               |       |          |           | ✓          | ✓     |
 | Pull a Container Registry image                                                         | ✓ (6) | ✓        | ✓         | ✓          | ✓     |
 | Remove a Container Registry image                                                       |       |          | ✓         | ✓          | ✓     |
 | View [Group DevOps Adoption](group/devops_adoption/index.md)                            |       | ✓        | ✓         | ✓          | ✓     |
diff --git a/doc/user/project/pages/getting_started/pages_ui.md b/doc/user/project/pages/getting_started/pages_ui.md
index 4fd2ca52fba..a6069b473e6 100644
--- a/doc/user/project/pages/getting_started/pages_ui.md
+++ b/doc/user/project/pages/getting_started/pages_ui.md
@@ -6,9 +6,11 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Create a Pages deployment for your static site **(FREE)**
 
-To generate a GitLab Pages website, you can fill out forms that
-automatically generate a `.gitlab-ci.yml` file and open a
-merge request with your changes. When you commit the merge request,
+If you already have a GitLab project that contains your static site or framework,
+you can generate a GitLab Pages website from it.
+
+When you provide basic information in the UI, a `.gitlab-ci.yml` file is created
+and a merge request opened. When you commit the merge request,
 a pipeline deploys your Pages website.
 
 ## Prerequisites