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 GitHub repositories according to your specific requirements. You can fine-tune the GitHub 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 PR On

The Open PR On definition associates the On Trigger scope to a specific repository, branch, and directory path in your repository.

RepositoryRefers to the owner and repository combination that uniquely identifies a repository in GitHub. 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/