Add latest changes from gitlab-org/gitlab@16-4-stable-eev16.4.0-rc42

18 files changed, 270 insertions, 25 deletions

diff --git a/data/deprecations/14-8-graphql-project-network-policies.yml b/data/deprecations/14-8-graphql-project-network-policies.yml
new file mode 100644
index 00000000000..e9d68987ebe
--- /dev/null
+++ b/data/deprecations/14-8-graphql-project-network-policies.yml
@@ -0,0 +1,9 @@
+- title: "GraphQL networkPolicies resource deprecated"  # (required) Clearly explain the change, or planned change. For example, "The `confidential` field for a `Note` is deprecated" or "CI/CD job names will be limited to 250 characters."
+  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
+  announcement_milestone: "14.8"  # (required) The milestone when this feature was first announced as deprecated.
+  breaking_change: true  # (required) Change to false if this is not a breaking change.
+  reporter: g.hickman  # (required) GitLab username of the person reporting the change
+  stage: Govern  # (required) String value of the stage that the feature was created in. e.g., Growth
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/421440  # (required) Link to the deprecation issue in GitLab
+  body: |  # (required) Do not modify this line, instead modify the lines below.
+    The `networkPolicies` [GraphQL resource](https://docs.gitlab.com/ee/api/graphql/reference/#projectnetworkpolicies) has been deprecated and will be removed in GitLab 17.0. Since GitLab 15.0 this field has returned no data.
diff --git a/data/deprecations/15-0-oauth-noexpiry.yml b/data/deprecations/15-0-oauth-noexpiry.yml
index 1eeb912a588..36f59e90908 100644
--- a/data/deprecations/15-0-oauth-noexpiry.yml
+++ b/data/deprecations/15-0-oauth-noexpiry.yml
@@ -7,7 +7,7 @@
     had no expiration. In GitLab 15.0, an expiry will be automatically generated for any existing token that does not
     already have one.
 
-    You should [opt in](https://docs.gitlab.com/ee/integration/oauth_provider.html#expiring-access-tokens) to expiring
+    You should [opt in](https://docs.gitlab.com/ee/integration/oauth_provider.html#access-token-expiration) to expiring
     tokens before GitLab 15.0 is released:
 
     1. Edit the application.
diff --git a/data/deprecations/15-6-deprecate-runner-reg-token-helm.yml b/data/deprecations/15-6-deprecate-runner-reg-token-helm.yml
index 0882d8ac894..f9409bf4c62 100644
--- a/data/deprecations/15-6-deprecate-runner-reg-token-helm.yml
+++ b/data/deprecations/15-6-deprecate-runner-reg-token-helm.yml
@@ -1,7 +1,7 @@
 - title: "`runnerRegistrationToken` parameter for GitLab Runner Helm Chart"  # (required) The name of the feature to be deprecated
   announcement_milestone: "15.6"  # (required) The milestone when this feature was first announced as deprecated.
-  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
-  removal_date: "2024-04-22"
+  removal_milestone: "18.0"  # (required) The milestone when this feature is planned to be removed
+  removal_date: "2025-04-22"
   breaking_change: true  # (required) If this deprecation is a breaking change, set this value to true
   reporter: pedropombeiro  # (required) GitLab username of the person reporting the deprecation
   stage: Verify  # (required) String value of the stage that the feature was created in. e.g., Growth
@@ -10,8 +10,8 @@
     The [`runnerRegistrationToken`](https://docs.gitlab.com/runner/install/kubernetes.html#required-configuration) parameter to use the GitLab Helm Chart to install a runner on Kubernetes is deprecated.
 
     We plan to implement a new method to bind runners to a GitLab instance leveraging `runnerToken`
-    as part of the new [GitLab Runner token architecture](https://docs.gitlab.com/ee/architecture/blueprints/runner_tokens/).
+    as part of the new [GitLab Runner token architecture](https://docs.gitlab.com/ee/ci/runners/new_creation_workflow.html).
     The work is planned in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/7633).
 
-    From GitLab 17.0 and later, the methods to register runners introduced by the new GitLab Runner token architecture will be the only supported methods.
+    From GitLab 18.0 and later, the methods to register runners introduced by the new GitLab Runner token architecture will be the only supported methods.
   end_of_support_milestone:  # (optional) Use "XX.YY" format. The milestone when support for this feature will end.
diff --git a/data/deprecations/15-6-deprecate-runner-register-command.yml b/data/deprecations/15-6-deprecate-runner-register-command.yml
index 6443580d8f8..4fcde11ce16 100644
--- a/data/deprecations/15-6-deprecate-runner-register-command.yml
+++ b/data/deprecations/15-6-deprecate-runner-register-command.yml
@@ -1,7 +1,7 @@
 - title: "Registration tokens and server-side runner arguments in `gitlab-runner register` command"  # (required) The name of the feature to be deprecated
   announcement_milestone: "15.6"  # (required) The milestone when this feature was first announced as deprecated.
-  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
-  removal_date: "2024-04-22"
+  removal_milestone: "18.0"  # (required) The milestone when this feature is planned to be removed
+  removal_date: "2025-04-22"
   breaking_change: true  # (required) If this deprecation is a breaking change, set this value to true
   reporter: pedropombeiro  # (required) GitLab username of the person reporting the deprecation
   stage: Verify  # (required) String value of the stage that the feature was created in. e.g., Growth
@@ -9,7 +9,7 @@
   body: |  # (required) Do not modify this line, instead modify the lines below.
     Registration tokens and certain configuration arguments in the command `gitlab-runner register` that [registers](https://docs.gitlab.com/runner/register/) a runner, are deprecated.
     Authentication tokens will be used to register runners instead. Registration tokens, and support for certain configuration arguments,
-    will be removed in GitLab 17.0. For more information, see [Migrating to the new runner registration workflow](../ci/runners/new_creation_workflow.md).
+    will be removed in GitLab 18.0. For more information, see [Migrating to the new runner registration workflow](../ci/runners/new_creation_workflow.md).
     The configuration arguments disabled for authentication tokens are:
 
     - `--locked`
diff --git a/data/deprecations/15-6-deprecate-runner-register-token-k8s-operator.yml b/data/deprecations/15-6-deprecate-runner-register-token-k8s-operator.yml
index c4910f72887..5bbe75efa42 100644
--- a/data/deprecations/15-6-deprecate-runner-register-token-k8s-operator.yml
+++ b/data/deprecations/15-6-deprecate-runner-register-token-k8s-operator.yml
@@ -1,14 +1,14 @@
 - title: "GitLab Runner registration token in Runner Operator"  # (required) The name of the feature to be deprecated
   announcement_milestone: "15.6"  # (required) The milestone when this feature was first announced as deprecated.
-  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
-  removal_date: "2024-04-22"
+  removal_milestone: "18.0"  # (required) The milestone when this feature is planned to be removed
+  removal_date: "2025-04-22"
   breaking_change: true  # (required) If this deprecation is a breaking change, set this value to true
   reporter: ratchade  # (required) GitLab username of the person reporting the deprecation
   stage: Verify  # (required) String value of the stage that the feature was created in. e.g., Growth
   issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/382077  # (required) Link to the deprecation issue in GitLab
   body: |  # (required) Do not modify this line, instead modify the lines below.
     The [`runner-registration-token`](https://docs.gitlab.com/runner/install/operator.html#install-the-kubernetes-operator) parameter that uses the OpenShift and Kubernetes Vanilla Operator to install a runner on Kubernetes is deprecated. Authentication tokens will be used to register runners instead. Registration tokens, and support for certain configuration arguments,
-    will be removed in GitLab 17.0. For more information, see [Migrating to the new runner registration workflow](../ci/runners/new_creation_workflow.md).
+    will be removed in GitLab 18.0. For more information, see [Migrating to the new runner registration workflow](../ci/runners/new_creation_workflow.md).
     The configuration arguments disabled for authentication tokens are:
 
     - `--locked`
diff --git a/data/deprecations/15-7-deprecate-api-v4-runner-registration-token-reset-endpoints.yml b/data/deprecations/15-7-deprecate-api-v4-runner-registration-token-reset-endpoints.yml
index d617b5de531..bf383119f9f 100644
--- a/data/deprecations/15-7-deprecate-api-v4-runner-registration-token-reset-endpoints.yml
+++ b/data/deprecations/15-7-deprecate-api-v4-runner-registration-token-reset-endpoints.yml
@@ -1,14 +1,14 @@
 - title: "Support for REST API endpoints that reset runner registration tokens"  # (required) The name of the feature to be deprecated
   announcement_milestone: "15.7"  # (required) The milestone when this feature was first announced as deprecated.
-  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
-  removal_date: "2024-04-22"
+  removal_milestone: "18.0"  # (required) The milestone when this feature is planned to be removed
+  removal_date: "2025-04-22"
   breaking_change: true  # (required) If this deprecation is a breaking change, set this value to true
   reporter: pedropombeiro  # (required) GitLab username of the person reporting the deprecation
   stage: Verify  # (required) String value of the stage that the feature was created in. e.g., Growth
   issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/383341  # (required) Link to the deprecation issue in GitLab
   body: |  # (required) Do not modify this line, instead modify the lines below.
     The support for runner registration tokens is deprecated. As a consequence, the REST API endpoints to reset a registration token are also deprecated and will
-    return the HTTP `410 Gone` status code in GitLab 17.0.
+    return the HTTP `410 Gone` status code in GitLab 18.0.
     The deprecated endpoints are:
 
     - `POST /runners/reset_registration_token`
@@ -16,11 +16,11 @@
     - `POST /groups/:id/runners/reset_registration_token`
 
     We plan to implement a new method to bind runners to a GitLab instance
-    as part of the new [GitLab Runner token architecture](https://docs.gitlab.com/ee/architecture/blueprints/runner_tokens/).
+    as part of the new [GitLab Runner token architecture](https://docs.gitlab.com/ee/ci/runners/new_creation_workflow.html).
     The work is planned in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/7633).
     This new architecture introduces a new method for registering runners and will eliminate the legacy
     [runner registration token](https://docs.gitlab.com/ee/security/token_overview.html#runner-registration-tokens).
-    From GitLab 17.0 and later, the runner registration methods implemented by the new GitLab Runner token architecture will be the only supported methods.
+    From GitLab 18.0 and later, the runner registration methods implemented by the new GitLab Runner token architecture will be the only supported methods.
   end_of_support_milestone:  # (optional) Use "XX.YY" format. The milestone when support for this feature will end.
   tiers:  # (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: https://docs.gitlab.com/ee/api/runners.html#register-a-new-runner  # (optional) This is a link to the current documentation page
diff --git a/data/deprecations/15-9-JWT-OIDC.yml b/data/deprecations/15-9-JWT-OIDC.yml
index 48e1b862032..5ed2b27e539 100644
--- a/data/deprecations/15-9-JWT-OIDC.yml
+++ b/data/deprecations/15-9-JWT-OIDC.yml
@@ -1,7 +1,7 @@
 ---
 - title: "Old versions of JSON web tokens are deprecated"
   announcement_milestone: "15.9"  # (required) The milestone when this feature was first announced as deprecated.
-  removal_milestone: "16.5"  # (required) The milestone when this feature is planned to be removed
+  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
   breaking_change: true  # (required) Change to false if this is not a breaking change.
   reporter: dhershkovitch  # (required) GitLab username of the person reporting the change
   stage: Verify  # (required) String value of the stage that the feature was created in. e.g., Growth
@@ -32,9 +32,9 @@
     - CI/CD jobs that use the `id_tokens` keyword can use ID tokens with `secrets:vault`,
       and will not have any `CI_JOB_JWT*` tokens available.
     - Jobs that do not use the `id_tokens` keyword will continue to have the `CI_JOB_JWT*`
-      tokens available until GitLab 16.5.
+      tokens available until GitLab 17.0.
 
-    In GitLab 16.5, the deprecated tokens will be completely removed and will no longer
+    In GitLab 17.0, the deprecated tokens will be completely removed and will no longer
     be available in CI/CD jobs.
 
 #
diff --git a/data/deprecations/15-9-license-compliance-ci-template.yml b/data/deprecations/15-9-license-compliance-ci-template.yml
index 9b2ab1cbe90..2defcda89ee 100644
--- a/data/deprecations/15-9-license-compliance-ci-template.yml
+++ b/data/deprecations/15-9-license-compliance-ci-template.yml
@@ -6,9 +6,19 @@
   stage: secure
   issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/387561
   body: |
-    **Update:** We previously announced we would remove the existing License Compliance CI template in GitLab 16.0. However, due to performance issues with the [license scanning of CycloneDX files](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/) we will do this change in 16.3 instead.
+    **Update:** We previously announced we would remove the existing License Compliance CI template in GitLab 16.0. However, due to performance issues with the [license scanning of CycloneDX files](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/) we will do this in 16.3 instead.
 
-    The GitLab [License Compliance](https://docs.gitlab.com/ee/user/compliance/license_compliance/) CI template is now deprecated and is scheduled for removal in the GitLab 16.1 release. Users who wish to continue using GitLab for License Compliance should remove the License Compliance template from their CI pipeline and add the [Dependency Scanning template](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuration). The Dependency Scanning template is now capable of gathering the required license information so it is no longer necessary to run a separate License Compliance job. The License Compliance CI template should not be removed prior to verifying that the `license_scanning_sbom_scanner` and `package_metadata_synchronization` flags are enabled for the instance and that the instance has been upgraded to a version that supports [the new method of license scanning](https://docs.gitlab.com/ee/user/compliance/license_scanning_of_cyclonedx_files/).
+    The GitLab [**License Compliance**](https://docs.gitlab.com/ee/user/compliance/license_compliance/) CI/CD template is now deprecated and is scheduled for removal in the GitLab 16.3 release.
+
+    To continue using GitLab for license compliance, remove the **License Compliance** template from your CI/CD pipeline and add the **Dependency Scanning** template. The **Dependency Scanning** template is now capable of gathering the required license information, so it is no longer necessary to run a separate license compliance job.
+
+    Before you remove the **License Compliance** CI/CD template, verify that the instance has been upgraded to a version that supports the new method of license scanning.
+
+    To begin using the Dependency Scanner quickly at scale, you may set up a scan execution policy at the group level to enforce the SBOM-based license scan for all projects in the group. Then, you may remove the inclusion of the `Jobs/License-Scanning.gitlab-ci.yml` template from your CI/CD configuration.
+
+    If you wish to continue using the legacy license compliance feature, you can do so by setting the `LICENSE_MANAGEMENT_VERSION CI` variable to `4`. This variable can be set at the project, group, or instance level. This configuration change will allow you to continue using an existing version of license compliance without having to adopt the new approach.
+
+    Bugs and vulnerabilities in this legacy analyzer will no longer be fixed.
 
     | CI Pipeline Includes | GitLab <= 15.8 | 15.9 <= GitLab < 16.3 | GitLab >= 16.3 |
     | ------------- | ------------- | ------------- | ------------- |
diff --git a/data/deprecations/16-0-Vault-integration.yml b/data/deprecations/16-0-Vault-integration.yml
index 987ac2bed3c..422852a5477 100644
--- a/data/deprecations/16-0-Vault-integration.yml
+++ b/data/deprecations/16-0-Vault-integration.yml
@@ -19,7 +19,7 @@
 #
 - title: "HashiCorp Vault integration will no longer use CI_JOB_JWT by default"
   announcement_milestone: "15.9"  # (required) The milestone when this feature was first announced as deprecated.
-  removal_milestone: "16.5"  # (required) The milestone when this feature is planned to be removed
+  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
   breaking_change: true  # (required) Change to false if this is not a breaking change.
   reporter: dhershkovitch  # (required) GitLab username of the person reporting the change
   stage: Verify  # (required) String value of the stage that the feature was created in. e.g., Growth
@@ -40,7 +40,7 @@
     - CI/CD jobs that use the `id_tokens` keyword can use ID tokens with `secrets:vault`,
       and will not have any `CI_JOB_JWT*` tokens available.
     - Jobs that do not use the `id_tokens` keyword will continue to have the `CI_JOB_JWT*`
-      tokens available until GitLab 16.5.
+      tokens available until GitLab 17.0.
 # If an End of Support period applies, the announcement should be shared with GitLab Support
 # in the `#spt_managers` channel in Slack, and mention `@gitlab-com/support` in this MR.
 #
diff --git a/data/deprecations/16-3-CI-job-token-scope-update.yml b/data/deprecations/16-3-CI-job-token-scope-update.yml
new file mode 100644
index 00000000000..5867cedcc53
--- /dev/null
+++ b/data/deprecations/16-3-CI-job-token-scope-update.yml
@@ -0,0 +1,28 @@
+#
+# REQUIRED FIELDS
+#
+- title: "Job token allowlist covers public and internal projects"  # (required) Clearly explain the change, or planned change. For example, "The `confidential` field for a `Note` is deprecated" or "CI/CD job names will be limited to 250 characters."
+  removal_milestone: "16.6"  # (required) The milestone when this feature is planned to be removed
+  announcement_milestone: "16.3"  # (required) The milestone when this feature was first announced as deprecated.
+  breaking_change: true  # (required) Change to false if this is not a breaking change.
+  reporter: jocelynjane  # (required) GitLab username of the person reporting the change
+  stage: Verify  # (required) String value of the stage that the feature was created in. e.g., Growth
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/420678  # (required) Link to the deprecation issue in GitLab
+  body: |  # (required) Do not modify this line, instead modify the lines below.
+    Starting in 16.6, projects that are **public** or **internal** will no longer authorize job token requests from projects that are **not** on the project's allowlist when [**Limit access to this project**](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-access-to-your-project-with-a-job-token) is enabled.
+
+    If you have [public or internal](https://docs.gitlab.com/ee/user/public_access.html#change-project-visibility) projects with the **Limit access to this project** setting enabled, you must add any projects which make job token requests to your project's allowlist for continued authorization.
+#
+# OPTIONAL END OF SUPPORT FIELDS
+#
+# If an End of Support period applies, the announcement should be shared with GitLab Support
+# in the `#spt_managers` channel in Slack, and mention `@gitlab-com/support` in this MR.
+#
+  end_of_support_milestone:  # (optional) Use "XX.YY" format. The milestone when support for this feature will end.
+  #
+  # OTHER OPTIONAL FIELDS
+  #
+  tiers:  # (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
diff --git a/data/deprecations/16-3-remove-rsa-key-size-larger-than-8k-support.yml b/data/deprecations/16-3-remove-rsa-key-size-larger-than-8k-support.yml
new file mode 100644
index 00000000000..8f6a547a1c1
--- /dev/null
+++ b/data/deprecations/16-3-remove-rsa-key-size-larger-than-8k-support.yml
@@ -0,0 +1,12 @@
+- title: "RSA key size limits"
+  removal_milestone: "16.3"
+  announcement_milestone: "16.3"
+  breaking_change: true
+  reporter: derekferguson
+  stage: Create
+  issue_url: https://gitlab.com/groups/gitlab-org/-/epics/11186
+  body: |  # (required) Do not modify this line, instead modify the lines below.
+    Go versions 1.20.7 and later add a `maxRSAKeySize` constant that limits RSA keys to a maximum of 8192 bits. As a result, RSA keys larger than 8192 bits will no longer work with GitLab. Any RSA keys larger than 8192 bits must be regenerated at a smaller size.
+
+    You might notice this issue because your logs include an error like `tls: server sent certificate containing RSA key larger than 8192 bits`. To test the length of your key, use this command: `openssl rsa -in <your-key-file> -text -noout | grep "Key:"`.
+  documentation_url: https://docs.gitlab.com/ee/user/ssh.html
diff --git a/data/deprecations/16-4-ci_job_token_scope_enabled-attribute-deprecation.yml b/data/deprecations/16-4-ci_job_token_scope_enabled-attribute-deprecation.yml
new file mode 100644
index 00000000000..57e42f17cc8
--- /dev/null
+++ b/data/deprecations/16-4-ci_job_token_scope_enabled-attribute-deprecation.yml
@@ -0,0 +1,26 @@
+#
+# REQUIRED FIELDS
+#
+- title: "The `ci_job_token_scope_enabled` projects API attribute is deprecated"  # (required) Clearly explain the change, or planned change. For example, "The `confidential` field for a `Note` is deprecated" or "CI/CD job names will be limited to 250 characters."
+  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
+  announcement_milestone: "16.4"  # (required) The milestone when this feature was first announced as deprecated.
+  breaking_change: true  # (required) Change to false if this is not a breaking change.
+  reporter: jocelynjane  # (required) GitLab username of the person reporting the change
+  stage: verify  # (required) String value of the stage that the feature was created in. e.g., Growth
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/423091 # (required) Link to the deprecation issue in GitLab
+  body: |  # (required) Do not modify this line, instead modify the lines below.
+    GitLab 16.1 introduced [API endpoints for the job token scope](https://gitlab.com/gitlab-org/gitlab/-/issues/351740). In the [projects API](https://docs.gitlab.com/ee/api/projects.html), the `ci_job_token_scope_enabled` attribute is deprecated, and will be removed in 17.0. You should use the [job token scope APIs](https://docs.gitlab.com/ee/api/project_job_token_scopes.html) instead.
+#
+# OPTIONAL END OF SUPPORT FIELDS
+#
+# If an End of Support period applies, the announcement should be shared with GitLab Support
+# in the `#spt_managers` channel in Slack, and mention `@gitlab-com/support` in this MR.
+#
+  end_of_support_milestone:  # (optional) Use "XX.YY" format. The milestone when support for this feature will end.
+  #
+  # OTHER OPTIONAL FIELDS
+  #
+  tiers:  # (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
diff --git a/data/deprecations/16-4-deprecate-change-vulnerability-status-with-developer-role.yml b/data/deprecations/16-4-deprecate-change-vulnerability-status-with-developer-role.yml
new file mode 100644
index 00000000000..e35c755ba87
--- /dev/null
+++ b/data/deprecations/16-4-deprecate-change-vulnerability-status-with-developer-role.yml
@@ -0,0 +1,11 @@
+- title: "Deprecate change vulnerability status from the Developer role"
+  removal_milestone: "17.0"
+  announcement_milestone: "16.4"
+  breaking_change: true
+  reporter: abellucci
+  stage: govern
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/424133
+  body: |
+    The ability for Developers to change the status of vulnerabilities is now deprecated.  We plan to make a breaking change in the upcoming GitLab 17.0 release to remove this ability from the Developer role.  Users who wish to continue to grant this permission to developers can [create a custom role](https://docs.gitlab.com/ee/user/permissions.html#custom-roles) for their developers and add in the `admin_vulnerability` permission to give them this access.
+  tiers: [Gold, Ultimate]
+  documentation_url: https://docs.gitlab.com/ee/user/permissions.html#custom-roles
diff --git a/data/deprecations/16-4-geo-legacy-component-routes-deprecation.yml b/data/deprecations/16-4-geo-legacy-component-routes-deprecation.yml
new file mode 100644
index 00000000000..83a9882c90f
--- /dev/null
+++ b/data/deprecations/16-4-geo-legacy-component-routes-deprecation.yml
@@ -0,0 +1,17 @@
+#
+# REQUIRED FIELDS
+#
+- title: "Geo: Legacy replication details routes for designs and projects deprecated"  # (required) Clearly explain the change, or planned change. For example, "The `confidential` field for a `Note` is deprecated" or "CI/CD job names will be limited to 250 characters."
+  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
+  announcement_milestone: "16.4"  # (required) The milestone when this feature was first announced as deprecated.
+  breaking_change: true  # (required) Change to false if this is not a breaking change.
+  reporter: sranasinghe  # (required) GitLab username of the person reporting the change
+  stage: enablement  # (required) String value of the stage that the feature was created in. e.g., Growth
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/424002  # (required) Link to the deprecation issue in GitLab
+  body: |  # (required) Do not modify this line, instead modify the lines below.
+    As part of the migration of legacy data types to the [Geo self-service framework](https://docs.gitlab.com/ee/development/geo/framework.html), the following replication details routes are deprecated:
+
+    - Designs `/admin/geo/replication/designs` replaced by `/admin/geo/sites/<Geo Node/Site ID>/replication/design_management_repositories`
+    - Projects `/admin/geo/replication/projects` replaced by `/admin/geo/sites/<Geo Node/Site ID>/replication/projects`
+
+    From GitLab 16.4 to 17.0, lookups for the legacy routes will automatically be redirected to the new routes. We will remove the redirections in 17.0. Please update any bookmarks or scripts that may use the legacy routes.
diff --git a/data/deprecations/16-4_support_for_delete_tags_endpoint.yml b/data/deprecations/16-4_support_for_delete_tags_endpoint.yml
new file mode 100644
index 00000000000..5805653c027
--- /dev/null
+++ b/data/deprecations/16-4_support_for_delete_tags_endpoint.yml
@@ -0,0 +1,21 @@
+- title: "Internal Container Registry API tag deletion endpoint"  # (required) Actionable title. e.g., The `confidential` field for a `Note` is deprecated. Use `internal` instead.
+  announcement_milestone: "16.4"  # (required) The milestone when this feature was first announced as deprecated.
+  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
+  breaking_change: true  # (required) If this deprecation is a breaking change, set this value to true
+  reporter: trizzi  # (required) GitLab username of the person reporting the deprecation
+  stage: Package  # (required) String value of the stage that the feature was created in. e.g., Growth
+  issue_url: https://gitlab.com/gitlab-org/container-registry/-/issues/1094  # (required) Link to the deprecation issue in GitLab
+  body: |  # (required) Do not modify this line, instead modify the lines below.
+    The [Docker Registry HTTP API V2 Spec](https://docs.docker.com/registry/spec/api/), later replaced by the [OCI Distribution Spec](https://github.com/opencontainers/distribution-spec/blob/main/spec.md) did not include a tag delete operation, and an unsafe and slow workaround (involving deleting manifests, not tags) had to be used to achieve the same end.
+
+    Tag deletion is an important function, so we added a tag deletion operation to the GitLab Container Registry, extending the V2 API beyond the scope of the Docker and OCI distribution spec.
+
+    Since then, the OCI Distribution Spec has had some updates and it now has a tag delete operation, using the [`DELETE /v2/<name>/manifests/<tag>` endpoint](https://github.com/opencontainers/distribution-spec/blob/main/spec.md#deleting-tags).
+
+    This leaves the container registry with two endpoints that provide the exact same functionality. `DELETE /v2/<name>/tags/reference/<tag>` is the custom GitLab tag delete endpoint and `DELETE /v2/<name>/manifests/<tag>`, the OCI compliant tag delete endpoint introduced in GitLab 16.4.
+
+    Support for the custom GitLab tag delete endpoint is deprecated in GitLab 16.4, and it will be removed in GitLab 17.0.
+
+    This endpoint is used by the **internal** Container Registry application API, not the public [GitLab Container Registry API](https://docs.gitlab.com/ee/api/container_registry.html). No action should be required by the majority of container registry users. All the GitLab UI and API functionality related to tag deletions will remain intact as we transition to the new OCI-compliant endpoint.
+
+    If you do access the internal container registry API and use the original tag deletion endpoint, you must update to the new endpoint.
diff --git a/data/deprecations/16-5-ci-job-token-limit-setting.yml b/data/deprecations/16-5-ci-job-token-limit-setting.yml
new file mode 100644
index 00000000000..aec19775513
--- /dev/null
+++ b/data/deprecations/16-5-ci-job-token-limit-setting.yml
@@ -0,0 +1,37 @@
+#
+# REQUIRED FIELDS
+#
+- title: "Default CI/CD job token (`CI_JOB_TOKEN`) scope changed"  # (required) Clearly explain the change, or planned change. For example, "The `confidential` field for a `Note` is deprecated" or "CI/CD job names will be limited to 250 characters."
+  announcement_milestone: "15.9"  # (required) The milestone when this feature was first announced as deprecated.
+  removal_milestone: "17.0"  # (required) The milestone when this feature is planned to be removed
+  breaking_change: true  # (required) If this deprecation is a breaking change, set this value to true
+  reporter: jocelynjane  # (required) GitLab username of the person reporting the deprecation
+  stage: Verify  # (required) String value of the stage that the feature was created in. e.g., Growth
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/383084  # (required) Link to the deprecation issue in GitLab
+  body: |  # (required) Do not modify this line, instead modify the lines below.
+    In GitLab 14.4 we introduced the ability to [limit your project's CI/CD job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#limit-your-projects-job-token-access) (`CI_JOB_TOKEN`) access to make it more secure. You can prevent job tokens **from your project's** pipelines from being used to **access other projects**. When enabled with no other configuration, your pipelines cannot access other projects. To use the job token to access other projects from your pipeline, you must list those projects explicitly in the **Limit CI_JOB_TOKEN access** setting's allowlist, and you must be a maintainer in all the projects.
+
+    The job token functionality was updated in 15.9 with a better security setting to [allow access to your project with a job token](https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#allow-access-to-your-project-with-a-job-token). When enabled with no other configuration, job tokens **from other projects** cannot **access your project**. Similar to the older setting, you can optionally allow other projects to access your project with a job token if you list those projects explicitly in the **Allow access to this project with a CI_JOB_TOKEN** setting's allowlist. With this new setting, you must be a maintainer in your own project, but only need to have the Guest role in the other projects.
+
+    The **Limit** setting was deprecated in 16.0 in preference of the better **Allow access** setting and **Limit** setting was disabled by default for all new projects. From this point forward, if the **Limit** setting is disabled in any project, it will not be possible to re-enable this setting in 16.0 or later.
+
+    In 17.0, we will remove the **Limit** setting completely, and set the **Allow access** setting to enabled for all projects. This change ensures a higher level of security between projects. If you currently use the **Limit** setting, you should update your projects to use the **Allow access** setting instead. If other projects access your project with a job token, you must add them to the **Allow access** allowlist.
+
+    To prepare for this change, users on GitLab.com or self-managed GitLab 15.9 or later can enable the **Allow access** setting now and add the other projects. It will not be possible to disable the setting in 17.0 or later.
+
+    In 16.3, the names of these settings were changed to clarify their meanings: the deprecated **Limit CI_JOB_TOKEN access** setting is now called **Limit access _from_ this project**, and the newer **Allow access to this project with a CI_JOB_TOKEN** setting is now called **Limit access _to_ this project**.
+  #
+  # OPTIONAL END OF SUPPORT FIELDS
+  #
+  # If an End of Support period applies, the announcement should be shared with GitLab Support
+  # in the `#spt_managers` channel in Slack, and mention `@gitlab-com/support` in this MR.
+  #
+  end_of_support_milestone:  # (optional) Use "XX.YY" format. The milestone when support for this feature will end.
+  end_of_support_date:  # (optional) The date of the milestone release when support for this feature will end.
+  #
+  # OTHER OPTIONAL FIELDS
+  #
+  tiers:  # (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: "https://docs.gitlab.com/ee/ci/jobs/ci_job_token.html#configure-the-job-token-scope-limit"  # (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
diff --git a/data/whats_new/202212200001_15_07.yml b/data/whats_new/202212200001_15_07.yml
index ebfcc0f16ad..465de395fdb 100644
--- a/data/whats_new/202212200001_15_07.yml
+++ b/data/whats_new/202212200001_15_07.yml
@@ -64,7 +64,7 @@
   release: 15.7
 - name: "Sign commits with your SSH key"
   description: |  # Do not modify this line, instead modify the lines below.
-    Signing commits just got a lot simpler. Use SSH keys [to sign commits](https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/), and provide others with confidence that a **Verified** commit was authored by you.
+    Signing commits just got a lot simpler. Use SSH keys [to sign commits](https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html), and provide others with confidence that a **Verified** commit was authored by you.
 
     Previous methods for signing commits required a GPG key or an X.509 certificate, neither of which can be used to sign in to GitLab. Adding support for commit signing with SSH keys now makes it possible to reuse your authentication key pair to also sign your commits. If you already authenticate into GitLab with an SSH key, add three lines of code to your local Git configuration and all your future commits will be signed.
 
@@ -73,7 +73,7 @@
   self-managed: true
   gitlab-com: true
   available_in: [Free, Premium, Ultimate]
-  documentation_link: https://docs.gitlab.com/ee/user/project/repository/ssh_signed_commits/
+  documentation_link: https://docs.gitlab.com/ee/user/project/repository/signed_commits/ssh.html
   image_url: https://img.youtube.com/vi/IrK83nKi8HA/hqdefault.jpg
   published_at: 2022-12-22
   release: 15.7
diff --git a/data/whats_new/202308220001_16_3.yml b/data/whats_new/202308220001_16_3.yml
new file mode 100644
index 00000000000..0e47c6a2eef
--- /dev/null
+++ b/data/whats_new/202308220001_16_3.yml
@@ -0,0 +1,74 @@
+- name: New velocity metrics in the Value Streams Dashboard
+  description: |  # Do not modify this line, instead modify the lines below.
+    The [Value Streams Dashboard](https://about.gitlab.com/blog/2023/06/12/getting-started-with-value-streams-dashboard/) has been enhanced with new metrics: **Merge request (MR) throughput** and **Total closed issues** (Velocity). In GitLab, **MR throughput** is a count of the number of merge requests merged per month, and **Total closed issues** is the number of flow items closed at a point in time.
+
+    With these metrics, you can identify low or high productivity months and the efficiency of [merge request and code review processes](https://docs.gitlab.com/ee/user/analytics/merge_request_analytics.html). You can then gauge whether the [Value Stream delivery](https://docs.gitlab.com/ee/user/group/value_stream_analytics/) is accelerating or not.
+
+    Over time, the metrics accumulate historical data from MRs and issues. Teams can use the data to determine if delivery rates are accelerating or need improvement, and provide more accurate estimates or forecasts for how much work they can deliver.
+  stage: Plan
+  self-managed: true
+  gitlab-com: true
+  available_in: [Ultimate]
+  documentation_link: https://docs.gitlab.com/ee/user/analytics/value_streams_dashboard.html
+  image_url: https://about.gitlab.com/images/16_3/16.3_vsd.mr_iss.png
+  published_at: 2023-08-22
+  release: 16.3
+
+- name: More powerful GitLab SaaS runners on Linux
+  description: |  # Do not modify this line, instead modify the lines below.
+    Having recently upgraded all of our Linux SaaS runners, we are now introducing `xlarge` and `2xlarge` [SaaS runners on Linux](https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html). Equipped with 16 and 32 vCPUs respectively and fully integrated with GitLab CI/CD, these runners will allow you to build and test your application faster than ever before.
+
+    We are determined to provide the industry's fastest CI/CD build speed and look forward to seeing teams achieve even shorter feedback cycles and ultimately deliver software faster.
+  stage: Verify
+  self-managed: false
+  gitlab-com: true
+  available_in: [Premium, Ultimate]
+  documentation_link: https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html
+  image_url: https://about.gitlab.com/images/16_3/larger-runners.png
+  published_at: 2023-08-22
+  release: 16.3
+
+- name: Additional filtering for scan result policies
+  description: |  # Do not modify this line, instead modify the lines below.
+    Determining which results from a security or compliance scan are actionable is a significant challenge for security and compliance teams. Granular filters for scan result policies will help you cut through the noise to identify which vulnerabilities or violations require your attention the most. These new filters and filter updates will streamline your workflows:
+
+    - Status: Status rule changes introduce more intuitive enforcement of "new" versus "previously existing" vulnerabilities. A new status field `new_needs_triage` allows you to filter only new vulnerabilities that need to be triaged.
+    - Age: Create policies to enforce approvals when a vulnerability is outside of SLA (days, months, or years) based on the detected date.
+    - Fix Available: Narrow the focus of your policy to address dependencies that have a fix available.
+    - False Positive: Filter out false positives that have been detected by our Vulnerability Extraction Tool, for SAST results, and via Rezilion for our Container Scanning and Dependency Scanning results.
+  stage: Govern
+  self-managed: true
+  gitlab-com: true
+  available_in: [Ultimate]
+  documentation_link: https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html
+  image_url: https://about.gitlab.com/images/16_3/security-policy-filters-compressed.png
+  published_at: 2023-08-22
+  release: 16.3
+
+- name: Connect to a workspace with SSH
+  description: |  # Do not modify this line, instead modify the lines below.
+    With workspaces, you can create reproducible, ephemeral, cloud-based runtime environments. Since the feature was introduced in GitLab 16.0, the only way to use a workspace was through the browser-based Web IDE running directly in the environment. The Web IDE, however, might not always be the right tool for you.
+
+    With GitLab 16.3, you can now securely connect to a workspace from your desktop with SSH and use your local tools and extensions. The first iteration supports SSH connections directly in VS Code or from the command line with editors like Vim or Emacs. Support for other editors such as JetBrains IDEs and JupyterLab is proposed in future iterations.
+  stage: Create
+  self-managed: true
+  gitlab-com: true
+  available_in: [Premium, Ultimate]
+  documentation_link: https://docs.gitlab.com/ee/user/workspace/configuration.html#connect-to-a-workspace-with-ssh
+  image_url: https://about.gitlab.com/images/16_3/create-workspace-ssh.png
+  published_at: 2023-08-22
+  release: 16.3
+
+- name: Flux sync status visualization
+  description: |  # Do not modify this line, instead modify the lines below.
+    In previous releases, you probably used `kubectl` or another third-party tool to check the status of your Flux deployments. From GitLab 16.3, you can check your deployments with the environments UI.
+
+    Deployments rely on Flux `Kustomization` and `HelmRelease` resources to gather the status of a given environment, which requires a namespace to be configured for the environment. By default, GitLab searches the `Kustomization` and `HelmRelease` resources for the name of the project slug. You can customize the name GitLab looks for in the environment settings.
+  stage: Deploy
+  self-managed: true
+  gitlab-com: true
+  available_in: [Free, Premium, Ultimate]
+  documentation_link: https://docs.gitlab.com/ee/ci/environments/kubernetes_dashboard.html#flux-sync-status
+  image_url: https://about.gitlab.com/images/16_3/flux-badges.png
+  published_at: 2023-08-22
+  release: 16.3