Trigger

ConfigHub supports automatic function Triggers. Triggers are registered to invoke Functions on config Units of the appropriate Type at specified lifecycle Events, either arbitrary Mutations of all kinds, or more specific Events, such as PostClone. Triggers are similar to dynamic admission control in Kubernetes.

Validating Function Triggers that run after all Mutations constitute a policy enforcement point (PEP) for the Space for which they are registered. They can enforce that specific constraints, invariants, and requirements are met. The way they do this is by adding Apply Gates to Units for each Validating Function Trigger that fails. When any Apply Gates are present on a Unit, the Unit cannot be Applied. Example validation functions include vet-schemas, which runs kubeconform to validate the schemas of Kubernetes resources, vet-celexpr, which evaluates a specified CEL expression over the configuration Unit, and vet-placeholders, which ensures that no placeholder values remain in the configuration.

Triggers with Warn set to true produce Apply Warnings instead of Apply Gates when their validating function fails. Apply Warnings are non-blocking — they surface validation issues without preventing Apply operations. This is useful for advisory policies, soft constraints, or gradually rolling out new validation rules. For example, you might introduce a new CEL expression constraint as a warning first, then switch it to blocking once existing units are brought into compliance:

cub trigger create --space home replicas-check Mutation Kubernetes/YAML --warn vet-celexpr 'r.kind != "Deployment" || r.spec.replicas > 1'

The --warn flag can be toggled with --unwarn on update.

Triggers support several fields for controlling their behavior:

• Description — user-defined text explaining what the trigger checks and how to fix failures, shown in the UI when hovering over an Apply Gate.
• WhereUnit — a filter expression to restrict which Units the Trigger applies to.
• UnitFilterID — a reference to a saved Filter entity (with From=Unit) for the same purpose.
• WhereResource — restricts which resources within a Unit's configuration data the function operates on.
• FailOpenAfter — for worker-executed Triggers, the duration after which a disconnected worker's triggers are treated as fail-open (default 6 hours).
• Hash — a computed hash of the Trigger's specification, used to detect changes that require re-running triggers on affected Units.

For a practical guide on creating and managing Triggers, see the validation and policies guide.

Importantly, Validating Function Triggers do not block edits or other mutations. This enables issues flagged by newly added Triggers to be addressed and also enables configuration data to be constructed or updated in multiple steps. They are similar in some ways to GitHub pull request status checks, which can gate merges.

Mutating Function Triggers are a key mechanism that enables configuration data to be decoupled from the code that operates on the data. By contrast, Infrastructure as Code (IaC) tools mix code and data, and require the configuration generation code to be re-evaluated in order to make any changes to the configuration data output. IaC packages encapsulate this code and expose bespoke, non-standard interfaces, typically expressed using input and output parameters. In ConfigHub, the code is not attached to the configuration data in that way. Instead, it comes from the Space in which the configuration data is manipulated and used.

Readonly (e.g. get-) Functions that return the AttributeValueList type may be used in Triggers also. These Triggers can extract values and store them in the Values map inside Units, for display using custom Views and for filtering. For example, get-image main could be used to store the current main container image of any workload resources.