Merge branch 'msj-remove-expired-docs' into 'master'

Delete docs marked for removal

See merge request https://gitlab.com/gitlab-org/gitlab/-/merge_requests/138503



Merged-by: Russell Dickenson <rdickenson@gitlab.com>
Approved-by: Russell Dickenson <rdickenson@gitlab.com>
Co-authored-by: Marcin Sedlak-Jakubowski <msedlakjakubowski@gitlab.com>

doc/administration/packages/container_registry.md

@@ -647,11 +647,6 @@ you can pull from the container registry, but you cannot push.
 
 > The default configuration for the storage driver is scheduled to be [changed](https://gitlab.com/gitlab-org/container-registry/-/issues/854) in GitLab 16.0.
 
-<!--- start_remove The following content will be removed on remove_date: '2023-10-22' -->
-WARNING:
-The default configuration for the storage driver is scheduled to be [changed](https://gitlab.com/gitlab-org/container-registry/-/issues/854) in GitLab 16.0. The storage driver will use `/` as the default root directory. You can add `trimlegacyrootprefix: false` to your current configuration now to avoid any disruptions. For more information, see the [container registry configuration](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/upstream-differences.md#azure-storage-driver) documentation.
-<!--- end_remove -->
-
 When moving from an existing file system or another object storage provider to Azure Object Storage, you must configure the registry to use the standard root directory.
 Configure it by setting [`trimlegacyrootprefix: true`](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/upstream-differences.md#azure-storage-driver) in the Azure storage driver section of the registry configuration.
 Without this configuration, the Azure storage driver uses `//` instead of `/` as the first section of the root path, rendering the migrated images inaccessible.

doc/ci/yaml/artifacts_reports.md

@@ -286,17 +286,6 @@ concatenate them into a single file. Use either:
 - A combination of both (`junit: [rspec.xml, test-results/TEST-*.xml]`).
 - Directories are not supported(`junit: test-results`, `junit: test-results/**`).
 
-<!--- start_remove The following content will be removed on remove_date: '2023-11-22' -->
-
-## `artifacts:reports:license_scanning` **(ULTIMATE ALL)**
-
-The license scanning report was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387561)
-in GitLab 15.9 and [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/421363) in GitLab 16.3.
-You should instead migrate to use [License approval policies](../../user/compliance/license_approval_policies.md) and
-the [new method of license scanning](../../user/compliance/license_scanning_of_cyclonedx_files/index.md).
-
-<!--- end_remove -->
-
 ## `artifacts:reports:load_performance` **(PREMIUM ALL)**
 
 The `load_performance` report collects [Load Performance Testing metrics](../testing/load_performance_testing.md).

doc/topics/autodevops/cloud_deployments/auto_devops_with_eks.md

@@ -178,8 +178,6 @@ The jobs are separated into stages:
   - Jobs suffixed with `-sast` run static analysis on the current code to check for potential
     security issues, and are allowed to fail ([Auto SAST](../stages.md#auto-sast))
   - The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](../stages.md#auto-secret-detection))
-  - The `license_scanning` job is deprecated and does not produce any results. It is allowed to fail
-    ([Auto License Compliance](../stages.md#auto-license-compliance-deprecated))
 
 - **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job.
   To learn more, see [Dynamic Application Security Testing (DAST)](../../../user/application_security/dast/index.md).

doc/topics/autodevops/cloud_deployments/auto_devops_with_gke.md

@@ -182,8 +182,6 @@ The jobs are separated into stages:
   - Jobs suffixed with `-sast` run static analysis on the current code to check for potential
     security issues, and are allowed to fail ([Auto SAST](../stages.md#auto-sast))
   - The `secret-detection` job checks for leaked secrets and is allowed to fail ([Auto Secret Detection](../stages.md#auto-secret-detection))
-  - The `license_scanning` job is deprecated and does not produce any results. It is allowed to fail
-    ([Auto License Compliance](../stages.md#auto-license-compliance-deprecated))
 
 - **Review** - Pipelines on the default branch include this stage with a `dast_environment_deploy` job.
   For more information, see [Dynamic Application Security Testing (DAST)](../../../user/application_security/dast/index.md).

doc/topics/autodevops/index.md

@@ -37,7 +37,6 @@ Auto DevOps supports development during each of the [DevOps stages](stages.md).
 | Test | [Auto Code Intelligence](stages.md#auto-code-intelligence) |
 | Test | [Auto Code Quality](stages.md#auto-code-quality) |
 | Test | [Auto Container Scanning](stages.md#auto-container-scanning) |
-| Test | [Auto License Compliance](stages.md#auto-license-compliance-deprecated) |
 | Deploy | [Auto Review Apps](stages.md#auto-review-apps) |
 | Deploy | [Auto Deploy](stages.md#auto-deploy) |
 | Secure | [Auto Dynamic Application Security Testing (DAST)](stages.md#auto-dast) |

doc/topics/autodevops/stages.md

@@ -240,18 +240,6 @@ check out. The merge request widget displays any security warnings detected,
 For more information, see
 [Dependency Scanning](../../user/application_security/dependency_scanning/index.md).
 
-<!--- start_remove The following content will be removed on remove_date: '2023-11-22' -->
-
-## Auto License Compliance (deprecated) **(ULTIMATE ALL)**
-
-This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/387561) in GitLab 15.9,
-in GitLab 16.3 we [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/421363) support for the License Compliance report.
-Auto License Compliance is still present in the pipeline, but won't produce any results.
-
-Use Auto Dependency Scanning instead.
-
-<!--- end_remove -->
-
 ## Auto Container Scanning
 
 Vulnerability static analysis for containers uses [Trivy](https://aquasecurity.github.io/trivy/latest/)

doc/user/compliance/license_scanning_of_cyclonedx_files/index.md

@@ -11,7 +11,20 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/385176) in GitLab 16.4. Feature flags `license_scanning_sbom_scanner` and `package_metadata_synchronization` removed.
 
 NOTE:
-The legacy License Compliance analyzer was deprecated in GitLab 15.9 and removed in GitLab 16.3. To continue using GitLab for License Compliance, remove the License Compliance template from your CI/CD pipeline and add the [Dependency Scanning template](../../application_security/dependency_scanning/index.md#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/CD template should not be removed prior to verifying 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](../../application_security/policies/scan-execution-policies.md) 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](../../../ci/variables/index.md#for-a-project), [group](../../../ci/variables/index.md#for-a-group) or [instance](../../../ci/variables/index.md#for-an-instance) level. This configuration change will allow you to continue using the existing version of License Compliance to generate [license scanning report](../../../ci/yaml/artifacts_reports.md#artifactsreportslicense_scanning) artifacts in your pipelines. However, since legacy license scanning support is being removed from our codebase, switching back to this legacy analyzer prevents other License Compliance features from working as expected, so this approach is not recommended. In addition to this, **bugs and vulnerabilities in this legacy analyzer will no longer be fixed.**
+The legacy License Compliance analyzer was deprecated in GitLab 15.9 and removed in GitLab 16.3.
+To continue using GitLab for License Compliance, remove the License Compliance template from your
+CI/CD pipeline and add the [Dependency Scanning template](../../application_security/dependency_scanning/index.md#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/CD
+template should not be removed prior to verifying 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](../../application_security/policies/scan-execution-policies.md)
+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](../../../ci/variables/index.md#for-a-project), [group](../../../ci/variables/index.md#for-a-group)
+or [instance](../../../ci/variables/index.md#for-an-instance) level.
 
 To detect the licenses in use, License Compliance relies on running the
 [Dependency Scanning CI Jobs](../../application_security/dependency_scanning/index.md),

doc/user/packages/container_registry/authenticate_with_container_registry.md

@@ -6,11 +6,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Authenticate with the container registry **(FREE ALL)**
 
-<!--- start_remove The following content will be removed on remove_date: '2023-11-22' -->
-WARNING:
-In GitLab 16.0 and later, [external authorization](../../../administration/settings/external_authorization.md) prevents personal access tokens and deploy tokens from accessing container and package registries and affects all users who use these tokens to access the registries. You can disable external authorization if you want to use personal access tokens and deploy tokens with the container or package registries.
-<!--- end_remove -->
-
 To authenticate with the container registry, you can use a:
 
 - [Personal access token](../../profile/personal_access_tokens.md).

doc/user/packages/package_registry/index.md

@@ -43,11 +43,6 @@ For information on how to create and upload a package, view the GitLab documenta
 
 ## Authenticate with the registry
 
-<!--- start_remove The following content will be removed on remove_date: '2023-11-22' -->
-WARNING:
-In GitLab 16.0 and later, [external authorization](../../../administration/settings/external_authorization.md) prevents personal access tokens and deploy tokens from accessing container and package registries and affects all users who use these tokens to access the registries. You can disable external authorization if you want to use personal access tokens and deploy tokens with the container or package registries.
-<!--- end_remove -->
-
 Authentication depends on the package manager being used. For more information, see the docs on the
 specific package format you want to use.