Add latest changes from gitlab-org/gitlab@master

6 files changed, 225 insertions, 175 deletions

diff --git a/doc/ci/components/index.md b/doc/ci/components/index.md
index 377a9a2147d..881cb931a0a 100644
--- a/doc/ci/components/index.md
+++ b/doc/ci/components/index.md
@@ -19,7 +19,7 @@ A components repository is a GitLab project with a repository that hosts one or
 A pipeline component is a reusable single pipeline configuration unit. You can use them to compose
 an entire pipeline configuration or a small part of a larger pipeline.
 
-A component can optionally take [input parameters](../yaml/includes.md#define-input-parameters-with-specinputs).
+A component can optionally take [input parameters](../yaml/inputs.md).
 
 ## Create a components repository
 
@@ -289,7 +289,7 @@ stage is set to a specific value, the pipeline using the component **must** defi
 the exact same stage. Additionally, if the component user wants to use a different stage,
 they must [override](../yaml/includes.md#override-included-configuration-values) the configuration.
 
-The preferred method is to use the [`input` keyword](../yaml/includes.md#define-input-parameters-with-specinputs).
+The preferred method is to use the [`input` keyword](../yaml/inputs.md).
 The component user can specify the exact value they need.
 
 For example:
diff --git a/doc/ci/yaml/includes.md b/doc/ci/yaml/includes.md
index bc95baeebb1..f0e5a475838 100644
--- a/doc/ci/yaml/includes.md
+++ b/doc/ci/yaml/includes.md
@@ -566,175 +566,6 @@ When the pipeline runs, GitLab:
   include: 'configs/**/*.yml'
   ```
 
-## Define inputs for configuration added with `include` **(BETA)**
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/391331) in GitLab 15.11 as a Beta feature.
-
-FLAG:
-`spec` and `with` are experimental [Open Beta features](../../policy/experiment-beta-support.md#beta)
-and subject to change without notice.
-
-### Define input parameters with `spec:inputs`
-
-Use `spec:inputs` to define input parameters for CI/CD configuration intended to be added
-to a pipeline with `include`. Use [`include:inputs`](#set-input-parameter-values-with-includeinputs)
-to define the values to use when the pipeline runs.
-
-The specs must be declared at the top of the configuration file, in a header section.
-Separate the header from the rest of the configuration with `---`.
-
-Use the interpolation format `$[[ input.input-id ]]` to reference the values outside of the header section.
-The inputs are evaluated and interpolated once, when the configuration is fetched
-during pipeline creation, but before the configuration is merged with the contents of the `.gitlab-ci.yml`.
-
-```yaml
-spec:
-  inputs:
-    environment:
-    job-stage:
----
-
-scan-website:
-  stage: $[[ inputs.job-stage ]]
-  script: ./scan-website $[[ inputs.environment ]]
-```
-
-When using `spec:inputs`:
-
-- Defined inputs are mandatory by default.
-- Inputs can be made optional by specifying a `default`. Use `default: null` to have no default value.
-- A string containing an interpolation block must not exceed 1 MB.
-- The string inside an interpolation block must not exceed 1 KB.
-
-For example, a `custom_configuration.yml`:
-
-```yaml
-spec:
-  inputs:
-    website:
-    user:
-      default: 'test-user'
-    flags:
-      default: null
----
-
-# The pipeline configuration would follow...
-```
-
-In this example:
-
-- `website` is mandatory and must be defined.
-- `user` is optional. If not defined, the value is `test-user`.
-- `flags` is optional. If not defined, it has no value.
-
-### Specify functions to manipulate input values
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/409462) in GitLab 16.3.
-
-You can specify predefined functions in the interpolation block to manipulate the input value.
-The format supported is the following:
-
-```yaml
-$[[ input.input-id | <function1> | <function2> | ... <functionN> ]]
-```
-
-Details:
-
-- Only [predefined interpolation functions](#predefined-interpolation-functions) are permitted.
-- A maximum of 3 functions may be specified in a single interpolation block.
-- The functions are executed in the sequence they are specified.
-
-```yaml
-spec:
-  inputs:
-    test:
-      default: '0123456789'
----
-
-test-job:
-  script: echo $[[ inputs.test | truncate(1,3) ]]
-```
-
-In this example:
-
-- The function [`truncate`](#truncate) applies to the value of `inputs.test`.
-- Assuming the value of `inputs.test` is `0123456789`, then the output of `script` would be `echo 123`.
-
-### Predefined interpolation functions
-
-#### Truncate
-
-Use `truncate` to shorten the interpolated value. For example:
-
-- `truncate(<offset>,<length>)`
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| `offset` | Integer | Number of characters to offset by. |
-| `length` | Integer | Number of characters to return after the offset. |
-
-Example:
-
-```yaml
-$[[ inputs.test | truncate(3,5) ]]
-```
-
-Assuming the value of `inputs.test` is `0123456789`, then the output would be `34567`.
-
-### Set input parameter values with `include:inputs`
-
-> `include:with` [renamed to `include:inputs`](https://gitlab.com/gitlab-org/gitlab/-/issues/406780) in GitLab 16.0.
-
-Use `include:inputs` to set the values for the parameters when the included configuration
-is added to the pipeline.
-
-For example, to include a `custom_configuration.yml` that has the same specs
-as the [example above](#define-input-parameters-with-specinputs):
-
-```yaml
-include:
-  - local: 'custom_configuration.yml'
-    inputs:
-      website: "My website"
-```
-
-In this example:
-
-- `website` has a value of `My website` for the included configuration.
-- `user` has a value of `test-user`, because that is the default when not specified.
-- `flags` has no value, because it is optional and has no default when not specified.
-
-### Use `include:inputs` with multiple files
-
-`inputs` must be specified separately for each included file. For example:
-
-```yaml
-include:
-  - component: gitlab.com/org/my-component@1.0
-    inputs:
-      stage: my-stage
-  - local: path/to/file.yml
-    inputs:
-      stage: my-stage
-```
-
-You can also include the same file multiple times, with different inputs.
-For example:
-
-```yaml
-include:
-  - local: path/to/my-super-linter.yml
-    inputs:
-      type: docs
-      job-name: lint-docs
-      lint-path: "doc/"
-  - local: path/to/my-super-linter.yml
-    inputs:
-      type: yaml
-      job-name: lint-yaml
-      lint-path: "data/yaml/"
-```
-
 ## Troubleshooting
 
 ### `Maximum of 150 nested includes are allowed!` error
diff --git a/doc/ci/yaml/inputs.md b/doc/ci/yaml/inputs.md
new file mode 100644
index 00000000000..1af53d666ce
--- /dev/null
+++ b/doc/ci/yaml/inputs.md
@@ -0,0 +1,174 @@
+---
+stage: Verify
+group: Pipeline Authoring
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Define inputs for configuration added with `include` **(FREE ALL BETA)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/391331) in GitLab 15.11 as a Beta feature.
+
+FLAG:
+`spec` and `inputs` are experimental [Open Beta features](../../policy/experiment-beta-support.md#beta)
+and subject to change without notice.
+
+## Define input parameters with `spec:inputs`
+
+Use `spec:inputs` to define input parameters for CI/CD configuration intended to be added
+to a pipeline with `include`. Use [`include:inputs`](#set-input-parameter-values-with-includeinputs)
+to define the values to use when the pipeline runs.
+
+The specs must be declared at the top of the configuration file, in a header section.
+Separate the header from the rest of the configuration with `---`.
+
+Use the interpolation format `$[[ input.input-id ]]` to reference the values outside of the header section.
+The inputs are evaluated and interpolated once, when the configuration is fetched
+during pipeline creation, but before the configuration is merged with the contents of the `.gitlab-ci.yml`.
+
+```yaml
+spec:
+  inputs:
+    environment:
+    job-stage:
+---
+
+scan-website:
+  stage: $[[ inputs.job-stage ]]
+  script: ./scan-website $[[ inputs.environment ]]
+```
+
+When using `spec:inputs`:
+
+- Defined inputs are mandatory by default.
+- Inputs can be made optional by specifying a `default`. Use `default: null` to have no default value.
+- A string containing an interpolation block must not exceed 1 MB.
+- The string inside an interpolation block must not exceed 1 KB.
+
+For example, a `custom_configuration.yml`:
+
+```yaml
+spec:
+  inputs:
+    website:
+    user:
+      default: 'test-user'
+    flags:
+      default: null
+---
+
+# The pipeline configuration would follow...
+```
+
+In this example:
+
+- `website` is mandatory and must be defined.
+- `user` is optional. If not defined, the value is `test-user`.
+- `flags` is optional. If not defined, it has no value.
+
+## Set input parameter values with `include:inputs`
+
+> `include:with` [renamed to `include:inputs`](https://gitlab.com/gitlab-org/gitlab/-/issues/406780) in GitLab 16.0.
+
+Use `include:inputs` to set the values for the parameters when the included configuration
+is added to the pipeline.
+
+For example, to include a `custom_configuration.yml` that has the same specs
+as the [example above](#define-input-parameters-with-specinputs):
+
+```yaml
+include:
+  - local: 'custom_configuration.yml'
+    inputs:
+      website: "My website"
+```
+
+In this example:
+
+- `website` has a value of `My website` for the included configuration.
+- `user` has a value of `test-user`, because that is the default when not specified.
+- `flags` has no value, because it is optional and has no default when not specified.
+
+### Use `include:inputs` with multiple files
+
+`inputs` must be specified separately for each included file. For example:
+
+```yaml
+include:
+  - component: gitlab.com/org/my-component@1.0
+    inputs:
+      stage: my-stage
+  - local: path/to/file.yml
+    inputs:
+      stage: my-stage
+```
+
+You can also include the same file multiple times, with different inputs.
+For example:
+
+```yaml
+include:
+  - local: path/to/my-super-linter.yml
+    inputs:
+      type: docs
+      job-name: lint-docs
+      lint-path: "doc/"
+  - local: path/to/my-super-linter.yml
+    inputs:
+      type: yaml
+      job-name: lint-yaml
+      lint-path: "data/yaml/"
+```
+
+## Specify functions to manipulate input values
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/409462) in GitLab 16.3.
+
+You can specify predefined functions in the interpolation block to manipulate the input value.
+The format supported is the following:
+
+```yaml
+$[[ input.input-id | <function1> | <function2> | ... <functionN> ]]
+```
+
+Details:
+
+- Only [predefined interpolation functions](#predefined-interpolation-functions) are permitted.
+- A maximum of 3 functions may be specified in a single interpolation block.
+- The functions are executed in the sequence they are specified.
+
+```yaml
+spec:
+  inputs:
+    test:
+      default: '0123456789'
+---
+
+test-job:
+  script: echo $[[ inputs.test | truncate(1,3) ]]
+```
+
+In this example:
+
+- The function [`truncate`](#truncate) applies to the value of `inputs.test`.
+- Assuming the value of `inputs.test` is `0123456789`, then the output of `script` would be `echo 123`.
+
+### Predefined interpolation functions
+
+#### `truncate`
+
+Use `truncate` to shorten the interpolated value. For example:
+
+- `truncate(<offset>,<length>)`
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| `offset` | Integer | Number of characters to offset by. |
+| `length` | Integer | Number of characters to return after the offset. |
+
+Example:
+
+```yaml
+$[[ inputs.test | truncate(3,5) ]]
+```
+
+Assuming the value of `inputs.test` is `0123456789`, then the output would be `34567`.
diff --git a/doc/update/deprecations.md b/doc/update/deprecations.md
index 73c4812fe37..90ffea90406 100644
--- a/doc/update/deprecations.md
+++ b/doc/update/deprecations.md
@@ -565,6 +565,32 @@ In GitLab 16.0 and later:
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### Internal Container Registry API tag deletion endpoint
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">16.4</span>
+- Removal in GitLab <span class="milestone">17.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/container-registry/-/issues/1094).
+</div>
+
+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.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### Maintainer role providing the ability to change Package settings using GraphQL API
 
 <div class="deprecation-notes">
@@ -876,6 +902,20 @@ Due to limited customer usage and capabilities, the Visual Reviews feature for R
 
 <div class="deprecation breaking-change" data-milestone="17.0">
 
+### The `ci_job_token_scope_enabled` projects API attribute is deprecated
+
+<div class="deprecation-notes">
+- Announced in GitLab <span class="milestone">16.4</span>
+- Removal in GitLab <span class="milestone">17.0</span> ([breaking change](https://docs.gitlab.com/ee/update/terminology.html#breaking-change))
+- To discuss this change or learn more, see the [deprecation issue](https://gitlab.com/gitlab-org/gitlab/-/issues/423091).
+</div>
+
+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.
+
+</div>
+
+<div class="deprecation breaking-change" data-milestone="17.0">
+
 ### The `gitlab-runner exec` command is deprecated
 
 <div class="deprecation-notes">
diff --git a/doc/user/project/codeowners/index.md b/doc/user/project/codeowners/index.md
index c77efaab2ea..d783471f0da 100644
--- a/doc/user/project/codeowners/index.md
+++ b/doc/user/project/codeowners/index.md
@@ -239,7 +239,7 @@ In this example:
 - `@database-team` and `@agarcia` own all items in the `Database` section except
   `config/db/database-setup.md`, which has an override assigning it to `@docs-team`.
 
-Compare this behavior by using [regular entries and sections together](#use-regular-entries-and-sections-together),
+Compare this behavior to when you use [regular entries and sections together](#use-regular-entries-and-sections-together),
 when entries in sections don't override entries without sections.
 
 #### Use default owners and optional sections together
@@ -286,7 +286,7 @@ In this example:
 - A merge request that modifies `model/db/CHANGELOG.txt` would require three approvals: one from each
   of the `@general-approvers`,`@docs-team`, and `@database-team` groups.
 
-Compare this behavior by using only [default owners for sections](#set-default-owner-for-a-section),
+Compare this behavior to when you use only [default owners for sections](#set-default-owner-for-a-section),
 when specific entries within a section override the section default.
 
 #### Sections with duplicate names
diff --git a/doc/user/project/description_templates.md b/doc/user/project/description_templates.md
index 4f2228ab172..97b350c8692 100644
--- a/doc/user/project/description_templates.md
+++ b/doc/user/project/description_templates.md
@@ -118,10 +118,15 @@ that you can use when creating a new project in the instance.
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/52360) in GitLab 13.9.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/321247) in GitLab 14.0.
 
-With **group-level** description templates, you can select a repository within the group to store
-your templates. Then, you can access these templates from other projects in the group.
+With **group-level** description templates, you can select a project within the group to store
+your templates. Then, you can access these templates in other projects in the group.
 As a result, you can use the same templates in issues and merge requests in all the group's projects.
 
+Prerequisites:
+
+- You must have the Owner role for the group.
+- The project must be a direct child of the group.
+
 To re-use templates [you've created](../project/description_templates.md#create-an-issue-template):
 
 1. On the left sidebar, select **Search or go to** and find your group.