Skip to content

Bindings

You can think of bindings as a side context where you can store and retrieve data by name.

This is particularly useful when some data is only known at runtime. For example, to pass data from one operation to another, to implement resource templating, to fetch data from an external system, or anything that needs to be computed at runtime.

Syntax

The test below illustrates bindings declaration at different levels:

apiVersion: chainsaw.kyverno.io/v1alpha1
kind: Test
metadata:
  name: example
spec:
  # bindings can be declared at the test level
  bindings:
  - name: chainsaw
    value: chainsaw
  steps:
    # bindings can also be declared at the step level
  - bindings:
    - name: hello
      value: hello
    try:
    - script:
        # bindings can also be declared at the operation level
        bindings:
        - name: awesome
          value: awesome
        env:
          # combined bindings together using the `join` functions and
          # assign the result to the GREETINGS environment variable
        - name: GREETINGS
          value: (join(' ', [$hello, $chainsaw, 'is', $awesome]))
        content: echo $GREETINGS

Reference

Browse the reference documentation to see the syntax details and where bindings can be declared.

Inheritance

Bindings can be configured at the test, step or operation level.

All bindings configured at a given level are automatically inherited at lower levels.

Immutability

Bindings are immutable. This means two bindings can have the same name without overwriting each other.

When a binding is registered it potentially hides other bindings with the same name.

When this binding goes out of scope, previously registered bindings with the same name become visible again.

Templating

Both name and value of a binding can use templating.

Built-in bindings

Chainsaw offers some built-in bindings you can directly use in your tests, steps and operations.

Browse the built-in bindings list to find available bindings.