@@ -101,7 +101,7 @@ with [domain expertise](#domain-experts).
1. If your merge request includes frontend changes (*1*), it must be
**approved by a [frontend maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_frontend)**.
1. If your merge request includes user-facing changes (*3*), it must be
**approved by a [Product Designer](https://about.gitlab.com/handbook/engineering/ux/product-design/)**,
**approved by a [Product Designer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_reviewers_UX)**,
based on assignments in the appropriate [DevOps stage group](https://about.gitlab.com/handbook/product/categories/#devops-stages).
1. If your merge request includes adding a new JavaScript library (*1*)...
- If the library significantly increases the
...
...
@@ -114,8 +114,8 @@ with [domain expertise](#domain-experts).
1. If your merge request includes a new dependency or a file system change, it must be
**approved by a [Distribution team member](https://about.gitlab.com/company/team/)**. See how to work with the [Distribution team](https://about.gitlab.com/handbook/engineering/development/enablement/distribution/#how-to-work-with-distribution) for more details.
1. If your merge request includes documentation changes, it must be **approved
by a [Technical writer](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments)**, based on
the appropriate [product category](https://about.gitlab.com/handbook/product/categories/).
by a [Technical writer](https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments)**,
based on assignments in the appropriate [DevOps stage group](https://about.gitlab.com/handbook/product/categories/#devops-stages).
1. If your merge request includes end-to-end **and** non-end-to-end changes (*4*), it must be **approved
by a [Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors)**.
1. If your merge request only includes end-to-end changes (*4*) **or** if the MR author is a [Software Engineer in Test](https://about.gitlab.com/handbook/engineering/quality/#individual-contributors), it must be **approved by a [Quality maintainer](https://about.gitlab.com/handbook/engineering/projects/#gitlab_maintainers_qa)**
Next, you need a GitLab repository to contain your Agent configuration. The minimal
repository layout looks like this:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) in GitLab 13.7, the Agent manifest configuration can be added to multiple directories (or subdirectories) of its repository.
To configure an Agent, you need:
1. A GitLab repository to hold the configuration file.
1. Install the Agent in a cluster.
After installed, when you update the configuration file, GitLab transmits the
information to the cluster automatically without downtime.
In your repository, add the Agent configuration file under:
```plaintext
.gitlab/agents/<agent-name>/config.yaml
```
Your `config.yaml` file can specify multiple manifest projects in the
section `manifest_projects`:
Your `config.yaml` file specifies all configurations of the Agent, such as:
- The manifest projects to synchronize.
- The address of the `hubble-relay` for the Network Security policy integrations.
As an example, a minimal Agent configuration that sets up only the manifest
synchronizations is:
```yaml
gitops:
manifest_projects:
-id:"path-to/your-manifest-project-number1"
...
-id:"path-to/your-manifest-project-1"
paths:
-glob:'/**/*.{yaml,yml,json}'
```
GitLab [versions 13.7 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/259669) also
supports manifest projects containing
multiple directories (or subdirectories) of YAML files. For more information see our
documentation on the [Kubernetes Agent configuration repository](repository.md).
All the options for the [Kubernetes Agent configuration repository](repository.md) are documented separately.