<!-- This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ## Release notes You can start using the GitLab agent for Kubernetes in two steps: (1) register the agent on the GitLab UI, (2) apply the provided command to your Kubernetes cluster. These two steps create an agent without a configuration file. To get the full benefits of the agent, like pull-based deployments, a configuration file is required. Specifically for pull-based deployments, you always had to specify the project where the manifests are stored. This required changing the file from project to project. From today, omitting the project id will look for manifests in the current project. This should simplify setting up new agents across several projects following the same conventions for storing their manifests. ### Problem to solve Simplify getting started and single-repo setup. ### Proposal Given that the agent is configured in project `gitlab-org/cluster-integration/gitlab-agent` simplify this ```yaml gitops: manifest_projects: - id: gitlab-org/cluster-integration/gitlab-agent paths: - glob: '/team1/app1/*.yaml' ``` to this ```yaml gitops: manifest_projects: - paths: - glob: '/team1/app1/*.yaml' ``` If no `id` is given, treat it as the same project. This would enable us to create project templates with agent configurations and could simplify many setups. ### Implementation proposal * Make [the config field](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/41fcf5cb2dcf37d9703eb7f2e1f454c3ef2ee2ce/pkg/agentcfg/agentcfg.proto#L29) optional (i.e. remove validation, add a test for that). See where the field is used and ensure no invariants are broken by the change, maybe add tests if you find something interesting. * Make [the field](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/41fcf5cb2dcf37d9703eb7f2e1f454c3ef2ee2ce/internal/module/gitops/rpc/rpc.proto#L17), used in the gRPC request, optional (i.e. remove validation, add a test for that). See where the field is used and ensure no invariants are broken by the change, maybe add tests if you find something interesting. * Change logic [in the GitOps server](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/41fcf5cb2dcf37d9703eb7f2e1f454c3ef2ee2ce/internal/module/gitops/server/server.go#L50-116) to use `GitalyInfo` and `gitalypb.Repository` from `api.AgentInfo` (rather than from `ProjectInfo`) in case project id is an empty string. Add some tests for the change to protect against regressions. ### Definition of done - [ ] Default Kas to reference current project instead of ID if ID is not present - [ ] Document this default and use in example projects ### Intended users * [Allison (Application Ops)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#allison-application-ops) * [Priyanka (Platform Engineer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#priyanka-platform-engineer)