Reference
Triggers
About
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.
| Item | Description |
|---|---|
| Clusters | Relates to a Kubernetes cluster integrated into Otterize. The names associated with the cluster are those provided during the integration. |
| Environments | One or more environments (testing, staging, production, etc.) are to be monitored for changes. Default is All |
| Namespaces | One or more Kubernetes namespaces to be monitored for changes. Default is All |
| Services | One 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.
| Item | Description |
|---|---|
| Repository | Refers 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 branch | Base branch for most repositories is main or master. |
| ClientIntents path | The path from the repository root folder that contains the intent definition files. For instance: /helm/intents/ |