Add latest changes from gitlab-org/gitlab@master

7 files changed, 201 insertions, 49 deletions

diff --git a/doc/administration/settings/jira_cloud_app_troubleshooting.md b/doc/administration/settings/jira_cloud_app_troubleshooting.md
index 1b6f88d43ae..7bbf232d412 100644
--- a/doc/administration/settings/jira_cloud_app_troubleshooting.md
+++ b/doc/administration/settings/jira_cloud_app_troubleshooting.md
@@ -26,12 +26,16 @@ To resolve this issue, set up [OAuth authentication](jira_cloud_app.md#set-up-oa
 
 ## Manual installation fails
 
-You might get an error if you have installed the GitLab for Jira Cloud app from the official marketplace listing and replaced it with [manual installation](jira_cloud_app.md#install-the-gitlab-for-jira-cloud-app-manually):
+You might see one of the following errors if you have installed the GitLab for Jira Cloud app from the official marketplace listing and replaced it with [manual installation](jira_cloud_app.md#install-the-gitlab-for-jira-cloud-app-manually):
 
 ```plaintext
 The app "gitlab-jira-connect-gitlab.com" could not be installed as a local app as it has previously been installed from Atlassian Marketplace
 ```
 
+```plaintext
+The app host returned HTTP response code 401 when we tried to contact it during installation. Please try again later or contact the app vendor.
+```
+
 To resolve this issue, disable the **Jira Connect Proxy URL** setting.
 
 - In GitLab 15.7:
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 46ddad63360..3701abbc237 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -19166,7 +19166,7 @@ GPG signature for a signed commit.
 | <a id="groupautodevopsenabled"></a>`autoDevopsEnabled` | [`Boolean`](#boolean) | Indicates whether Auto DevOps is enabled for all projects within this group. |
 | <a id="groupavatarurl"></a>`avatarUrl` | [`String`](#string) | Avatar URL of the group. |
 | <a id="groupcontainerrepositoriescount"></a>`containerRepositoriesCount` | [`Int!`](#int) | Number of container repositories in the group. |
-| <a id="groupcontainslockedprojects"></a>`containsLockedProjects` | [`Boolean!`](#boolean) | Includes at least one project where the repository size exceeds the limit. This only applies to namespaces under Project limit enforcement. |
+| <a id="groupcontainslockedprojects"></a>`containsLockedProjects` | [`Boolean`](#boolean) | Includes at least one project where the repository size exceeds the limit. This only applies to namespaces under Project limit enforcement. |
 | <a id="groupcrossprojectpipelineavailable"></a>`crossProjectPipelineAvailable` | [`Boolean!`](#boolean) | Indicates if the cross_project_pipeline feature is available for the namespace. |
 | <a id="groupdependencyproxyblobcount"></a>`dependencyProxyBlobCount` | [`Int!`](#int) | Number of dependency proxy blobs cached in the group. |
 | <a id="groupdependencyproxyblobs"></a>`dependencyProxyBlobs` | [`DependencyProxyBlobConnection`](#dependencyproxyblobconnection) | Dependency Proxy blobs. (see [Connections](#connections)) |
@@ -19191,7 +19191,7 @@ GPG signature for a signed commit.
 | <a id="groupfullpath"></a>`fullPath` | [`ID!`](#id) | Full path of the namespace. |
 | <a id="groupgooglecloudloggingconfigurations"></a>`googleCloudLoggingConfigurations` | [`GoogleCloudLoggingConfigurationTypeConnection`](#googlecloudloggingconfigurationtypeconnection) | Google Cloud logging configurations that receive audit events belonging to the group. (see [Connections](#connections)) |
 | <a id="groupid"></a>`id` | [`ID!`](#id) | ID of the namespace. |
-| <a id="groupistemporarystorageincreaseenabled"></a>`isTemporaryStorageIncreaseEnabled` **{warning-solid}** | [`Boolean!`](#boolean) | **Deprecated** in 16.7. Feature removal, will be completely removed in 17.0. |
+| <a id="groupistemporarystorageincreaseenabled"></a>`isTemporaryStorageIncreaseEnabled` **{warning-solid}** | [`Boolean`](#boolean) | **Deprecated** in 16.7. Feature removal, will be completely removed in 17.0. |
 | <a id="grouplfsenabled"></a>`lfsEnabled` | [`Boolean`](#boolean) | Indicates if Large File Storage (LFS) is enabled for namespace. |
 | <a id="groupmentionsdisabled"></a>`mentionsDisabled` | [`Boolean`](#boolean) | Indicates if a group is disabled from getting mentioned. |
 | <a id="groupname"></a>`name` | [`String!`](#string) | Name of the namespace. |
@@ -19201,7 +19201,7 @@ GPG signature for a signed commit.
 | <a id="grouppendingmembers"></a>`pendingMembers` **{warning-solid}** | [`PendingGroupMemberConnection`](#pendinggroupmemberconnection) | **Introduced** in 16.6. This feature is an Experiment. It can be changed or removed at any time. A pending membership of a user within this group. |
 | <a id="groupprojectcreationlevel"></a>`projectCreationLevel` | [`String`](#string) | Permission level required to create projects in the group. |
 | <a id="grouprecentissueboards"></a>`recentIssueBoards` | [`BoardConnection`](#boardconnection) | List of recently visited boards of the group. Maximum size is 4. (see [Connections](#connections)) |
-| <a id="grouprepositorysizeexcessprojectcount"></a>`repositorySizeExcessProjectCount` | [`Int!`](#int) | Number of projects in the root namespace where the repository size exceeds the limit. This only applies to namespaces under Project limit enforcement. |
+| <a id="grouprepositorysizeexcessprojectcount"></a>`repositorySizeExcessProjectCount` | [`Int`](#int) | Number of projects in the root namespace where the repository size exceeds the limit. This only applies to namespaces under Project limit enforcement. |
 | <a id="grouprequestaccessenabled"></a>`requestAccessEnabled` | [`Boolean`](#boolean) | Indicates if users can request access to namespace. |
 | <a id="grouprequiretwofactorauthentication"></a>`requireTwoFactorAuthentication` | [`Boolean`](#boolean) | Indicates if all users in this group are required to set up two-factor authentication. |
 | <a id="grouprootstoragestatistics"></a>`rootStorageStatistics` | [`RootStorageStatistics`](#rootstoragestatistics) | Aggregated storage statistics of the namespace. Only available for root namespaces. |
@@ -22962,19 +22962,19 @@ Product analytics events for a specific month and year.
 | <a id="namespaceactualrepositorysizelimit"></a>`actualRepositorySizeLimit` | [`Float`](#float) | Size limit for repositories in the namespace in bytes. This limit only applies to namespaces under Project limit enforcement. |
 | <a id="namespaceactualsizelimit"></a>`actualSizeLimit` | [`Float`](#float) | The actual storage size limit (in bytes) based on the enforcement type of either repository or namespace. This limit is agnostic of enforcement type. |
 | <a id="namespaceadditionalpurchasedstoragesize"></a>`additionalPurchasedStorageSize` | [`Float`](#float) | Additional storage purchased for the root namespace in bytes. |
-| <a id="namespacecontainslockedprojects"></a>`containsLockedProjects` | [`Boolean!`](#boolean) | Includes at least one project where the repository size exceeds the limit. This only applies to namespaces under Project limit enforcement. |
+| <a id="namespacecontainslockedprojects"></a>`containsLockedProjects` | [`Boolean`](#boolean) | Includes at least one project where the repository size exceeds the limit. This only applies to namespaces under Project limit enforcement. |
 | <a id="namespacecrossprojectpipelineavailable"></a>`crossProjectPipelineAvailable` | [`Boolean!`](#boolean) | Indicates if the cross_project_pipeline feature is available for the namespace. |
 | <a id="namespacedescription"></a>`description` | [`String`](#string) | Description of the namespace. |
 | <a id="namespacedescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | GitLab Flavored Markdown rendering of `description`. |
 | <a id="namespacefullname"></a>`fullName` | [`String!`](#string) | Full name of the namespace. |
 | <a id="namespacefullpath"></a>`fullPath` | [`ID!`](#id) | Full path of the namespace. |
 | <a id="namespaceid"></a>`id` | [`ID!`](#id) | ID of the namespace. |
-| <a id="namespaceistemporarystorageincreaseenabled"></a>`isTemporaryStorageIncreaseEnabled` **{warning-solid}** | [`Boolean!`](#boolean) | **Deprecated** in 16.7. Feature removal, will be completely removed in 17.0. |
+| <a id="namespaceistemporarystorageincreaseenabled"></a>`isTemporaryStorageIncreaseEnabled` **{warning-solid}** | [`Boolean`](#boolean) | **Deprecated** in 16.7. Feature removal, will be completely removed in 17.0. |
 | <a id="namespacelfsenabled"></a>`lfsEnabled` | [`Boolean`](#boolean) | Indicates if Large File Storage (LFS) is enabled for namespace. |
 | <a id="namespacename"></a>`name` | [`String!`](#string) | Name of the namespace. |
 | <a id="namespacepackagesettings"></a>`packageSettings` | [`PackageSettings`](#packagesettings) | Package settings for the namespace. |
 | <a id="namespacepath"></a>`path` | [`String!`](#string) | Path of the namespace. |
-| <a id="namespacerepositorysizeexcessprojectcount"></a>`repositorySizeExcessProjectCount` | [`Int!`](#int) | Number of projects in the root namespace where the repository size exceeds the limit. This only applies to namespaces under Project limit enforcement. |
+| <a id="namespacerepositorysizeexcessprojectcount"></a>`repositorySizeExcessProjectCount` | [`Int`](#int) | Number of projects in the root namespace where the repository size exceeds the limit. This only applies to namespaces under Project limit enforcement. |
 | <a id="namespacerequestaccessenabled"></a>`requestAccessEnabled` | [`Boolean`](#boolean) | Indicates if users can request access to namespace. |
 | <a id="namespacerootstoragestatistics"></a>`rootStorageStatistics` | [`RootStorageStatistics`](#rootstoragestatistics) | Aggregated storage statistics of the namespace. Only available for root namespaces. |
 | <a id="namespacesharedrunnerssetting"></a>`sharedRunnersSetting` | [`SharedRunnersSetting`](#sharedrunnerssetting) | Shared runners availability for the namespace and its descendants. |
diff --git a/doc/api/packages/terraform-modules.md b/doc/api/packages/terraform-modules.md
index 3645fc03e9a..079b7652e67 100644
--- a/doc/api/packages/terraform-modules.md
+++ b/doc/api/packages/terraform-modules.md
@@ -208,6 +208,8 @@ X-Terraform-Get: /api/v4/packages/terraform/modules/v1/group/hello-world/local/1
 
 ## Download module
 
+### From a namespace
+
 ```plaintext
 GET packages/terraform/modules/v1/:module_namespace/:module_name/:module_system/:module_version/file
 ```
@@ -229,6 +231,29 @@ To write the output to file:
 curl --header "Authorization: Bearer <personal_access_token>" "https://gitlab.example.com/api/v4/packages/terraform/modules/v1/group/hello-world/local/1.0.0/file" --output hello-world-local.tgz
 ```
 
+### From a project
+
+```plaintext
+GET /projects/:id/packages/terraform/modules/:module_name/:module_system/:module_version
+```
+
+| Attribute | Type | Required | Description |
+| --------- | ---- | -------- | ----------- |
+| `id` | integer/string | yes | The ID or URL-encoded path of the project. |
+| `module_name` | string | yes | The module name. |
+| `module_system` | string | yes | The name of the module system or [provider](https://www.terraform.io/registry/providers). |
+| `module_version` | string | no | Specific module version to download. If omitted, the latest version is downloaded. |
+
+```shell
+curl --user "<username>:<personal_access_token>" "https://gitlab.example.com/api/v4/projects/1/packages/terraform/modules/hello-world/local/1.0.0"
+```
+
+To write the output to file:
+
+```shell
+curl --user "<username>:<personal_access_token>" "https://gitlab.example.com/api/v4/projects/1/packages/terraform/modules/hello-world/local/1.0.0" --output hello-world-local.tgz
+```
+
 ## Upload module
 
 ```plaintext
diff --git a/doc/development/feature_flags/index.md b/doc/development/feature_flags/index.md
index 17dd8432f7b..965b3bd86aa 100644
--- a/doc/development/feature_flags/index.md
+++ b/doc/development/feature_flags/index.md
@@ -7,7 +7,7 @@ info: "See the Technical Writers assigned to Development Guidelines: https://han
 # Feature flags in the development of GitLab
 
 NOTE:
-This document explains how to contribute to the development of the GitLab product.
+This document explains how to contribute to the development and operations of the GitLab product.
 If you want to use feature flags to show and hide functionality in your own applications,
 view [this feature flags information](../../operations/feature_flags.md) instead.
 
@@ -17,6 +17,11 @@ All newly-introduced feature flags should be [disabled by default](https://about
 WARNING:
 All newly-introduced feature flags should be [used with an actor](controls.md#percentage-based-actor-selection).
 
+Blueprints:
+
+- (Latest) [Feature Flags usage in GitLab development and operations](../../architecture/blueprints/feature_flags_usage_in_dev_and_ops/index.md)
+- [Development Feature Flags Architecture](../../architecture/blueprints/feature_flags_development/index.md)
+
 This document is the subject of continued work as part of an epic to [improve internal usage of feature flags](https://gitlab.com/groups/gitlab-org/-/epics/3551). Raise any suggestions as new issues and attach them to the epic.
 
 For an [overview of the feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#feature-flag-lifecycle), or if you need help deciding [if you should use a feature flag](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags) or not, see the [feature flag lifecycle](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/) handbook page.
@@ -44,77 +49,147 @@ should be leveraged:
 When the feature implementation is delivered over multiple merge requests:
 
 1. [Create a new feature flag](#create-a-new-feature-flag)
-   which is **off** by default, in the first merge request which uses the flag.
-   Flags [should not be added separately](#risk-of-a-broken-main-branch).
+   which is **disabled** by default, in the first merge request which uses the flag.
+   Flags [should not be added separately](#risk-of-a-broken-default-branch).
 1. Submit incremental changes via one or more merge requests, ensuring that any
-   new code added can only be reached if the feature flag is **on**.
+   new code added can only be reached if the feature flag is **enabled**.
    You can keep the feature flag enabled on your local GDK during development.
 1. When the feature is ready to be tested by other team members, [create the initial documentation](../documentation/feature_flags.md#when-to-document-features-behind-a-feature-flag).
    Include details about the status of the [feature flag](../documentation/feature_flags.md#how-to-add-feature-flag-documentation).
-1. Enable the feature flag for a specific project and ensure that there are no issues
+1. Enable the feature flag for a specific group/project/user and ensure that there are no issues
    with the implementation. Do not enable the feature flag for a public project
-   like `gitlab` if there is no documentation. Team members and contributors might search for
+   like `gitlab-org/gitlab` if there is no documentation. Team members and contributors might search for
    documentation on how to use the feature if they see it enabled in a public project.
 1. When the feature is ready for production use, open a merge request to:
    - Update the documentation to describe the latest flag status.
    - Add a [changelog entry](#changelog).
-   - Flip the feature flag to be **on by default** or remove it entirely
-     to enable the new behavior.
+   - Remove the feature flag to enable the new behavior, or flip the feature flag to be **enabled by default** (only for `ops` and `beta` feature flags).
 
 One might be tempted to think that feature flags will delay the release of a
 feature by at least one month (= one release). This is not the case. A feature
 flag does not have to stick around for a specific amount of time
 (for example, at least one release), instead they should stick around until the feature
-is deemed stable. Stable means it works on GitLab.com without causing any
-problems, such as outages.
+is deemed stable. **Stable means it works on GitLab.com without causing any
+problems, such as outages.**
 
-## Risk of a broken main branch
+## Risk of a broken default branch
 
 Feature flags must be used in the MR that introduces them. Not doing so causes a
-[broken main branch](https://about.gitlab.com/handbook/engineering/workflow/#broken-master) scenario due
-to the `rspec:feature-flags` job that only runs on the `main` branch.
+[broken default branch](https://about.gitlab.com/handbook/engineering/workflow/#broken-master) scenario due
+to the `rspec:feature-flags` job that only runs on the default branch.
 
 ## Types of feature flags
 
 Choose a feature flag type that matches the expected usage.
 
-### `development` type
+### `gitlab_com_derisk` type
+
+`gitlab_com_derisk` feature flags are short-lived feature flags,
+used to de-risk GitLab.com deployments. Most feature flags used at
+GitLab are of the `gitlab_com_derisk` type.
+
+#### Constraints
+
+- `default_enabled`: **Must not** be set to true. This kind of feature flag is meant to lower the risk on GitLab.com, thus there's no need to keep the flag in the codebase after it's been enabled on GitLab.com. `default_enabled: true` will not have any effect for this type of feature flag.
+- Maximum Lifespan: 2 months after it's merged into the default branch
+- Documentation: This type of feature flag don't need to be documented in the
+  [All feature flags in GitLab](../../user/feature_flags.md) page given they're short-lived and deployment-related
+- Rollout issue: **Must** have a rollout issue created from the
+  [Feature flag Roll Out template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20Flag%20Roll%20Out.md)
 
-`development` feature flags are short-lived feature flags,
-used for deploying unfinished code to production. Most feature flags used at
-GitLab are the `development` type.
+#### Usage
 
-A `development` feature flag must have a rollout issue
-created from the [Feature flag Roll Out template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20Flag%20Roll%20Out.md).
+The format for `gitlab_com_derisk` feature flags is `Feature.<state>(:<dev_flag_name>)`.
 
-The format for `development` feature flags is `Feature.<state>(:<dev_flag_name>)`.
 To enable and disable them, run on the GitLab Rails console:
 
 ```ruby
 # To enable it for the instance:
-Feature.enable(:<dev_flag_name>)
+Feature.enable(:<dev_flag_name>, type: :gitlab_com_derisk)
 
 # To disable it for the instance:
-Feature.disable(:<dev_flag_name>)
+Feature.disable(:<dev_flag_name>, type: :gitlab_com_derisk)
 
 # To enable for a specific project:
-Feature.enable(:<dev_flag_name>, Project.find(<project id>))
+Feature.enable(:<dev_flag_name>, Project.find(<project id>), type: :gitlab_com_derisk)
 
 # To disable for a specific project:
-Feature.disable(:<dev_flag_name>, Project.find(<project id>))
+Feature.disable(:<dev_flag_name>, Project.find(<project id>), type: :gitlab_com_derisk)
 ```
 
-To check a `development` feature flag's state:
+To check a `gitlab_com_derisk` feature flag's state:
 
 ```ruby
 # Check if the feature flag is enabled
-Feature.enabled?(:dev_flag_name)
+Feature.enabled?(:dev_flag_name, type: :gitlab_com_derisk)
 
 # Check if the feature flag is disabled
-Feature.disabled?(:dev_flag_name)
+Feature.disabled?(:dev_flag_name, type: :gitlab_com_derisk)
+```
+
+### `wip` type
+
+Some features are complex and need to be implemented through several MRs. Until they're fully implemented,
+it needs to be hidden from anyone. In that case, the `wip` (for "Work In Progress") feature flag allows
+to merge all the changes to the main branch without actually using the feature yet.
+
+Once the feature is complete, the feature flag type can be changed to the `gitlab_com_derisk` or
+`beta` type depending on how the feature will be presented/documented to customers.
+
+#### Constraints
+
+- `default_enabled`: **Must not** be set to true. If needed, this type can be changed to beta once the feature is complete.
+- Maximum Lifespan: 4 months after it's merged into the default branch
+- Documentation: This type of feature flag don't need to be documented in the
+  [All feature flags in GitLab](../../user/feature_flags.md) page given they're mostly hiding unfinished code
+- Rollout issue: Likely no need for a rollout issues, as `wip` feature flags should be transitioned to
+  another type before being enabled
+
+#### Usage
+
+```ruby
+# Check if feature flag is enabled
+Feature.enabled?(:my_wip_flag, project, type: :wip)
+
+# Check if feature flag is disabled
+Feature.disabled?(:my_wip_flag, project, type: :wip)
+
+# Push feature flag to Frontend
+push_frontend_feature_flag(:my_wip_flag, project, type: :wip)
 ```
 
-For `development` feature flags, the type doesn't need to be specified (they're the default type).
+### `beta` type
+
+We might
+[not be confident we'll be able to scale, support, and maintain a feature](https://about.gitlab.com/handbook/product/gitlab-the-product/#experiment-beta-ga)
+in its current form for every designed use case ([example](https://gitlab.com/gitlab-org/gitlab/-/issues/336070#note_1523983444)).
+There are also scenarios where a feature is not complete enough to be considered an MVC.
+Providing a flag in this case allows engineers and customers to disable the new feature until it's performant enough.
+
+#### Constraints
+
+- `default_enabled`: Can be set to `true` so that a feature can be "released" to everyone in Beta with the
+  possibility to disable it in the case of scalability issues (ideally it should only be disabled for this
+  reason on specific on-premise installations)
+- Maximum Lifespan: 6 months after it's merged into the default branch
+- Documentation: This type of feature flag **must** be documented in the
+  [All feature flags in GitLab](../../user/feature_flags.md) page
+- Rollout issue: **Must** have a rollout issue
+  created from the
+  [Feature flag Roll Out template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20Flag%20Roll%20Out.md)
+
+#### Usage
+
+```ruby
+# Check if feature flag is enabled
+Feature.enabled?(:my_beta_flag, project, type: :beta)
+
+# Check if feature flag is disabled
+Feature.disabled?(:my_beta_flag, project, type: :beta)
+
+# Push feature flag to Frontend
+push_frontend_feature_flag(:my_beta_flag, project, type: :beta)
+```
 
 ### `ops` type
 
@@ -122,10 +197,20 @@ For `development` feature flags, the type doesn't need to be specified (they're
 of GitLab product behavior. For example, feature flags that disable features that might
 have a performance impact such as Sidekiq worker behavior.
 
-`ops` feature flags likely do not have rollout issues, as it is hard to
-predict when they are enabled or disabled.
+Remember that using this type should follow a conscious decision not to introduce an
+instance/group/project/user setting.
+
+#### Constraints
+
+- `default_enabled`: Can be set to `true` so that a feature can be "released" to everyone in Beta with the
+  possibility to disable it in the case of scalability issues (ideally it should only be disabled for this
+  reason on specific on-premise installations)
+- Maximum Lifespan: Unlimited
+- Documentation: This type of feature flag **must** be documented in the
+  [All feature flags in GitLab](../../user/feature_flags.md) page
+- Rollout issue: Likely no need for a rollout issues, as it is hard to predict when they are enabled or disabled
 
-To invoke `ops` feature flags, you must append `type: :ops`:
+#### Usage
 
 ```ruby
 # Check if feature flag is enabled
@@ -142,18 +227,27 @@ push_frontend_feature_flag(:my_ops_flag, project, type: :ops)
 
 `experiment` feature flags are used for A/B testing on GitLab.com.
 
-An `experiment` feature flag should conform to the same standards as a `development` feature flag,
+An `experiment` feature flag should conform to the same standards as a `beta` feature flag,
 although the interface has some differences. An experiment feature flag should have a rollout issue,
 created using the [Experiment Tracking template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Experiment%20Rollout.md). More information can be found in the [experiment guide](../experiment_guide/index.md).
 
+#### Constraints
+
+- `default_enabled`: **Must not** be set to `true`.
+- Maximum Lifespan: 6 months after it's merged into the default branch
+
 ### `worker` type
 
-`worker` feature flags are used for controlling Sidekiq workers behavior, such as deferring Sidekiq jobs.
+`worker` feature flags are special `ops` flags that allow to control Sidekiq workers behavior, such as deferring Sidekiq jobs.
 
 `worker` feature flags likely do not have any YAML definition as the name could be dynamically generated using
 the worker name itself, for example, `run_sidekiq_jobs_AuthorizedProjectsWorker`. Some examples for using `worker` type feature
 flags can be found in [deferring Sidekiq jobs](#deferring-sidekiq-jobs).
 
+### [Deprecated]`development` type
+
+The `development` type is deprecated in favor of the `gitlab_com_derisk`, `wip`, and `beta` feature flag types.
+
 ## Feature flag definition and validation
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/229161) in GitLab 13.3.
@@ -179,10 +273,11 @@ Each feature flag is defined in a separate YAML file consisting of a number of f
 | `name`              | yes      | Name of the feature flag.                                      |
 | `type`              | yes      | Type of feature flag.                                          |
 | `default_enabled`   | yes      | The default state of the feature flag.                         |
-| `introduced_by_url` | no       | The URL to the merge request that introduced the feature flag. |
+| `introduced_by_url` | yes      | The URL to the merge request that introduced the feature flag. |
+| `milestone`         | yes      | Milestone in which the feature flag was created. |
+| `group`             | yes      | The [group](https://about.gitlab.com/handbook/product/categories/#devops-stages) that owns the feature flag. |
+| `feature_issue_url` | no       | The URL to the original feature issue.                         |
 | `rollout_issue_url` | no       | The URL to the Issue covering the feature flag rollout.        |
-| `milestone`         | no       | Milestone in which the feature flag was created. |
-| `group`             | no       | The [group](https://about.gitlab.com/handbook/product/categories/#devops-stages) that owns the feature flag. |
 
 NOTE:
 All validations are skipped when running in `RAILS_ENV=production`.
diff --git a/doc/development/work_items.md b/doc/development/work_items.md
index 0c3bc4611f5..7fc0c0d9d21 100644
--- a/doc/development/work_items.md
+++ b/doc/development/work_items.md
@@ -245,7 +245,8 @@ Keep the following in mind when you write your migration:
     necessary if the new work item type is going to use the `Hierarchy` widget. In this table, you must add what
     work item type can have children and of what type. Also, you should specify the hierarchy depth for work items of the same
     type. By default a cross-hierarchy (cross group or project) relationship is disabled when creating new restrictions but
-    it can be enabled by specifying a value for `cross_hierarchy_enabled`.
+    it can be enabled by specifying a value for `cross_hierarchy_enabled`. Due to the restrictions being cached for the work item type, it's also
+    required to call `clear_reactive_cache!` on the associated work item types.
 - Optional. Create linked item restrictions.
   - Similarly to the `Hierarchy` widget, the `Linked items` widget also supports rules defining which work item types can be
     linked to other types. A restriction can specify if the source type can be related to or blocking a target type. Current restrictions:
diff --git a/doc/user/packages/terraform_module_registry/index.md b/doc/user/packages/terraform_module_registry/index.md
index 2c9576bf9f7..8612acc37cb 100644
--- a/doc/user/packages/terraform_module_registry/index.md
+++ b/doc/user/packages/terraform_module_registry/index.md
@@ -163,7 +163,9 @@ Prerequisites:
 
 - You need to [authenticate with the API](../../../api/rest/index.md#authentication). If authenticating with a personal access token, it must be configured with the `read_api` scope.
 
-Authentication tokens (Job Token or Personal Access Token) can be provided for `terraform` in your `~/.terraformrc` or `%APPDATA%/terraform.rc` file:
+### From a namespace
+
+You can provide authentication tokens (job tokens, personal access tokens, or deploy tokens) for `terraform` in your `~/.terraformrc` or `%APPDATA%/terraform.rc` file:
 
 ```terraform
 credentials "gitlab.com" {
@@ -183,6 +185,30 @@ module "<module>" {
 
 Where `<namespace>` is the [namespace](../../../user/namespace/index.md) of the Terraform Module Registry.
 
+### From a project
+
+To reference a Terraform module using a project-level source, use the [fetching archives over HTTP](https://developer.hashicorp.com/terraform/language/modules/sources#fetching-archives-over-http) source type provided by Terraform.
+
+You can provide authentication tokens (job tokens, personal access tokens, or deploy tokens) for `terraform` in your `~/.netrc` file:
+
+```netrc
+machine gitlab.com
+login <USERNAME>
+password <TOKEN>
+```
+
+Where `gitlab.com` can be replaced with the hostname of your self-managed GitLab instance, and `<USERNAME>` is your token username.
+
+You can refer to your Terraform module from a downstream Terraform project:
+
+```terraform
+module "<module>" {
+  source = "https://gitlab.com/api/v4/projects/<project-id>/packages/terraform/modules/<module-name>/<module-system>/<module-version>"
+}
+```
+
+If you need to reference the latest version of a module, you can omit the `<module-version>` from the source URL. To prevent future issues, you should reference a specific version if possible.
+
 ## Download a Terraform module
 
 To download a Terraform module:
diff --git a/doc/user/project/pages/pages_access_control.md b/doc/user/project/pages/pages_access_control.md
index 1c7aa0f182c..07b41f391ba 100644
--- a/doc/user/project/pages/pages_access_control.md
+++ b/doc/user/project/pages/pages_access_control.md
@@ -48,7 +48,8 @@ can access the website.
 To sign out of your GitLab Pages website, revoke the application access token
 for GitLab Pages:
 
-1. In the top menu, select your profile, and then select **Settings**.
-1. On the left sidebar, select **Applications**.
-1. Scroll to the **Authorized applications** section, find the **GitLab Pages**
-   entry, and select its **Revoke** button.
+1. On the left sidebar, select your avatar.
+1. Select **Edit profile**.
+1. Select **Applications**.
+1. In the **Authorized applications** section, find the **GitLab Pages**
+   entry, and select **Revoke**.