Skip to main content




Teams adopt various strategies for organizing their repositories, including creating separate repositories for individual clusters, namespaces, and services or using branches to represent different states of deployment. Triggers enhance this organizational flexibility, enabling you to tailor the mapping of your environment to your GitLab repositories according to your specific requirements. You can fine-tune the GitLab integration by configuring multiple triggers to align precisely with your needs.

On Trigger

The On Trigger configurations define the trigger’s scope, limiting it to only the specific contexts required to be monitored for changes. This allows targeted workflows, such as tracking changes in the Staging environment to prepare intents for an upcoming production release.

ClustersRelates to a Kubernetes cluster integrated into Otterize. The names associated with the cluster are those provided during the integration.
EnvironmentsOne or more environments (testing, staging, production, etc.) are to be monitored for changes. Default is All
NamespacesOne or more Kubernetes namespaces to be monitored for changes. Default is All
ServicesOne or more Kubernetes Services to be monitored for changes. Default is All

Open merge request On

The Open merge request on definition associates the On Trigger scope to a specific GitLab project, branch, and directory path in your .

ProjectRefers to the owner or group and project name combination that uniquely identifies a project in GitLab. For example, Otterizes network mapper would be supplied by otterize/network-mapper
Base branchBase branch for most repositories is main or master.
ClientIntents pathThe path from the repository root folder that contains the intent definition files. For instance: /helm/intents/