Add latest changes from gitlab-org/gitlab@master

3 files changed, 21 insertions, 4 deletions

diff --git a/data/deprecations/15-8-third-party-registries.yml b/data/deprecations/15-8-third-party-registries.yml
index 6eb49f1dd26..6d583cd3d19 100644
--- a/data/deprecations/15-8-third-party-registries.yml
+++ b/data/deprecations/15-8-third-party-registries.yml
@@ -6,7 +6,11 @@
   stage: Package  # (required) String value of the stage that the feature was created in. e.g., Growth
   issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/376216  # (required) Link to the deprecation issue in GitLab
   body: |  # (required) Do not modify this line, instead modify the lines below.
-    Using third-party container registries is deprecated in GitLab 15.8 and the end of support is scheduled for GitLab 16.0. Supporting both GitLab's Container Registry and third-party container registries is challenging for maintenance, code quality, and backward compatibility. This hinders our ability to stay [efficient](https://about.gitlab.com/handbook/values/#efficiency).
+    Using third-party container registries with GitLab as an auth endpoint is deprecated in GitLab 15.8 and the [end of support](https://docs.gitlab.com/ee/development/deprecation_guidelines/#terminology) is scheduled for GitLab 16.0. This impacts self-managed customers that have connected their external registry to the GitLab user interface to find, view, and delete container images.
+
+    Supporting both GitLab's Container Registry as well as third-party container registries is challenging for maintenance, code quality, and backward compatibility. This hinders our ability to stay [efficient](https://about.gitlab.com/handbook/values/#efficiency). As a result we will not support this functionality moving forward.
+
+    This change will not impact your ability to pull and push container images to external registries using pipelines.
 
     Since we released the new [GitLab Container Registry](https://gitlab.com/groups/gitlab-org/-/epics/5523) version for GitLab.com, we've started to implement additional features that are not available in third-party container registries. These new features have allowed us to achieve significant performance improvements, such as [cleanup policies](https://gitlab.com/groups/gitlab-org/-/epics/8379). We are focusing on delivering [new features](https://gitlab.com/groups/gitlab-org/-/epics/5136), most of which will require functionalities only available on the GitLab Container Registry. This deprecation allows us to reduce fragmentation and user frustration in the long term by focusing on delivering a more robust integrated registry experience and feature set.
 
diff --git a/data/deprecations/15-9-license-compliance-ci-template.yml b/data/deprecations/15-9-license-compliance-ci-template.yml
index 7fd6a348915..edce1062883 100644
--- a/data/deprecations/15-9-license-compliance-ci-template.yml
+++ b/data/deprecations/15-9-license-compliance-ci-template.yml
@@ -1,14 +1,16 @@
 - title: "License Compliance CI Template"
   announcement_milestone: "15.9"
-  removal_milestone: "16.0"
+  removal_milestone: "16.1"
   breaking_change: true
   reporter: sam.white
   stage: secure
   issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/387561
   body: |
-    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.0 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/).
+    **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.1 instead.
 
-    | CI Pipeline Includes | GitLab <= 15.8 | 15.9 <= GitLab < 16.0 | GitLab >= 16.0 |
+    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/).
+
+    | CI Pipeline Includes | GitLab <= 15.8 | 15.9 <= GitLab < 16.1 | GitLab >= 16.1 |
     | ------------- | ------------- | ------------- | ------------- |
     | Both DS and LS templates | License data from LS job is used | License data from LS job is used | License data from DS job is used |
     | DS template is included but LS template is not | No license data | License data from DS job is used | License data from DS job is used |
diff --git a/data/removals/16_0/16-0-conan-search-limited-to-project.yml b/data/removals/16_0/16-0-conan-search-limited-to-project.yml
new file mode 100644
index 00000000000..bf77ca38ba0
--- /dev/null
+++ b/data/removals/16_0/16-0-conan-search-limited-to-project.yml
@@ -0,0 +1,11 @@
+# REQUIRED FIELDS
+#
+- title: Conan project-level search returns only project-specific results"  # (required) Clearly explain the change. For example, "The `confidential` field for a `Note` is removed" or "CI/CD job names are limited to 250 characters."
+  announcement_milestone: "15.8"  # (required) The milestone when this feature was deprecated.
+  removal_milestone: "16.0"  # (required) The milestone when this feature is being removed.
+  breaking_change: true  # (required) Change to false if this is not a breaking change.
+  reporter: trizzi  # (required) GitLab username of the person reporting the removal
+  stage: Package  # (required) String value of the stage that the feature was created in. e.g., Growth
+  issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/384455  # (required) Link to the deprecation issue in GitLab
+  body: |  # (required) Do not modify this line, instead modify the lines below.
+    The [GitLab Conan repository](https://docs.gitlab.com/ee/user/packages/conan_repository/) supports the `conan search` command, but when searching a project-level endpoint, instance-level Conan packages could have been returned. This unintended functionality is removed in GitLab 16.0. The search endpoint for the project level now only returns packages from the target project.