From 962bba1c5b5689033f19f17b145bd1314c6b5566 Mon Sep 17 00:00:00 2001 From: ci-bot Date: Fri, 17 May 2024 08:25:13 +0000 Subject: [PATCH] Deployed d058ce7 to main with MkDocs 1.6.0 and mike 2.1.1 --- main/404.html | 2 +- main/apis/chainsaw.v1alpha1/index.html | 2 +- main/apis/chainsaw.v1alpha2/index.html | 2 +- main/bindings/index.html | 2 +- main/bindings/outputs/index.html | 2 +- main/collectors/describe/index.html | 2 +- main/collectors/events/index.html | 2 +- main/collectors/get/index.html | 2 +- main/collectors/index.html | 2 +- main/collectors/pod-logs/index.html | 2 +- main/commands/chainsaw/index.html | 2 +- main/commands/chainsaw_assert/index.html | 2 +- main/commands/chainsaw_build/index.html | 2 +- main/commands/chainsaw_build_docs/index.html | 2 +- main/commands/chainsaw_completion/index.html | 2 +- main/commands/chainsaw_completion_bash/index.html | 2 +- main/commands/chainsaw_completion_fish/index.html | 2 +- main/commands/chainsaw_completion_powershell/index.html | 2 +- main/commands/chainsaw_completion_zsh/index.html | 2 +- main/commands/chainsaw_create/index.html | 2 +- main/commands/chainsaw_create_test/index.html | 2 +- main/commands/chainsaw_docs/index.html | 2 +- main/commands/chainsaw_export/index.html | 2 +- main/commands/chainsaw_export_schemas/index.html | 2 +- main/commands/chainsaw_lint/index.html | 2 +- main/commands/chainsaw_migrate/index.html | 2 +- main/commands/chainsaw_migrate_kuttl/index.html | 2 +- main/commands/chainsaw_migrate_kuttl_config/index.html | 2 +- main/commands/chainsaw_migrate_kuttl_tests/index.html | 2 +- main/commands/chainsaw_test/index.html | 2 +- main/commands/chainsaw_version/index.html | 2 +- main/community/index.html | 2 +- main/configuration/cleanup-delay/index.html | 2 +- main/configuration/file/index.html | 2 +- main/configuration/flags/index.html | 2 +- main/configuration/grace/index.html | 2 +- main/configuration/index.html | 2 +- main/configuration/multi-cluster/index.html | 2 +- main/configuration/no-cluster/index.html | 2 +- main/configuration/reports/index.html | 2 +- main/configuration/selector/index.html | 2 +- main/configuration/templating/index.html | 2 +- main/configuration/timeouts/index.html | 2 +- main/configuration/values/index.html | 2 +- main/docs/index.html | 2 +- main/examples/array-assertions/index.html | 2 +- main/examples/assertion-tree/index.html | 2 +- main/examples/basic/index.html | 2 +- main/examples/index.html | 2 +- main/examples/inline/index.html | 2 +- main/examples/labels-selector/index.html | 2 +- main/examples/non-resource-assertion/index.html | 2 +- main/examples/test-output/index.html | 4 ++-- main/gh-action/index.html | 2 +- main/index.html | 4 ++-- main/install/index.html | 2 +- main/intro/index.html | 2 +- main/jp/functions/index.html | 2 +- main/json-schemas/index.html | 2 +- main/more/crds/index.html | 2 +- main/more/events/index.html | 2 +- main/more/kuttl-migration/index.html | 2 +- main/more/lint/index.html | 2 +- main/more/test-docs/index.html | 2 +- main/operations/apply/index.html | 2 +- main/operations/assert/index.html | 2 +- main/operations/check/index.html | 2 +- main/operations/command/index.html | 2 +- main/operations/create/index.html | 2 +- main/operations/delete/index.html | 2 +- main/operations/error/index.html | 2 +- main/operations/index.html | 2 +- main/operations/non-resource-assert/index.html | 2 +- main/operations/patch/index.html | 2 +- main/operations/script/index.html | 2 +- main/operations/sleep/index.html | 2 +- main/operations/templating/index.html | 2 +- main/operations/update/index.html | 2 +- main/operations/wait/index.html | 2 +- main/quick-start/index.html | 2 +- main/resources/index.html | 2 +- main/steps/catch/index.html | 2 +- main/steps/finally/index.html | 2 +- main/steps/index.html | 2 +- main/steps/try/index.html | 2 +- main/tests/index.html | 2 +- main/tests/manifests-based/index.html | 2 +- main/tests/test-based/index.html | 2 +- main/writing-tests/index.html | 2 +- 89 files changed, 91 insertions(+), 91 deletions(-) diff --git a/main/404.html b/main/404.html index 94d9a1f50..a26e41c8c 100644 --- a/main/404.html +++ b/main/404.html @@ -1 +1 @@ - Chainsaw

404 - Not found

\ No newline at end of file + Chainsaw

404 - Not found

\ No newline at end of file diff --git a/main/apis/chainsaw.v1alpha1/index.html b/main/apis/chainsaw.v1alpha1/index.html index 31dbbde20..d0f08124f 100644 --- a/main/apis/chainsaw.v1alpha1/index.html +++ b/main/apis/chainsaw.v1alpha1/index.html @@ -1 +1 @@ - chainsaw (v1alpha1) - Chainsaw
Skip to content

v1alpha1

Package v1alpha1 contains API Schema definitions for the v1alpha1 API group.

Resource Types

Configuration

Configuration is the resource that contains the configuration used to run tests.

Field Type Required Inline Description
apiVersion string ✅ chainsaw.kyverno.io/v1alpha1
kind string ✅ Configuration
metadata meta/v1.ObjectMeta

Standard object's metadata.
spec ConfigurationSpec ✅

Configuration spec.

Test

Test is the resource that contains a test definition.

Field Type Required Inline Description
apiVersion string ✅ chainsaw.kyverno.io/v1alpha1
kind string ✅ Test
metadata meta/v1.ObjectMeta

Standard object's metadata.
spec TestSpec ✅

Test spec.

Apply

Appears in:

Apply represents a set of configurations or resources that should be applied during testing.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrResource FileRefOrResource ✅ ✅

FileRefOrResource provides a reference to the resources to be applied.
template bool

Template determines whether resources should be considered for templating.
dryRun bool

DryRun determines whether the file should be applied in dry run mode.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

Assert

Appears in:

Assert represents a test condition that is expected to hold true during the testing process.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrCheck FileRefOrCheck ✅ ✅

FileRefOrAssert provides a reference to the assertion.
template bool

Template determines whether resources should be considered for templating.

Binding

Appears in:

Binding represents a key/value set as a binding in an executing test.

Field Type Required Inline Description
name string ✅

Name the name of the binding.
value policy/v1alpha1.Any ✅

Value value of the binding.

Catch

Appears in:

Catch defines actions to be executed on failure.

Field Type Required Inline Description
description string

Description contains a description of the operation.
podLogs PodLogs

PodLogs determines the pod logs collector to execute.
events Events

Events determines the events collector to execute.
describe Describe

Describe determines the resource describe collector to execute.
wait Wait

Wait determines the resource wait collector to execute.
get Get

Get determines the resource get collector to execute.
delete Delete

Delete represents a deletion operation.
command Command

Command defines a command to run.
script Script

Script defines a script to run.
sleep Sleep

Sleep defines zzzz.

Cluster

Appears in:

Cluster defines cluster config and context.

Field Type Required Inline Description
kubeconfig string ✅

Kubeconfig is the path to the referenced file.
context string

Context is the name of the context to use.

Command

Appears in:

Command describes a command to run as a part of a test step.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
env []Binding

Env defines additional environment variables.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
entrypoint string ✅

Entrypoint is the command entry point to run.
args []string

Args is the command arguments.
skipLogOutput bool

SkipLogOutput removes the output from the command. Useful for sensitive logs or to reduce noise.
check policy/v1alpha1.Any

Check is an assertion tree to validate the operation outcome.

Condition

Appears in:

Condition represents parameters for waiting on a specific condition of a resource.

Field Type Required Inline Description
name string ✅

Name defines the specific condition to wait for, e.g., "Available", "Ready".
value string

Value defines the specific condition status to wait for, e.g., "True", "False".

ConfigurationSpec

Appears in:

ConfigurationSpec contains the configuration used to run tests.

Field Type Required Inline Description
timeouts Timeouts

Global timeouts configuration. Applies to all tests/test steps if not overridden.
skipDelete bool

If set, do not delete the resources after running the tests (implies SkipClusterDelete).
template bool

Template determines whether resources should be considered for templating.
failFast bool

FailFast determines whether the test should stop upon encountering the first failure.
parallel int

The maximum number of tests to run at once.
reportFormat ReportFormatType

ReportFormat determines test report format (JSON
reportPath string

ReportPath defines the path.
reportName string

ReportName defines the name of report to create. It defaults to "chainsaw-report".
namespace string

Namespace defines the namespace to use for tests. If not specified, every test will execute in a random ephemeral namespace unless the namespace is overridden in a the test spec.
namespaceTemplate policy/v1alpha1.Any

NamespaceTemplate defines a template to create the test namespace.
fullName bool

FullName makes use of the full test case folder path instead of the folder name.
excludeTestRegex string

ExcludeTestRegex is used to exclude tests based on a regular expression.
includeTestRegex string

IncludeTestRegex is used to include tests based on a regular expression.
repeatCount int

RepeatCount indicates how many times the tests should be executed.
testFile string

TestFile is the name of the file containing the test to run. If no extension is provided, chainsaw will try with .yaml first and .yml if needed.
forceTerminationGracePeriod meta/v1.Duration

ForceTerminationGracePeriod forces the termination grace period on pods, statefulsets, daemonsets and deployments.
delayBeforeCleanup meta/v1.Duration

DelayBeforeCleanup adds a delay between the time a test ends and the time cleanup starts.
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
catch []Catch

Catch defines what the tests steps will execute when an error happens. This will be combined with catch handlers defined at the test and step levels.

Create

Appears in:

Create represents a set of resources that should be created. If a resource already exists in the cluster it will fail.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrResource FileRefOrResource ✅ ✅

FileRefOrResource provides a reference to the file containing the resources to be created.
template bool

Template determines whether resources should be considered for templating.
dryRun bool

DryRun determines whether the file should be applied in dry run mode.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

Delete

Appears in:

Delete is a reference to an object that should be deleted

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
template bool

Template determines whether resources should be considered for templating.
ref ObjectReference ✅

ObjectReference determines objects to be deleted.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

Deletion

Appears in:

Deletion represents parameters for waiting on a resource's deletion.

Describe

Appears in:

Describe defines how to describe resources.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ResourceReference ResourceReference ✅ ✅

ResourceReference referenced resource type.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
showEvents bool

Show Events indicates whether to include related events.

Error

Appears in:

Error represents an anticipated error condition that may arise during testing. Instead of treating such an error as a test failure, it acknowledges it as expected.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrCheck FileRefOrCheck ✅ ✅

FileRefOrAssert provides a reference to the expected error.
template bool

Template determines whether resources should be considered for templating.

Events

Appears in:

Events defines how to collect events.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
format Format

Format determines the output format (json or yaml).

Expectation

Appears in:

Expectation represents a check to be applied on the result of an operation with a match filter to determine if the verification should be considered.

Field Type Required Inline Description
match policy/v1alpha1.Any

Match defines the matching statement.
check policy/v1alpha1.Any ✅

Check defines the verification statement.

FileRef

Appears in:

FileRef represents a file reference.

Field Type Required Inline Description
file string ✅

File is the path to the referenced file. This can be a direct path to a file or an expression that matches multiple files, such as "manifest/*.yaml" for all YAML files within the "manifest" directory.

FileRefOrCheck

Appears in:

FileRefOrCheck represents a file reference or resource.

Field Type Required Inline Description
FileRef FileRef ✅

FileRef provides a reference to the file containing the resources to be applied.
resource policy/v1alpha1.Any

Check provides a check used in assertions.

FileRefOrResource

Appears in:

FileRefOrResource represents a file reference or resource.

Field Type Required Inline Description
FileRef FileRef ✅

FileRef provides a reference to the file containing the resources to be applied.
resource meta/v1/unstructured.Unstructured

Resource provides a resource to be applied.

Finally

Appears in:

Finally defines actions to be executed at the end of a test.

Field Type Required Inline Description
description string

Description contains a description of the operation.
podLogs PodLogs

PodLogs determines the pod logs collector to execute.
events Events

Events determines the events collector to execute.
describe Describe

Describe determines the resource describe collector to execute.
wait Wait

Wait determines the resource wait collector to execute.
get Get

Get determines the resource get collector to execute.
delete Delete

Delete represents a deletion operation.
command Command

Command defines a command to run.
script Script

Script defines a script to run.
sleep Sleep

Sleep defines zzzz.

For

Appears in:

For specifies the condition to wait for.

Field Type Required Inline Description
deletion Deletion

Deletion specifies parameters for waiting on a resource's deletion.
condition Condition

Condition specifies the condition to wait for.
jsonPath JsonPath

JsonPath specifies the json path condition to wait for.

Format

(Alias of string)

Appears in:

Format determines the output format (json or yaml).

Get

Appears in:

Get defines how to get resources.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ResourceReference ResourceReference ✅ ✅

ResourceReference referenced resource type.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
format Format

Format determines the output format (json or yaml).

JsonPath

Appears in:

JsonPath represents parameters for waiting on a json path of a resource.

Field Type Required Inline Description
path string ✅

Path defines the json path to wait for, e.g. '{.status.phase}'.
value string ✅

Value defines the expected value to wait for, e.g., "Running".

ObjectLabelsSelector

Appears in:

ObjectLabelsSelector represents a strategy to select objects. For a single object name and namespace are used to identify the object. For multiple objects use selector.

Field Type Required Inline Description
namespace string

Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
name string

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
selector string

Selector defines labels selector.

ObjectReference

Appears in:

ObjectReference represents one or more objects with a specific apiVersion and kind. For a single object name and namespace are used to identify the object. For multiple objects use labels.

Field Type Required Inline Description
ObjectType ObjectType ✅ ✅

ObjectType determines the type of referenced objects.
ObjectSelector ObjectSelector ✅ ✅

ObjectSelector determines the selection process of referenced objects.

ObjectSelector

Appears in:

ObjectSelector represents a strategy to select objects. For a single object name and namespace are used to identify the object. For multiple objects use labels.

Field Type Required Inline Description
namespace string

Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
name string

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
labels map[string]string

Label selector to match objects to delete

ObjectType

Appears in:

ObjectType represents a specific apiVersion and kind.

Field Type Required Inline Description
apiVersion string ✅

API version of the referent.
kind string ✅

Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

Operation

Appears in:

Operation defines a single operation, only one action is permitted for a given operation.

Field Type Required Inline Description
description string

Description contains a description of the operation.
continueOnError bool

ContinueOnError determines whether a test should continue or not in case the operation was not successful. Even if the test continues executing, it will still be reported as failed.
apply Apply

Apply represents resources that should be applied for this test step. This can include things like configuration settings or any other resources that need to be available during the test.
assert Assert

Assert represents an assertion to be made. It checks whether the conditions specified in the assertion hold true.
command Command

Command defines a command to run.
create Create

Create represents a creation operation.
delete Delete

Delete represents a deletion operation.
error Error

Error represents the expected errors for this test step. If any of these errors occur, the test will consider them as expected; otherwise, they will be treated as test failures.
patch Patch

Patch represents a patch operation.
script Script

Script defines a script to run.
sleep Sleep

Sleep defines zzzz.
update Update

Update represents an update operation.
wait Wait

Wait determines the resource wait collector to execute.

Output

Appears in:

Output represents an output binding with a match to determine if the binding must be considered or not.

Field Type Required Inline Description
Binding Binding ✅ ✅

Binding determines the binding to create when the match succeeds.
match policy/v1alpha1.Any

Match defines the matching statement.

Patch

Appears in:

Patch represents a set of resources that should be patched. If a resource doesn't exist yet in the cluster it will fail.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrResource FileRefOrResource ✅ ✅

FileRefOrResource provides a reference to the file containing the resources to be patched.
template bool

Template determines whether resources should be considered for templating.
dryRun bool

DryRun determines whether the file should be applied in dry run mode.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

PodLogs

Appears in:

PodLogs defines how to collect pod logs.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
container string

Container in pod to get logs from else --all-containers is used.
tail int

Tail is the number of last lines to collect from pods. If omitted or zero, then the default is 10 if you use a selector, or -1 (all) if you use a pod name. This matches default behavior of kubectl logs.

ReportFormatType

(Alias of string)

Appears in:

ResourceReference

Appears in:

ResourceReference represents a resource (API), it can be represented with a resource or a kind. Optionally an apiVersion can be specified.

Field Type Required Inline Description
apiVersion string

API version of the referent.
kind string

Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
resource string

Resource name of the referent.

Script

Appears in:

Script describes a script to run as a part of a test step.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
env []Binding

Env defines additional environment variables.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
content string

Content defines a shell script (run with "sh -c ...").
skipLogOutput bool

SkipLogOutput removes the output from the command. Useful for sensitive logs or to reduce noise.
check policy/v1alpha1.Any

Check is an assertion tree to validate the operation outcome.

Sleep

Appears in:

Sleep represents a duration while nothing happens.

Field Type Required Inline Description
duration meta/v1.Duration ✅

Duration is the delay used for sleeping.

TestSpec

Appears in:

TestSpec contains the test spec.

Field Type Required Inline Description
description string

Description contains a description of the test.
timeouts Timeouts

Timeouts for the test. Overrides the global timeouts set in the Configuration on a per operation basis.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
skip bool

Skip determines whether the test should skipped.
concurrent bool

Concurrent determines whether the test should run concurrently with other tests.
skipDelete bool

SkipDelete determines whether the resources created by the test should be deleted after the test is executed.
template bool

Template determines whether resources should be considered for templating.
namespace string

Namespace determines whether the test should run in a random ephemeral namespace or not.
namespaceTemplate policy/v1alpha1.Any

NamespaceTemplate defines a template to create the test namespace.
bindings []Binding

Bindings defines additional binding key/values.
steps []TestStep ✅

Steps defining the test.
catch []Catch

Catch defines what the steps will execute when an error happens. This will be combined with catch handlers defined at the step level.
forceTerminationGracePeriod meta/v1.Duration

ForceTerminationGracePeriod forces the termination grace period on pods, statefulsets, daemonsets and deployments.
delayBeforeCleanup meta/v1.Duration

DelayBeforeCleanup adds a delay between the time a test ends and the time cleanup starts.

TestStep

Appears in:

TestStep contains the test step definition used in a test spec.

Field Type Required Inline Description
name string

Name of the step.
TestStepSpec TestStepSpec ✅ ✅

TestStepSpec of the step.

TestStepSpec

Appears in:

TestStepSpec defines the desired state and behavior for each test step.

Field Type Required Inline Description
description string

Description contains a description of the test step.
timeouts Timeouts

Timeouts for the test step. Overrides the global timeouts set in the Configuration and the timeouts eventually set in the Test.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
skipDelete bool

SkipDelete determines whether the resources created by the step should be deleted after the test step is executed.
template bool

Template determines whether resources should be considered for templating.
bindings []Binding

Bindings defines additional binding key/values.
try []Operation ✅

Try defines what the step will try to execute.
catch []Catch

Catch defines what the step will execute when an error happens.
finally []Finally

Finally defines what the step will execute after the step is terminated.

Timeouts

Appears in:

Timeouts contains timeouts per operation.

Field Type Required Inline Description
apply meta/v1.Duration ✅

Apply defines the timeout for the apply operation
assert meta/v1.Duration ✅

Assert defines the timeout for the assert operation
cleanup meta/v1.Duration ✅

Cleanup defines the timeout for the cleanup operation
delete meta/v1.Duration ✅

Delete defines the timeout for the delete operation
error meta/v1.Duration ✅

Error defines the timeout for the error operation
exec meta/v1.Duration ✅

Exec defines the timeout for exec operations

Update

Appears in:

Update represents a set of resources that should be updated. If a resource does not exist in the cluster it will fail.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrResource FileRefOrResource ✅ ✅

FileRefOrResource provides a reference to the file containing the resources to be created.
template bool

Template determines whether resources should be considered for templating.
dryRun bool

DryRun determines whether the file should be applied in dry run mode.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

Wait

Appears in:

Wait specifies how to perform wait operations on resources.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Specifies how long to wait for the condition to be met before timing out.
cluster string

Cluster defines the target cluster where the wait operation will be performed (default cluster will be used if not specified).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ResourceReference ResourceReference ✅ ✅

ResourceReference referenced resource type.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
for For ✅

For specifies the condition to wait for.
format Format

Format determines the output format (json or yaml).
\ No newline at end of file + chainsaw (v1alpha1) - Chainsaw
Skip to content

v1alpha1

Package v1alpha1 contains API Schema definitions for the v1alpha1 API group.

Resource Types

Configuration

Configuration is the resource that contains the configuration used to run tests.

Field Type Required Inline Description
apiVersion string ✅ chainsaw.kyverno.io/v1alpha1
kind string ✅ Configuration
metadata meta/v1.ObjectMeta

Standard object's metadata.
spec ConfigurationSpec ✅

Configuration spec.

Test

Test is the resource that contains a test definition.

Field Type Required Inline Description
apiVersion string ✅ chainsaw.kyverno.io/v1alpha1
kind string ✅ Test
metadata meta/v1.ObjectMeta

Standard object's metadata.
spec TestSpec ✅

Test spec.

Apply

Appears in:

Apply represents a set of configurations or resources that should be applied during testing.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrResource FileRefOrResource ✅ ✅

FileRefOrResource provides a reference to the resources to be applied.
template bool

Template determines whether resources should be considered for templating.
dryRun bool

DryRun determines whether the file should be applied in dry run mode.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

Assert

Appears in:

Assert represents a test condition that is expected to hold true during the testing process.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrCheck FileRefOrCheck ✅ ✅

FileRefOrAssert provides a reference to the assertion.
template bool

Template determines whether resources should be considered for templating.

Binding

Appears in:

Binding represents a key/value set as a binding in an executing test.

Field Type Required Inline Description
name string ✅

Name the name of the binding.
value policy/v1alpha1.Any ✅

Value value of the binding.

Catch

Appears in:

Catch defines actions to be executed on failure.

Field Type Required Inline Description
description string

Description contains a description of the operation.
podLogs PodLogs

PodLogs determines the pod logs collector to execute.
events Events

Events determines the events collector to execute.
describe Describe

Describe determines the resource describe collector to execute.
wait Wait

Wait determines the resource wait collector to execute.
get Get

Get determines the resource get collector to execute.
delete Delete

Delete represents a deletion operation.
command Command

Command defines a command to run.
script Script

Script defines a script to run.
sleep Sleep

Sleep defines zzzz.

Cluster

Appears in:

Cluster defines cluster config and context.

Field Type Required Inline Description
kubeconfig string ✅

Kubeconfig is the path to the referenced file.
context string

Context is the name of the context to use.

Command

Appears in:

Command describes a command to run as a part of a test step.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
env []Binding

Env defines additional environment variables.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
entrypoint string ✅

Entrypoint is the command entry point to run.
args []string

Args is the command arguments.
skipLogOutput bool

SkipLogOutput removes the output from the command. Useful for sensitive logs or to reduce noise.
check policy/v1alpha1.Any

Check is an assertion tree to validate the operation outcome.

Condition

Appears in:

Condition represents parameters for waiting on a specific condition of a resource.

Field Type Required Inline Description
name string ✅

Name defines the specific condition to wait for, e.g., "Available", "Ready".
value string

Value defines the specific condition status to wait for, e.g., "True", "False".

ConfigurationSpec

Appears in:

ConfigurationSpec contains the configuration used to run tests.

Field Type Required Inline Description
timeouts Timeouts

Global timeouts configuration. Applies to all tests/test steps if not overridden.
skipDelete bool

If set, do not delete the resources after running the tests (implies SkipClusterDelete).
template bool

Template determines whether resources should be considered for templating.
failFast bool

FailFast determines whether the test should stop upon encountering the first failure.
parallel int

The maximum number of tests to run at once.
reportFormat ReportFormatType

ReportFormat determines test report format (JSON
reportPath string

ReportPath defines the path.
reportName string

ReportName defines the name of report to create. It defaults to "chainsaw-report".
namespace string

Namespace defines the namespace to use for tests. If not specified, every test will execute in a random ephemeral namespace unless the namespace is overridden in a the test spec.
namespaceTemplate policy/v1alpha1.Any

NamespaceTemplate defines a template to create the test namespace.
fullName bool

FullName makes use of the full test case folder path instead of the folder name.
excludeTestRegex string

ExcludeTestRegex is used to exclude tests based on a regular expression.
includeTestRegex string

IncludeTestRegex is used to include tests based on a regular expression.
repeatCount int

RepeatCount indicates how many times the tests should be executed.
testFile string

TestFile is the name of the file containing the test to run. If no extension is provided, chainsaw will try with .yaml first and .yml if needed.
forceTerminationGracePeriod meta/v1.Duration

ForceTerminationGracePeriod forces the termination grace period on pods, statefulsets, daemonsets and deployments.
delayBeforeCleanup meta/v1.Duration

DelayBeforeCleanup adds a delay between the time a test ends and the time cleanup starts.
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
catch []Catch

Catch defines what the tests steps will execute when an error happens. This will be combined with catch handlers defined at the test and step levels.

Create

Appears in:

Create represents a set of resources that should be created. If a resource already exists in the cluster it will fail.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrResource FileRefOrResource ✅ ✅

FileRefOrResource provides a reference to the file containing the resources to be created.
template bool

Template determines whether resources should be considered for templating.
dryRun bool

DryRun determines whether the file should be applied in dry run mode.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

Delete

Appears in:

Delete is a reference to an object that should be deleted

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
template bool

Template determines whether resources should be considered for templating.
ref ObjectReference ✅

ObjectReference determines objects to be deleted.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

Deletion

Appears in:

Deletion represents parameters for waiting on a resource's deletion.

Describe

Appears in:

Describe defines how to describe resources.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ResourceReference ResourceReference ✅ ✅

ResourceReference referenced resource type.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
showEvents bool

Show Events indicates whether to include related events.

Error

Appears in:

Error represents an anticipated error condition that may arise during testing. Instead of treating such an error as a test failure, it acknowledges it as expected.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrCheck FileRefOrCheck ✅ ✅

FileRefOrAssert provides a reference to the expected error.
template bool

Template determines whether resources should be considered for templating.

Events

Appears in:

Events defines how to collect events.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
format Format

Format determines the output format (json or yaml).

Expectation

Appears in:

Expectation represents a check to be applied on the result of an operation with a match filter to determine if the verification should be considered.

Field Type Required Inline Description
match policy/v1alpha1.Any

Match defines the matching statement.
check policy/v1alpha1.Any ✅

Check defines the verification statement.

FileRef

Appears in:

FileRef represents a file reference.

Field Type Required Inline Description
file string ✅

File is the path to the referenced file. This can be a direct path to a file or an expression that matches multiple files, such as "manifest/*.yaml" for all YAML files within the "manifest" directory.

FileRefOrCheck

Appears in:

FileRefOrCheck represents a file reference or resource.

Field Type Required Inline Description
FileRef FileRef ✅

FileRef provides a reference to the file containing the resources to be applied.
resource policy/v1alpha1.Any

Check provides a check used in assertions.

FileRefOrResource

Appears in:

FileRefOrResource represents a file reference or resource.

Field Type Required Inline Description
FileRef FileRef ✅

FileRef provides a reference to the file containing the resources to be applied.
resource meta/v1/unstructured.Unstructured

Resource provides a resource to be applied.

Finally

Appears in:

Finally defines actions to be executed at the end of a test.

Field Type Required Inline Description
description string

Description contains a description of the operation.
podLogs PodLogs

PodLogs determines the pod logs collector to execute.
events Events

Events determines the events collector to execute.
describe Describe

Describe determines the resource describe collector to execute.
wait Wait

Wait determines the resource wait collector to execute.
get Get

Get determines the resource get collector to execute.
delete Delete

Delete represents a deletion operation.
command Command

Command defines a command to run.
script Script

Script defines a script to run.
sleep Sleep

Sleep defines zzzz.

For

Appears in:

For specifies the condition to wait for.

Field Type Required Inline Description
deletion Deletion

Deletion specifies parameters for waiting on a resource's deletion.
condition Condition

Condition specifies the condition to wait for.
jsonPath JsonPath

JsonPath specifies the json path condition to wait for.

Format

(Alias of string)

Appears in:

Format determines the output format (json or yaml).

Get

Appears in:

Get defines how to get resources.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ResourceReference ResourceReference ✅ ✅

ResourceReference referenced resource type.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
format Format

Format determines the output format (json or yaml).

JsonPath

Appears in:

JsonPath represents parameters for waiting on a json path of a resource.

Field Type Required Inline Description
path string ✅

Path defines the json path to wait for, e.g. '{.status.phase}'.
value string ✅

Value defines the expected value to wait for, e.g., "Running".

ObjectLabelsSelector

Appears in:

ObjectLabelsSelector represents a strategy to select objects. For a single object name and namespace are used to identify the object. For multiple objects use selector.

Field Type Required Inline Description
namespace string

Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
name string

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
selector string

Selector defines labels selector.

ObjectReference

Appears in:

ObjectReference represents one or more objects with a specific apiVersion and kind. For a single object name and namespace are used to identify the object. For multiple objects use labels.

Field Type Required Inline Description
ObjectType ObjectType ✅ ✅

ObjectType determines the type of referenced objects.
ObjectSelector ObjectSelector ✅ ✅

ObjectSelector determines the selection process of referenced objects.

ObjectSelector

Appears in:

ObjectSelector represents a strategy to select objects. For a single object name and namespace are used to identify the object. For multiple objects use labels.

Field Type Required Inline Description
namespace string

Namespace of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
name string

Name of the referent. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
labels map[string]string

Label selector to match objects to delete

ObjectType

Appears in:

ObjectType represents a specific apiVersion and kind.

Field Type Required Inline Description
apiVersion string ✅

API version of the referent.
kind string ✅

Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

Operation

Appears in:

Operation defines a single operation, only one action is permitted for a given operation.

Field Type Required Inline Description
description string

Description contains a description of the operation.
continueOnError bool

ContinueOnError determines whether a test should continue or not in case the operation was not successful. Even if the test continues executing, it will still be reported as failed.
apply Apply

Apply represents resources that should be applied for this test step. This can include things like configuration settings or any other resources that need to be available during the test.
assert Assert

Assert represents an assertion to be made. It checks whether the conditions specified in the assertion hold true.
command Command

Command defines a command to run.
create Create

Create represents a creation operation.
delete Delete

Delete represents a deletion operation.
error Error

Error represents the expected errors for this test step. If any of these errors occur, the test will consider them as expected; otherwise, they will be treated as test failures.
patch Patch

Patch represents a patch operation.
script Script

Script defines a script to run.
sleep Sleep

Sleep defines zzzz.
update Update

Update represents an update operation.
wait Wait

Wait determines the resource wait collector to execute.

Output

Appears in:

Output represents an output binding with a match to determine if the binding must be considered or not.

Field Type Required Inline Description
Binding Binding ✅ ✅

Binding determines the binding to create when the match succeeds.
match policy/v1alpha1.Any

Match defines the matching statement.

Patch

Appears in:

Patch represents a set of resources that should be patched. If a resource doesn't exist yet in the cluster it will fail.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrResource FileRefOrResource ✅ ✅

FileRefOrResource provides a reference to the file containing the resources to be patched.
template bool

Template determines whether resources should be considered for templating.
dryRun bool

DryRun determines whether the file should be applied in dry run mode.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

PodLogs

Appears in:

PodLogs defines how to collect pod logs.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
container string

Container in pod to get logs from else --all-containers is used.
tail int

Tail is the number of last lines to collect from pods. If omitted or zero, then the default is 10 if you use a selector, or -1 (all) if you use a pod name. This matches default behavior of kubectl logs.

ReportFormatType

(Alias of string)

Appears in:

ResourceReference

Appears in:

ResourceReference represents a resource (API), it can be represented with a resource or a kind. Optionally an apiVersion can be specified.

Field Type Required Inline Description
apiVersion string

API version of the referent.
kind string

Kind of the referent. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
resource string

Resource name of the referent.

Script

Appears in:

Script describes a script to run as a part of a test step.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
env []Binding

Env defines additional environment variables.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
content string

Content defines a shell script (run with "sh -c ...").
skipLogOutput bool

SkipLogOutput removes the output from the command. Useful for sensitive logs or to reduce noise.
check policy/v1alpha1.Any

Check is an assertion tree to validate the operation outcome.

Sleep

Appears in:

Sleep represents a duration while nothing happens.

Field Type Required Inline Description
duration meta/v1.Duration ✅

Duration is the delay used for sleeping.

TestSpec

Appears in:

TestSpec contains the test spec.

Field Type Required Inline Description
description string

Description contains a description of the test.
timeouts Timeouts

Timeouts for the test. Overrides the global timeouts set in the Configuration on a per operation basis.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
skip bool

Skip determines whether the test should skipped.
concurrent bool

Concurrent determines whether the test should run concurrently with other tests.
skipDelete bool

SkipDelete determines whether the resources created by the test should be deleted after the test is executed.
template bool

Template determines whether resources should be considered for templating.
namespace string

Namespace determines whether the test should run in a random ephemeral namespace or not.
namespaceTemplate policy/v1alpha1.Any

NamespaceTemplate defines a template to create the test namespace.
bindings []Binding

Bindings defines additional binding key/values.
steps []TestStep ✅

Steps defining the test.
catch []Catch

Catch defines what the steps will execute when an error happens. This will be combined with catch handlers defined at the step level.
forceTerminationGracePeriod meta/v1.Duration

ForceTerminationGracePeriod forces the termination grace period on pods, statefulsets, daemonsets and deployments.
delayBeforeCleanup meta/v1.Duration

DelayBeforeCleanup adds a delay between the time a test ends and the time cleanup starts.

TestStep

Appears in:

TestStep contains the test step definition used in a test spec.

Field Type Required Inline Description
name string

Name of the step.
TestStepSpec TestStepSpec ✅ ✅

TestStepSpec of the step.

TestStepSpec

Appears in:

TestStepSpec defines the desired state and behavior for each test step.

Field Type Required Inline Description
description string

Description contains a description of the test step.
timeouts Timeouts

Timeouts for the test step. Overrides the global timeouts set in the Configuration and the timeouts eventually set in the Test.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
skipDelete bool

SkipDelete determines whether the resources created by the step should be deleted after the test step is executed.
template bool

Template determines whether resources should be considered for templating.
bindings []Binding

Bindings defines additional binding key/values.
try []Operation ✅

Try defines what the step will try to execute.
catch []Catch

Catch defines what the step will execute when an error happens.
finally []Finally

Finally defines what the step will execute after the step is terminated.

Timeouts

Appears in:

Timeouts contains timeouts per operation.

Field Type Required Inline Description
apply meta/v1.Duration ✅

Apply defines the timeout for the apply operation
assert meta/v1.Duration ✅

Assert defines the timeout for the assert operation
cleanup meta/v1.Duration ✅

Cleanup defines the timeout for the cleanup operation
delete meta/v1.Duration ✅

Delete defines the timeout for the delete operation
error meta/v1.Duration ✅

Error defines the timeout for the error operation
exec meta/v1.Duration ✅

Exec defines the timeout for exec operations

Update

Appears in:

Update represents a set of resources that should be updated. If a resource does not exist in the cluster it will fail.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Overrides the global timeout set in the Configuration.
bindings []Binding

Bindings defines additional binding key/values.
outputs []Output

Outputs defines output bindings.
cluster string

Cluster defines the target cluster (default cluster will be used if not specified and/or overridden).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
FileRefOrResource FileRefOrResource ✅ ✅

FileRefOrResource provides a reference to the file containing the resources to be created.
template bool

Template determines whether resources should be considered for templating.
dryRun bool

DryRun determines whether the file should be applied in dry run mode.
expect []Expectation

Expect defines a list of matched checks to validate the operation outcome.

Wait

Appears in:

Wait specifies how to perform wait operations on resources.

Field Type Required Inline Description
timeout meta/v1.Duration

Timeout for the operation. Specifies how long to wait for the condition to be met before timing out.
cluster string

Cluster defines the target cluster where the wait operation will be performed (default cluster will be used if not specified).
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
ResourceReference ResourceReference ✅ ✅

ResourceReference referenced resource type.
ObjectLabelsSelector ObjectLabelsSelector ✅ ✅

ObjectLabelsSelector determines the selection process of referenced objects.
for For ✅

For specifies the condition to wait for.
format Format

Format determines the output format (json or yaml).
\ No newline at end of file diff --git a/main/apis/chainsaw.v1alpha2/index.html b/main/apis/chainsaw.v1alpha2/index.html index b743902a2..bf0c01e59 100644 --- a/main/apis/chainsaw.v1alpha2/index.html +++ b/main/apis/chainsaw.v1alpha2/index.html @@ -1 +1 @@ - chainsaw (v1alpha2) - Chainsaw
Skip to content

v1alpha2

Package v1alpha2 contains API Schema definitions for the v1alpha2 API group.

Resource Types

Configuration

Configuration is the resource that contains the configuration used to run tests.

Field Type Required Inline Description
apiVersion string ✅ chainsaw.kyverno.io/v1alpha2
kind string ✅ Configuration
metadata meta/v1.ObjectMeta

Standard object's metadata.
spec ConfigurationSpec ✅

Configuration spec.

Cleanup

Appears in:

Cleanup contains the cleanup configuration.

Field Type Required Inline Description
skipDelete bool

If set, do not delete the resources after running a test.
delayBeforeCleanup meta/v1.Duration

DelayBeforeCleanup adds a delay between the time a test ends and the time cleanup starts.

ConfigurationSpec

Appears in:

ConfigurationSpec contains the configuration used to run tests.

Field Type Required Inline Description
catch []Catch

Catch defines what the tests steps will execute when an error happens. This will be combined with catch handlers defined at the test and step levels.
cleanup Cleanup

Cleanup contains cleanup configuration.
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
discovery Discovery

Discovery contains tests discovery configuration.
execution Execution

Execution contains tests execution configuration.
namespace Namespace

Namespace contains properties for the namespace to use for tests.
report Report

Report contains properties for the report.
templating Templating

Templating contains the templating config.
timeouts Timeouts

Global timeouts configuration. Applies to all tests/test steps if not overridden.

Discovery

Appears in:

Discovery contains the tests discovery configuration.

Field Type Required Inline Description
excludeTestRegex string

ExcludeTestRegex is used to exclude tests based on a regular expression.
includeTestRegex string

IncludeTestRegex is used to include tests based on a regular expression.
testFile string

TestFile is the name of the file containing the test to run. If no extension is provided, chainsaw will try with .yaml first and .yml if needed.
fullName bool

FullName makes use of the full test case folder path instead of the folder name.

Execution

Appears in:

Execution contains the runner configuration.

Field Type Required Inline Description
failFast bool

FailFast determines whether the test should stop upon encountering the first failure.
parallel int

The maximum number of tests to run at once.
repeatCount int

RepeatCount indicates how many times the tests should be executed.
forceTerminationGracePeriod meta/v1.Duration

ForceTerminationGracePeriod forces the termination grace period on pods, statefulsets, daemonsets and deployments.

Namespace

Appears in:

Namespace contains info about the namespace used for testing.

Field Type Required Inline Description
name string

Name defines the namespace to use for tests. If not specified, every test will execute in a random ephemeral namespace unless the namespace is overridden in a the test spec.
template policy/v1alpha1.Any

Template defines a template to create the test namespace.

Report

Appears in:

Report contains info about the report.

Field Type Required Inline Description
format ReportFormatType

ReportFormat determines test report format (JSON
path string

ReportPath defines the path.
name string

ReportName defines the name of report to create. It defaults to "chainsaw-report".

ReportFormatType

(Alias of string)

Appears in:

Templating

Appears in:

Templating contains the templating configuration.

Field Type Required Inline Description
enabled bool

Enabled determines whether resources should be considered for templating.
\ No newline at end of file + chainsaw (v1alpha2) - Chainsaw
Skip to content

v1alpha2

Package v1alpha2 contains API Schema definitions for the v1alpha2 API group.

Resource Types

Configuration

Configuration is the resource that contains the configuration used to run tests.

Field Type Required Inline Description
apiVersion string ✅ chainsaw.kyverno.io/v1alpha2
kind string ✅ Configuration
metadata meta/v1.ObjectMeta

Standard object's metadata.
spec ConfigurationSpec ✅

Configuration spec.

Cleanup

Appears in:

Cleanup contains the cleanup configuration.

Field Type Required Inline Description
skipDelete bool

If set, do not delete the resources after running a test.
delayBeforeCleanup meta/v1.Duration

DelayBeforeCleanup adds a delay between the time a test ends and the time cleanup starts.

ConfigurationSpec

Appears in:

ConfigurationSpec contains the configuration used to run tests.

Field Type Required Inline Description
catch []Catch

Catch defines what the tests steps will execute when an error happens. This will be combined with catch handlers defined at the test and step levels.
cleanup Cleanup

Cleanup contains cleanup configuration.
clusters map[string]Cluster

Clusters holds a registry to clusters to support multi-cluster tests.
discovery Discovery

Discovery contains tests discovery configuration.
execution Execution

Execution contains tests execution configuration.
namespace Namespace

Namespace contains properties for the namespace to use for tests.
report Report

Report contains properties for the report.
templating Templating

Templating contains the templating config.
timeouts Timeouts

Global timeouts configuration. Applies to all tests/test steps if not overridden.

Discovery

Appears in:

Discovery contains the tests discovery configuration.

Field Type Required Inline Description
excludeTestRegex string

ExcludeTestRegex is used to exclude tests based on a regular expression.
includeTestRegex string

IncludeTestRegex is used to include tests based on a regular expression.
testFile string

TestFile is the name of the file containing the test to run. If no extension is provided, chainsaw will try with .yaml first and .yml if needed.
fullName bool

FullName makes use of the full test case folder path instead of the folder name.

Execution

Appears in:

Execution contains the runner configuration.

Field Type Required Inline Description
failFast bool

FailFast determines whether the test should stop upon encountering the first failure.
parallel int

The maximum number of tests to run at once.
repeatCount int

RepeatCount indicates how many times the tests should be executed.
forceTerminationGracePeriod meta/v1.Duration

ForceTerminationGracePeriod forces the termination grace period on pods, statefulsets, daemonsets and deployments.

Namespace

Appears in:

Namespace contains info about the namespace used for testing.

Field Type Required Inline Description
name string

Name defines the namespace to use for tests. If not specified, every test will execute in a random ephemeral namespace unless the namespace is overridden in a the test spec.
template policy/v1alpha1.Any

Template defines a template to create the test namespace.

Report

Appears in:

Report contains info about the report.

Field Type Required Inline Description
format ReportFormatType

ReportFormat determines test report format (JSON
path string

ReportPath defines the path.
name string

ReportName defines the name of report to create. It defaults to "chainsaw-report".

ReportFormatType

(Alias of string)

Appears in:

Templating

Appears in:

Templating contains the templating configuration.

Field Type Required Inline Description
enabled bool

Enabled determines whether resources should be considered for templating.
\ No newline at end of file diff --git a/main/bindings/index.html b/main/bindings/index.html index 6d097d81e..11df7ca80 100644 --- a/main/bindings/index.html +++ b/main/bindings/index.html @@ -1,4 +1,4 @@ - Bindings - Chainsaw
Skip to content

Bindings

Chainsaw has a concept of bindings which can be seen as an execution context.

Bindings are used in assertion trees and resource templating, as well as when using the --values flag when invoking chainsaw.

While some bindings are built-in and provided by chainsaw, it's possible to define custom bindings at the test, step, or individual operation level. Those bindings can in turn be used to create custom environment variables in command and script operations.

Immutability

It's important to note that bindings are immutable, it's not possible to overwrite a binding and two bindings with the same name can exist without overwriting each other.

When a binding value is resolved, chainsaw will walk the binding chain upwards until it finds a binding with the expected name. Effectively, the last one registered in the chain will be used.

Templating

A binding name supports templating.

The name of a binding can therefore be dynamic and depend on values or other bindings.

Usage

The example below defines custom bindings at the test level.

Test level bindings

apiVersion: chainsaw.kyverno.io/v1alpha1
+ Bindings - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Bindings
 
Chainsaw has a concept of bindings which can be seen as an execution context.
 
Bindings are used in assertion trees and resource templating, as well as when using the --values flag when invoking chainsaw.
 
While some bindings are built-in and provided by chainsaw, it's possible to define custom bindings at the test, step, or individual operation level. Those bindings can in turn be used to create custom environment variables in command and script operations.
 
Immutability
 
It's important to note that bindings are immutable, it's not possible to overwrite a binding and two bindings with the same name can exist without overwriting each other.
 
When a binding value is resolved, chainsaw will walk the binding chain upwards until it finds a binding with the expected name. Effectively, the last one registered in the chain will be used.
 
Templating
 
A binding name supports templating.
 
The name of a binding can therefore be dynamic and depend on values or other bindings.
 
Usage
 
The example below defines custom bindings at the test level.
 
 
Test level bindings
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/bindings/outputs/index.html b/main/bindings/outputs/index.html
index 3e32f6977..f31e7f9a7 100644
--- a/main/bindings/outputs/index.html
+++ b/main/bindings/outputs/index.html
@@ -1,4 +1,4 @@
- Outputs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Outputs
 
Binding outputs can be useful to communicate and reuse computation results between operations.
 
Supported operations
 
Currently, only script and command operations support outputs.
 
Lifetime of outputs
 
Once an output has been added in the form of a binding, this binding will be available to all following operations in the same step.
 
Currently, outputs do not cross the step boundaries.
 
Matching
 
An output supports an optional match field. The match is used to conditionally create a binding.
 
In the case of applying a file, for example, the file may contain multiple resources. The match can be used to select the resource to use for creating the binding.
 
Examples
 
The example below defines invokes a kubectl command to get a configmap from the cluster in json format.
 
The json output is then parsed and added to the $cm binding and the next operation performs an assertion on it by reading the binding instead of querying the cluster.
 
 
Output in script
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Outputs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Outputs
 
Binding outputs can be useful to communicate and reuse computation results between operations.
 
Supported operations
 
Currently, only script and command operations support outputs.
 
Lifetime of outputs
 
Once an output has been added in the form of a binding, this binding will be available to all following operations in the same step.
 
Currently, outputs do not cross the step boundaries.
 
Matching
 
An output supports an optional match field. The match is used to conditionally create a binding.
 
In the case of applying a file, for example, the file may contain multiple resources. The match can be used to select the resource to use for creating the binding.
 
Examples
 
The example below defines invokes a kubectl command to get a configmap from the cluster in json format.
 
The json output is then parsed and added to the $cm binding and the next operation performs an assertion on it by reading the binding instead of querying the cluster.
 
 
Output in script
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/collectors/describe/index.html b/main/collectors/describe/index.html
index 41729074b..23b857b61 100644
--- a/main/collectors/describe/index.html
+++ b/main/collectors/describe/index.html
@@ -1,4 +1,4 @@
- Describe - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Describe
 
Describing resources present in the cluster can help understand what happened and troubleshoot test failures.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Describe resource is documented here.
    •  
 
 
 
Deprecated syntax
 
You can specify the resource directly instead of using apiVersion and kind.
 
This is a deprecated syntax though and will be removed in a future version.
 
 
Clustered resources
 
When used with a clustered resource, the namespace is ignored and is not added to the corresponding kubectl command.
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Describe pods
 
If a name is specified, Chainsaw will describe resources that have a name starting with the provided name in the test namespace (or in the cluster if it is a clustered-level resource).
 
 
Describe pods in the test namespace
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Describe - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Describe
 
Describing resources present in the cluster can help understand what happened and troubleshoot test failures.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Describe resource is documented here.
    •  
 
 
 
Deprecated syntax
 
You can specify the resource directly instead of using apiVersion and kind.
 
This is a deprecated syntax though and will be removed in a future version.
 
 
Clustered resources
 
When used with a clustered resource, the namespace is ignored and is not added to the corresponding kubectl command.
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Describe pods
 
If a name is specified, Chainsaw will describe resources that have a name starting with the provided name in the test namespace (or in the cluster if it is a clustered-level resource).
 
 
Describe pods in the test namespace
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/collectors/events/index.html b/main/collectors/events/index.html
index 4d3cb63ba..38d2e2e29 100644
--- a/main/collectors/events/index.html
+++ b/main/collectors/events/index.html
@@ -1,4 +1,4 @@
- Events - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Events
 
Collecting namespace events can help understand what happened inside the cluster.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Events resource is documented here.
    •  
 
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Single event
 
If a name is specified, Chainsaw will retrieve the specified event in the test namespace.
 
 
Collect event in the test namespace
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Events - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Events
 
Collecting namespace events can help understand what happened inside the cluster.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Events resource is documented here.
    •  
 
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Single event
 
If a name is specified, Chainsaw will retrieve the specified event in the test namespace.
 
 
Collect event in the test namespace
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/collectors/get/index.html b/main/collectors/get/index.html
index eb2d68a44..59e3edc0f 100644
--- a/main/collectors/get/index.html
+++ b/main/collectors/get/index.html
@@ -1,4 +1,4 @@
- Get - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Get
 
The get collector is used to list and print resources in the cluster.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Get resource is documented here.
    •  
 
 
 
Deprecated syntax
 
You can specify the resource directly instead of using apiVersion and kind.
 
This is a deprecated syntax though and will be removed in a future version.
 
 
Clustered resources
 
When used with a clustered resource, the namespace is ignored and is not added to the corresponding kubectl command.
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Single resource
 
If a name is specified, Chainsaw will retrieve the specified resource in the test namespace.
 
 
Get pod in the test namespace
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Get - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Get
 
The get collector is used to list and print resources in the cluster.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Get resource is documented here.
    •  
 
 
 
Deprecated syntax
 
You can specify the resource directly instead of using apiVersion and kind.
 
This is a deprecated syntax though and will be removed in a future version.
 
 
Clustered resources
 
When used with a clustered resource, the namespace is ignored and is not added to the corresponding kubectl command.
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Single resource
 
If a name is specified, Chainsaw will retrieve the specified resource in the test namespace.
 
 
Get pod in the test namespace
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/collectors/index.html b/main/collectors/index.html
index daafda510..a21cad761 100644
--- a/main/collectors/index.html
+++ b/main/collectors/index.html
@@ -1 +1 @@
- Collectors - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Collectors
 
Purpose
 
The purpose of collectors is to collect certain information about the outcome of a step should it fail (in the case of catch) or at the end of the step (in the case of finally).
 
The ultimate goal of collectors is to gather information about the failure of a step and therefore help understand what caused it to fail.
 
A test step can have an arbitrary number of collectors.
 
Available collectors
  
Templating
 
All string fields in collectors support templating.
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+ Collectors - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Collectors
 
Purpose
 
The purpose of collectors is to collect certain information about the outcome of a step should it fail (in the case of catch) or at the end of the step (in the case of finally).
 
The ultimate goal of collectors is to gather information about the failure of a step and therefore help understand what caused it to fail.
 
A test step can have an arbitrary number of collectors.
 
Available collectors
  
Templating
 
All string fields in collectors support templating.
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/collectors/pod-logs/index.html b/main/collectors/pod-logs/index.html
index 543167605..ff82950dc 100644
--- a/main/collectors/pod-logs/index.html
+++ b/main/collectors/pod-logs/index.html
@@ -1,4 +1,4 @@
- Pod logs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Pod logs
 
Collecting pod logs can help understand what happened inside one or more pods.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the PodLogs resource is documented here.
    •  
 
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Single pod
 
If a pod name is specified, Chainsaw will retrieve logs from this specific pod in the test namespace.
 
 
Collect pod logs in the test namespace
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Pod logs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Pod logs
 
Collecting pod logs can help understand what happened inside one or more pods.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the PodLogs resource is documented here.
    •  
 
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Single pod
 
If a pod name is specified, Chainsaw will retrieve logs from this specific pod in the test namespace.
 
 
Collect pod logs in the test namespace
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/commands/chainsaw/index.html b/main/commands/chainsaw/index.html
index 753cd340c..c6b39930f 100644
--- a/main/commands/chainsaw/index.html
+++ b/main/commands/chainsaw/index.html
@@ -1,3 +1,3 @@
- Chainsaw - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw
 
chainsaw
 
Stronger tool for e2e testing
 
chainsaw [flags]
+ Chainsaw - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw
 
chainsaw
 
Stronger tool for e2e testing
 
chainsaw [flags]
 
 
Options
 
  -h, --help   help for chainsaw
 
 
SEE ALSO
  
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/commands/chainsaw_assert/index.html b/main/commands/chainsaw_assert/index.html
index e6f5922e0..e09c19ecf 100644
--- a/main/commands/chainsaw_assert/index.html
+++ b/main/commands/chainsaw_assert/index.html
@@ -1,4 +1,4 @@
- Chainsaw assert - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw assert
 
chainsaw assert
 
Evaluate assertion
 
chainsaw assert [flags] [FILE]
+ Chainsaw assert - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw assert
 
chainsaw assert
 
Evaluate assertion
 
chainsaw assert [flags] [FILE]
 
 
Options
 
      --clustered                           Defines if the resource is clustered (only applies when resource is loaded from a file)
   -f, --file string                         Path to the file to assert or '-' to read from stdin
   -h, --help                                help for assert
diff --git a/main/commands/chainsaw_build/index.html b/main/commands/chainsaw_build/index.html
index fdc9c2dd2..e63bd7b2a 100644
--- a/main/commands/chainsaw_build/index.html
+++ b/main/commands/chainsaw_build/index.html
@@ -1,3 +1,3 @@
- Chainsaw build - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw build
 
chainsaw build
 
Build commands
 
chainsaw build [flags]
+ Chainsaw build - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw build
 
chainsaw build
 
Build commands
 
chainsaw build [flags]
 
 
Options
 
  -h, --help   help for build
 
 
SEE ALSO
  
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/commands/chainsaw_build_docs/index.html b/main/commands/chainsaw_build_docs/index.html
index d2a56e63b..63c5598b5 100644
--- a/main/commands/chainsaw_build_docs/index.html
+++ b/main/commands/chainsaw_build_docs/index.html
@@ -1,4 +1,4 @@
- Chainsaw build docs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw build docs
 
chainsaw build docs
 
Build tests documentation
 
chainsaw build docs [flags]
+ Chainsaw build docs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw build docs
 
chainsaw build docs
 
Build tests documentation
 
chainsaw build docs [flags]
 
 
Options
 
      --catalog string         Path to the built test catalog file
   -h, --help                   help for docs
       --readme-file string     Name of the built docs file (default "README.md")
diff --git a/main/commands/chainsaw_completion/index.html b/main/commands/chainsaw_completion/index.html
index 829379f98..fee833e8f 100644
--- a/main/commands/chainsaw_completion/index.html
+++ b/main/commands/chainsaw_completion/index.html
@@ -1,2 +1,2 @@
- Chainsaw completion - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion
 
chainsaw completion
 
Generate the autocompletion script for the specified shell
 
Synopsis
 
Generate the autocompletion script for chainsaw for the specified shell. See each sub-command's help for details on how to use the generated script.
 
Options
 
  -h, --help   help for completion
+ Chainsaw completion - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion
 
chainsaw completion
 
Generate the autocompletion script for the specified shell
 
Synopsis
 
Generate the autocompletion script for chainsaw for the specified shell. See each sub-command's help for details on how to use the generated script.
 
Options
 
  -h, --help   help for completion
 
 
SEE ALSO
  
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/commands/chainsaw_completion_bash/index.html b/main/commands/chainsaw_completion_bash/index.html
index b72cabd6b..4dfc99a46 100644
--- a/main/commands/chainsaw_completion_bash/index.html
+++ b/main/commands/chainsaw_completion_bash/index.html
@@ -1,4 +1,4 @@
- Chainsaw completion bash - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion bash
 
chainsaw completion bash
 
Generate the autocompletion script for bash
 
Synopsis
 
Generate the autocompletion script for the bash shell.
 
This script depends on the 'bash-completion' package. If it is not installed already, you can install it via your OS's package manager.
 
To load completions in your current shell session:
 
source <(chainsaw completion bash)
+ Chainsaw completion bash - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion bash
 
chainsaw completion bash
 
Generate the autocompletion script for bash
 
Synopsis
 
Generate the autocompletion script for the bash shell.
 
This script depends on the 'bash-completion' package. If it is not installed already, you can install it via your OS's package manager.
 
To load completions in your current shell session:
 
source <(chainsaw completion bash)
 
 
To load completions for every new session, execute once:
 
Linux:
 
chainsaw completion bash > /etc/bash_completion.d/chainsaw
 
 
macOS:
 
chainsaw completion bash > $(brew --prefix)/etc/bash_completion.d/chainsaw
 
 
You will need to start a new shell for this setup to take effect.
 
chainsaw completion bash
diff --git a/main/commands/chainsaw_completion_fish/index.html b/main/commands/chainsaw_completion_fish/index.html
index ff8d86829..a02b3fb21 100644
--- a/main/commands/chainsaw_completion_fish/index.html
+++ b/main/commands/chainsaw_completion_fish/index.html
@@ -1,4 +1,4 @@
- Chainsaw completion fish - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion fish
 
chainsaw completion fish
 
Generate the autocompletion script for fish
 
Synopsis
 
Generate the autocompletion script for the fish shell.
 
To load completions in your current shell session:
 
chainsaw completion fish | source
+ Chainsaw completion fish - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion fish
 
chainsaw completion fish
 
Generate the autocompletion script for fish
 
Synopsis
 
Generate the autocompletion script for the fish shell.
 
To load completions in your current shell session:
 
chainsaw completion fish | source
 
 
To load completions for every new session, execute once:
 
chainsaw completion fish > ~/.config/fish/completions/chainsaw.fish
 
 
You will need to start a new shell for this setup to take effect.
 
chainsaw completion fish [flags]
 
 
Options
 
  -h, --help              help for fish
diff --git a/main/commands/chainsaw_completion_powershell/index.html b/main/commands/chainsaw_completion_powershell/index.html
index 7212aa3da..f7f3dc511 100644
--- a/main/commands/chainsaw_completion_powershell/index.html
+++ b/main/commands/chainsaw_completion_powershell/index.html
@@ -1,4 +1,4 @@
- Chainsaw completion powershell - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion powershell
 
chainsaw completion powershell
 
Generate the autocompletion script for powershell
 
Synopsis
 
Generate the autocompletion script for powershell.
 
To load completions in your current shell session:
 
chainsaw completion powershell | Out-String | Invoke-Expression
+ Chainsaw completion powershell - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion powershell
 
chainsaw completion powershell
 
Generate the autocompletion script for powershell
 
Synopsis
 
Generate the autocompletion script for powershell.
 
To load completions in your current shell session:
 
chainsaw completion powershell | Out-String | Invoke-Expression
 
 
To load completions for every new session, add the output of the above command to your powershell profile.
 
chainsaw completion powershell [flags]
 
 
Options
 
  -h, --help              help for powershell
       --no-descriptions   disable completion descriptions
diff --git a/main/commands/chainsaw_completion_zsh/index.html b/main/commands/chainsaw_completion_zsh/index.html
index 3d405ac32..552bf79fe 100644
--- a/main/commands/chainsaw_completion_zsh/index.html
+++ b/main/commands/chainsaw_completion_zsh/index.html
@@ -1,4 +1,4 @@
- Chainsaw completion zsh - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion zsh
 
chainsaw completion zsh
 
Generate the autocompletion script for zsh
 
Synopsis
 
Generate the autocompletion script for the zsh shell.
 
If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once:
 
echo "autoload -U compinit; compinit" >> ~/.zshrc
+ Chainsaw completion zsh - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw completion zsh
 
chainsaw completion zsh
 
Generate the autocompletion script for zsh
 
Synopsis
 
Generate the autocompletion script for the zsh shell.
 
If shell completion is not already enabled in your environment you will need to enable it. You can execute the following once:
 
echo "autoload -U compinit; compinit" >> ~/.zshrc
 
 
To load completions in your current shell session:
 
source <(chainsaw completion zsh)
 
 
To load completions for every new session, execute once:
 
Linux:
 
chainsaw completion zsh > "${fpath[1]}/_chainsaw"
 
 
macOS:
 
chainsaw completion zsh > $(brew --prefix)/share/zsh/site-functions/_chainsaw
diff --git a/main/commands/chainsaw_create/index.html b/main/commands/chainsaw_create/index.html
index 9825bd10a..0bb51220d 100644
--- a/main/commands/chainsaw_create/index.html
+++ b/main/commands/chainsaw_create/index.html
@@ -1,3 +1,3 @@
- Chainsaw create - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw create
 
chainsaw create
 
Create Chainsaw resources
 
chainsaw create [flags]
+ Chainsaw create - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw create
 
chainsaw create
 
Create Chainsaw resources
 
chainsaw create [flags]
 
 
Options
 
  -h, --help   help for create
 
 
SEE ALSO
  
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/commands/chainsaw_create_test/index.html b/main/commands/chainsaw_create_test/index.html
index 97779c350..576c23cf3 100644
--- a/main/commands/chainsaw_create_test/index.html
+++ b/main/commands/chainsaw_create_test/index.html
@@ -1,4 +1,4 @@
- Chainsaw create test - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw create test
 
chainsaw create test
 
Create a Chainsaw test
 
chainsaw create test [flags]
+ Chainsaw create test - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw create test
 
chainsaw create test
 
Create a Chainsaw test
 
chainsaw create test [flags]
 
 
Options
 
      --description   If set, adds description when applicable (default true)
       --force         If set, existing test will be deleted if needed
   -h, --help          help for test
diff --git a/main/commands/chainsaw_docs/index.html b/main/commands/chainsaw_docs/index.html
index 2bdab44f4..3c8d7deb1 100644
--- a/main/commands/chainsaw_docs/index.html
+++ b/main/commands/chainsaw_docs/index.html
@@ -1,4 +1,4 @@
- Chainsaw docs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw docs
 
chainsaw docs
 
Generate reference documentation
 
chainsaw docs [flags]
+ Chainsaw docs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw docs
 
chainsaw docs
 
Generate reference documentation
 
chainsaw docs [flags]
 
 
Options
 
      --autogenTag      Determines if the generated docs should contain a timestamp (default true)
   -h, --help            help for docs
   -o, --output string   Output path (default ".")
diff --git a/main/commands/chainsaw_export/index.html b/main/commands/chainsaw_export/index.html
index 017c138d3..97f4bf576 100644
--- a/main/commands/chainsaw_export/index.html
+++ b/main/commands/chainsaw_export/index.html
@@ -1,3 +1,3 @@
- Chainsaw export - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw export
 
chainsaw export
 
Export commands
 
chainsaw export [flags]
+ Chainsaw export - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw export
 
chainsaw export
 
Export commands
 
chainsaw export [flags]
 
 
Options
 
  -h, --help   help for export
 
 
SEE ALSO
  
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/commands/chainsaw_export_schemas/index.html b/main/commands/chainsaw_export_schemas/index.html
index d41630dda..729ba3aff 100644
--- a/main/commands/chainsaw_export_schemas/index.html
+++ b/main/commands/chainsaw_export_schemas/index.html
@@ -1,3 +1,3 @@
- Chainsaw export schemas - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw export schemas
 
chainsaw export schemas
 
Export JSON schemas
 
chainsaw export schemas [flags]
+ Chainsaw export schemas - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw export schemas
 
chainsaw export schemas
 
Export JSON schemas
 
chainsaw export schemas [flags]
 
 
Options
 
  -h, --help   help for schemas
 
 
SEE ALSO
  
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/commands/chainsaw_lint/index.html b/main/commands/chainsaw_lint/index.html
index 0fe759e2a..300561aa1 100644
--- a/main/commands/chainsaw_lint/index.html
+++ b/main/commands/chainsaw_lint/index.html
@@ -1,4 +1,4 @@
- Chainsaw lint - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw lint
 
chainsaw lint
 
Lint a file or read from standard input
 
Synopsis
 
Use chainsaw lint to lint a specific file or read from standard input for either test or configuration.
 
chainsaw lint [test|configuration] [flags]
+ Chainsaw lint - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw lint
 
chainsaw lint
 
Lint a file or read from standard input
 
Synopsis
 
Use chainsaw lint to lint a specific file or read from standard input for either test or configuration.
 
chainsaw lint [test|configuration] [flags]
 
 
Options
 
  -f, --file string   Specify the file to lint or '-' for standard input
   -h, --help          help for lint
 
 
SEE ALSO
 
     
  • chainsaw - Stronger tool for e2e testing
    •  
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/commands/chainsaw_migrate/index.html b/main/commands/chainsaw_migrate/index.html
index 973345e2d..1d1611c79 100644
--- a/main/commands/chainsaw_migrate/index.html
+++ b/main/commands/chainsaw_migrate/index.html
@@ -1,3 +1,3 @@
- Chainsaw migrate - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw migrate
 
chainsaw migrate
 
Migrate resources to Chainsaw
 
chainsaw migrate [flags]
+ Chainsaw migrate - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw migrate
 
chainsaw migrate
 
Migrate resources to Chainsaw
 
chainsaw migrate [flags]
 
 
Options
 
  -h, --help   help for migrate
 
 
SEE ALSO
  
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/commands/chainsaw_migrate_kuttl/index.html b/main/commands/chainsaw_migrate_kuttl/index.html
index 93f74e358..22fba4bbd 100644
--- a/main/commands/chainsaw_migrate_kuttl/index.html
+++ b/main/commands/chainsaw_migrate_kuttl/index.html
@@ -1,3 +1,3 @@
- Chainsaw migrate kuttl - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw migrate kuttl
 
chainsaw migrate kuttl
 
Migrate KUTTL resources to Chainsaw
 
chainsaw migrate kuttl [flags]
+ Chainsaw migrate kuttl - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
  
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/commands/chainsaw_migrate_kuttl_config/index.html b/main/commands/chainsaw_migrate_kuttl_config/index.html
index fd0a8d999..ed91a1046 100644
--- a/main/commands/chainsaw_migrate_kuttl_config/index.html
+++ b/main/commands/chainsaw_migrate_kuttl_config/index.html
@@ -1,4 +1,4 @@
- Chainsaw migrate kuttl config - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw migrate kuttl config
 
chainsaw migrate kuttl config
 
Migrate KUTTL config to Chainsaw
 
chainsaw migrate kuttl config [flags]
+ Chainsaw migrate kuttl config - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw migrate kuttl config
 
chainsaw migrate kuttl config
 
Migrate KUTTL config to Chainsaw
 
chainsaw migrate kuttl config [flags]
 
 
Options
 
      --cleanup   If set, delete converted files
   -h, --help      help for config
       --save      If set, converted files will be saved
diff --git a/main/commands/chainsaw_migrate_kuttl_tests/index.html b/main/commands/chainsaw_migrate_kuttl_tests/index.html
index 705e22c70..db9b5af3f 100644
--- a/main/commands/chainsaw_migrate_kuttl_tests/index.html
+++ b/main/commands/chainsaw_migrate_kuttl_tests/index.html
@@ -1,4 +1,4 @@
- Chainsaw migrate kuttl tests - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw migrate kuttl tests
 
chainsaw migrate kuttl tests
 
Migrate KUTTL tests to Chainsaw
 
chainsaw migrate kuttl tests [flags]
+ Chainsaw migrate kuttl tests - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw migrate kuttl tests
 
chainsaw migrate kuttl tests
 
Migrate KUTTL tests to Chainsaw
 
chainsaw migrate kuttl tests [flags]
 
 
Options
 
      --cleanup   If set, delete converted files
   -h, --help      help for tests
       --save      If set, converted files will be saved
diff --git a/main/commands/chainsaw_test/index.html b/main/commands/chainsaw_test/index.html
index 4562c09bd..8cc107aa2 100644
--- a/main/commands/chainsaw_test/index.html
+++ b/main/commands/chainsaw_test/index.html
@@ -1,4 +1,4 @@
- Chainsaw test - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw test
 
chainsaw test
 
Run tests
 
chainsaw test [flags]... [test directories]...
+ Chainsaw test - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw test
 
chainsaw test
 
Run tests
 
chainsaw test [flags]... [test directories]...
 
 
Options
 
      --apply-timeout duration                    The apply timeout to use as default for configuration (default 5s)
       --assert-timeout duration                   The assert timeout to use as default for configuration (default 30s)
       --cleanup-delay duration                    Adds a delay between the time a test ends and the time cleanup starts
diff --git a/main/commands/chainsaw_version/index.html b/main/commands/chainsaw_version/index.html
index 3e4d70751..712202039 100644
--- a/main/commands/chainsaw_version/index.html
+++ b/main/commands/chainsaw_version/index.html
@@ -1,3 +1,3 @@
- Chainsaw version - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw version
 
chainsaw version
 
Print the version informations
 
chainsaw version [flags]
+ Chainsaw version - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Chainsaw version
 
chainsaw version
 
Print the version informations
 
chainsaw version [flags]
 
 
Options
 
  -h, --help   help for version
 
 
SEE ALSO
 
     
  • chainsaw - Stronger tool for e2e testing
    •  
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/community/index.html b/main/community/index.html
index 40c079fc7..3703ff3a1 100644
--- a/main/community/index.html
+++ b/main/community/index.html
@@ -1 +1 @@
- Community - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Community
 
Chainsaw has a growing community and we would definitely love to see you join and contribute.
 
Everyone is welcome to make suggestions, report bugs, open feature requests, contribute code or docs, participate in discussions, write blogs or anything that can benefit the project.
 
 
 Chainsaw is built and maintained under the Kyverno umbrella but decisions are
 
Community driven
 
Everyone's voice matters
 
 
 
Slack channel
 
Join our slack channel #kyverno-chainsaw to meet with users, contributors and maintainers.
 
Community Meetings
 
To attend our community meetings, join the Chainsaw group. You will then be sent a meeting invite and will have access to the agenda and meeting notes. Any member may suggest topics for discussion.
 
This is a public, weekly for Kyverno-Chainsaw maintainers to make announcements and provide project updates, and request input and feedback. This forum allows community members to raise agenda items of any sort, including but not limited to any PRs or issues on which they are working.
 
Weekly every Thursday at 2:00 PM UTC
  
RoadMap
 
For detailed information on our planned features and upcoming updates, please view our Roadmap.
 
Contributing
 
Please read the contributing guide for details around:
 
     
  1. Code of Conduct
    2.  
  2. Code Culture
    3.  
  3. Details on how to contribute
    4.  
 
Adopters
 
If you are using Chainsaw and want to share it publicly we always appreciate a bit of support. Pull requests to the ADOPTERS LIST will put a smile on our faces 😄
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+ Community - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Community
 
Chainsaw has a growing community and we would definitely love to see you join and contribute.
 
Everyone is welcome to make suggestions, report bugs, open feature requests, contribute code or docs, participate in discussions, write blogs or anything that can benefit the project.
 
 
 Chainsaw is built and maintained under the Kyverno umbrella but decisions are
 
Community driven
 
Everyone's voice matters
 
 
 
Slack channel
 
Join our slack channel #kyverno-chainsaw to meet with users, contributors and maintainers.
 
Community Meetings
 
To attend our community meetings, join the Chainsaw group. You will then be sent a meeting invite and will have access to the agenda and meeting notes. Any member may suggest topics for discussion.
 
This is a public, weekly for Kyverno-Chainsaw maintainers to make announcements and provide project updates, and request input and feedback. This forum allows community members to raise agenda items of any sort, including but not limited to any PRs or issues on which they are working.
 
Weekly every Thursday at 2:00 PM UTC
  
RoadMap
 
For detailed information on our planned features and upcoming updates, please view our Roadmap.
 
Contributing
 
Please read the contributing guide for details around:
 
     
  1. Code of Conduct
    2.  
  2. Code Culture
    3.  
  3. Details on how to contribute
    4.  
 
Adopters
 
If you are using Chainsaw and want to share it publicly we always appreciate a bit of support. Pull requests to the ADOPTERS LIST will put a smile on our faces 😄
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/configuration/cleanup-delay/index.html b/main/configuration/cleanup-delay/index.html
index cdcaa5ec8..1c756fa22 100644
--- a/main/configuration/cleanup-delay/index.html
+++ b/main/configuration/cleanup-delay/index.html
@@ -1,4 +1,4 @@
- Delay before cleanup - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Delay before cleanup
 
At the end of each test, Chainsaw will delete the resources it created during the test.
 
When testing operators, it can be useful to wait a little bit before starting the cleanup process to make sure the operator/controller has the necessary time to update the internal state.
 
For this reason, Chainsaw provides the delayBeforeCleanup configuration option and the corresponding --delay-before-cleanup flag.
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Delay before cleanup - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Delay before cleanup
 
At the end of each test, Chainsaw will delete the resources it created during the test.
 
When testing operators, it can be useful to wait a little bit before starting the cleanup process to make sure the operator/controller has the necessary time to update the internal state.
 
For this reason, Chainsaw provides the delayBeforeCleanup configuration option and the corresponding --delay-before-cleanup flag.
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Configuration
 metadata:
   name: custom-config
diff --git a/main/configuration/file/index.html b/main/configuration/file/index.html
index f96c4caa3..3b2c8cab2 100644
--- a/main/configuration/file/index.html
+++ b/main/configuration/file/index.html
@@ -1,4 +1,4 @@
- Configuration file - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Configuration file
 
Chainsaw is described as a Stronger tool for e2e testing.
 
With its versatile configuration options, you can customize the testing process to fit your needs.
 
Chainsaw prioritizes its configuration in the following order:
 
     
  1.  
    User-specified configuration
     
    If you explicitly provide a configuration file using a command-line flag
     
    2.  
  2.  
    Default configuration file
     
    If no configuration is specified, Chainsaw will look for a default file named .chainsaw.yaml in the current working directory
     
    3.  
  3.  
    Internal default configuration
     
    In the absence of both the above, Chainsaw will use a default configuration file embedded in the Chainsaw binary
     
    4.  
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Configuration file - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Configuration file
 
Chainsaw is described as a Stronger tool for e2e testing.
 
With its versatile configuration options, you can customize the testing process to fit your needs.
 
Chainsaw prioritizes its configuration in the following order:
 
     
  1.  
    User-specified configuration
     
    If you explicitly provide a configuration file using a command-line flag
     
    2.  
  2.  
    Default configuration file
     
    If no configuration is specified, Chainsaw will look for a default file named .chainsaw.yaml in the current working directory
     
    3.  
  3.  
    Internal default configuration
     
    In the absence of both the above, Chainsaw will use a default configuration file embedded in the Chainsaw binary
     
    4.  
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Configuration
 metadata:
   name: custom-config
diff --git a/main/configuration/flags/index.html b/main/configuration/flags/index.html
index 6140d1d6c..e2a779a1a 100644
--- a/main/configuration/flags/index.html
+++ b/main/configuration/flags/index.html
@@ -1,4 +1,4 @@
- Command line flags - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Command line flags
 
Even after a configuration file is loaded, you can override specific settings using command-line flags.
 
Example
 
chainsaw test                         \
+ Command line flags - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Command line flags
 
Even after a configuration file is loaded, you can override specific settings using command-line flags.
 
Example
 
chainsaw test                         \
     path/to/test/dir                    \
     --config path/to/your/config.yaml   \
     --assert-timeout 45s                \
diff --git a/main/configuration/grace/index.html b/main/configuration/grace/index.html
index a60024c2f..70c6d099a 100644
--- a/main/configuration/grace/index.html
+++ b/main/configuration/grace/index.html
@@ -1,4 +1,4 @@
- Termination graceful period - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Termination graceful period
 
Some Kubernetes resources can take time before being stopped. For example, deleting a Pod can take time if the underlying container doesn't quit quickly enough.
 
For this reason, Chainsaw provides the forceTerminationGracePeriod configuration option and the corresponding --force-termination-grace-period flag. If set, Chainsaw will override the terminationGracePeriodSeconds when working with the following resource kinds:
 
     
  • Pod
    •  
  • Deployment
    •  
  • StatefulSet
    •  
  • DaemonSet
    •  
  • Job
    •  
  • CronJob
    •  
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Termination graceful period - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Termination graceful period
 
Some Kubernetes resources can take time before being stopped. For example, deleting a Pod can take time if the underlying container doesn't quit quickly enough.
 
For this reason, Chainsaw provides the forceTerminationGracePeriod configuration option and the corresponding --force-termination-grace-period flag. If set, Chainsaw will override the terminationGracePeriodSeconds when working with the following resource kinds:
 
     
  • Pod
    •  
  • Deployment
    •  
  • StatefulSet
    •  
  • DaemonSet
    •  
  • Job
    •  
  • CronJob
    •  
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Configuration
 metadata:
   name: custom-config
diff --git a/main/configuration/index.html b/main/configuration/index.html
index d854d767a..036458a26 100644
--- a/main/configuration/index.html
+++ b/main/configuration/index.html
@@ -1 +1 @@
- Configuring Chainsaw - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Configuring Chainsaw
 
Chainsaw is a comprehensive tool designed to facilitate end-to-end testing in Kubernetes.
 
This documentation will focus on providing a breakdown of its configuration structure and how to use it.
 
Chainsaw can be configured in two different and complementary ways:
  
 
Precedence
 
If both are specified, command-line flags will take precedence over configuration coming from a configuration file.
 
 
Specific configuration options
 
Please pay attention to the configuration options below, they may or may not be relevant in your case but can be useful in certain cases:
  
 
  
  
  
 
 
 
     
\ No newline at end of file
+ Configuring Chainsaw - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Configuring Chainsaw
 
Chainsaw is a comprehensive tool designed to facilitate end-to-end testing in Kubernetes.
 
This documentation will focus on providing a breakdown of its configuration structure and how to use it.
 
Chainsaw can be configured in two different and complementary ways:
  
 
Precedence
 
If both are specified, command-line flags will take precedence over configuration coming from a configuration file.
 
 
Specific configuration options
 
Please pay attention to the configuration options below, they may or may not be relevant in your case but can be useful in certain cases:
  
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/configuration/multi-cluster/index.html b/main/configuration/multi-cluster/index.html
index 6f20e7ab3..1528612f7 100644
--- a/main/configuration/multi-cluster/index.html
+++ b/main/configuration/multi-cluster/index.html
@@ -1,4 +1,4 @@
- Multi cluster - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Multi cluster
 
Chainsaw supports testing against multiple clusters.
 
To use a specific cluster in a test (or test step) you will need to register the cluster either using the config file or using command line flags.
 
Since v0.2.1 you can also register clusters dynamically at the test, step and operation levels. This is particularly useful when a cluster is created in a test step and used in subsequent steps.
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Multi cluster - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Multi cluster
 
Chainsaw supports testing against multiple clusters.
 
To use a specific cluster in a test (or test step) you will need to register the cluster either using the config file or using command line flags.
 
Since v0.2.1 you can also register clusters dynamically at the test, step and operation levels. This is particularly useful when a cluster is created in a test step and used in subsequent steps.
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Configuration
 metadata:
   name: custom-config
diff --git a/main/configuration/no-cluster/index.html b/main/configuration/no-cluster/index.html
index 72c174b3f..f5e468a4f 100644
--- a/main/configuration/no-cluster/index.html
+++ b/main/configuration/no-cluster/index.html
@@ -1,3 +1,3 @@
- Running without a cluster - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Running without a cluster
 
Chainsaw can be run without connection to a Kubernetes cluster. In this case, chainsaw will not try to create an ephemeral namespace and all operations requiring a Kubernetes cluster will fail.
 
To run chainsaw in this mode pass the --no-cluster flag.
 
Example
 
# run chainsaw without connection to a Kubernetes cluster
+ Running without a cluster - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Running without a cluster
 
Chainsaw can be run without connection to a Kubernetes cluster. In this case, chainsaw will not try to create an ephemeral namespace and all operations requiring a Kubernetes cluster will fail.
 
To run chainsaw in this mode pass the --no-cluster flag.
 
Example
 
# run chainsaw without connection to a Kubernetes cluster
 chainsaw test --no-cluster
 
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/configuration/reports/index.html b/main/configuration/reports/index.html
index 796909d7c..dcba0c9b5 100644
--- a/main/configuration/reports/index.html
+++ b/main/configuration/reports/index.html
@@ -1,4 +1,4 @@
- Reports - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Reports
 
Chainsaw can generate JUnit reports in XML or JSON format.
 
To produce a test report, configure the report format, report path and report name in the configuration or using CLI flags.
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Reports - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Reports
 
Chainsaw can generate JUnit reports in XML or JSON format.
 
To produce a test report, configure the report format, report path and report name in the configuration or using CLI flags.
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Configuration
 metadata:
   name: custom-config
diff --git a/main/configuration/selector/index.html b/main/configuration/selector/index.html
index fa13afb1e..12dd7d90f 100644
--- a/main/configuration/selector/index.html
+++ b/main/configuration/selector/index.html
@@ -1,4 +1,4 @@
- Label selectors - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Label selectors
 
Chainsaw can filter the tests to run using label selectors.
 
You can pass label selectors using the --selector flag when invoking the chainsaw test command.
 
Example
 
Given the test below:
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Label selectors - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Label selectors
 
Chainsaw can filter the tests to run using label selectors.
 
You can pass label selectors using the --selector flag when invoking the chainsaw test command.
 
Example
 
Given the test below:
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: basic
diff --git a/main/configuration/templating/index.html b/main/configuration/templating/index.html
index dbb3985a4..0f3f5e2aa 100644
--- a/main/configuration/templating/index.html
+++ b/main/configuration/templating/index.html
@@ -1,4 +1,4 @@
- Resource templating - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Resource templating
 
 
Experimental status
 
This is an experimental feature, and implementation could change slightly in the next versions.
 
 
 
Info
 
Templating was disabled by default in v0.1.* but is now enabled by default since v0.2.1.
 
 
Chainsaw can apply transformations to the resources before they are processed by the operation.
 
This is useful when a resource needs some runtime configuration.
 
Templating must be enabled at the configuration, test, step, or operation level for the templating process to kick in. Alternatively, templating can be enabled using the --template flag when invoking chainsaw from the command line.
 
 
Note
 
Unlike assertion trees, templating can only be specified in leave nodes of the YAML tree.
 
 
Example
 
The test below will create, assert, and delete a ConfigMap with a dynamic name configured at runtime using the $namespace binding.
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Resource templating - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Resource templating
 
 
Experimental status
 
This is an experimental feature, and implementation could change slightly in the next versions.
 
 
 
Info
 
Templating was disabled by default in v0.1.* but is now enabled by default since v0.2.1.
 
 
Chainsaw can apply transformations to the resources before they are processed by the operation.
 
This is useful when a resource needs some runtime configuration.
 
Templating must be enabled at the configuration, test, step, or operation level for the templating process to kick in. Alternatively, templating can be enabled using the --template flag when invoking chainsaw from the command line.
 
 
Note
 
Unlike assertion trees, templating can only be specified in leave nodes of the YAML tree.
 
 
Example
 
The test below will create, assert, and delete a ConfigMap with a dynamic name configured at runtime using the $namespace binding.
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: values
diff --git a/main/configuration/timeouts/index.html b/main/configuration/timeouts/index.html
index bd4ca86ba..e1a56542b 100644
--- a/main/configuration/timeouts/index.html
+++ b/main/configuration/timeouts/index.html
@@ -1,4 +1,4 @@
- Timeouts - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Timeouts
 
Timeouts in Chainsaw are specified per type of operation. This is required because the timeout varies greatly depending on the nature of an operation.
 
For example, applying a manifest in a cluster is expected to be reasonably fast, while validating a resource can be a long operation.
 
Chainsaw supports separately configuring the timeouts below:
 
     
  •  
    Apply
     
    When Chainsaw applies manifests in a cluster
     
    •  
  •  
    Assert
     
    When Chainsaw validates resources in a cluster
     
    •  
  •  
    Cleanup
     
    When Chainsaw removes resources from a cluster created for a test
     
    •  
  •  
    Delete
     
    When Chainsaw deletes resources from a cluster
     
    •  
  •  
    Error
     
    When Chainsaw validates resources in a cluster
     
    •  
  •  
    Exec
     
    When Chainsaw executes arbitrary commands or scripts
     
    •  
 
 
Overriding timeouts
 
Each timeout can be overridden at the test level, test step level, or individual operation level.
 
Timeouts defined in the Configuration are used in operations when not overridden.
 
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Timeouts - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Timeouts
 
Timeouts in Chainsaw are specified per type of operation. This is required because the timeout varies greatly depending on the nature of an operation.
 
For example, applying a manifest in a cluster is expected to be reasonably fast, while validating a resource can be a long operation.
 
Chainsaw supports separately configuring the timeouts below:
 
     
  •  
    Apply
     
    When Chainsaw applies manifests in a cluster
     
    •  
  •  
    Assert
     
    When Chainsaw validates resources in a cluster
     
    •  
  •  
    Cleanup
     
    When Chainsaw removes resources from a cluster created for a test
     
    •  
  •  
    Delete
     
    When Chainsaw deletes resources from a cluster
     
    •  
  •  
    Error
     
    When Chainsaw validates resources in a cluster
     
    •  
  •  
    Exec
     
    When Chainsaw executes arbitrary commands or scripts
     
    •  
 
 
Overriding timeouts
 
Each timeout can be overridden at the test level, test step level, or individual operation level.
 
Timeouts defined in the Configuration are used in operations when not overridden.
 
 
Configuration
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Configuration
 metadata:
   name: custom-config
diff --git a/main/configuration/values/index.html b/main/configuration/values/index.html
index d389acd45..1f4d2c04b 100644
--- a/main/configuration/values/index.html
+++ b/main/configuration/values/index.html
@@ -1,4 +1,4 @@
- Passing data to tests - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Passing data to tests
 
Chainsaw can pass arbitrary values when running tests using the --values flag. Values will be available to tests under the $values binding.
 
This is useful when a test needs to be configured externally.
 
Example
 
The test below expects the $value.foo to be provided when chainsaw is invoked.
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Passing data to tests - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Passing data to tests
 
Chainsaw can pass arbitrary values when running tests using the --values flag. Values will be available to tests under the $values binding.
 
This is useful when a test needs to be configured externally.
 
Example
 
The test below expects the $value.foo to be provided when chainsaw is invoked.
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: values
diff --git a/main/docs/index.html b/main/docs/index.html
index 9ff0ee164..49f7772e0 100644
--- a/main/docs/index.html
+++ b/main/docs/index.html
@@ -1 +1 @@
- Documentation - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Documentation
 
Starting with Chainsaw v0.0.6 we maintain separate docs per version:
  
 
  
  
  
 
 
 
     
\ No newline at end of file
+ Documentation - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Documentation
 
Starting with Chainsaw v0.0.6 we maintain separate docs per version:
  
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/examples/array-assertions/index.html b/main/examples/array-assertions/index.html
index 157697b69..5f424a396 100644
--- a/main/examples/array-assertions/index.html
+++ b/main/examples/array-assertions/index.html
@@ -1,4 +1,4 @@
- Array assertions - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Array assertions
 
This example demonstrates how to perform complex assertions on arrays.
 
Setup
 
See Setup docs
 
Manifests
 
resources.yaml
 
apiVersion: v1
+ Array assertions - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Array assertions
 
This example demonstrates how to perform complex assertions on arrays.
 
Setup
 
See Setup docs
 
Manifests
 
resources.yaml
 
apiVersion: v1
 kind: Pod
 metadata:
   name: example
diff --git a/main/examples/assertion-tree/index.html b/main/examples/assertion-tree/index.html
index 6ac1711bb..f40d16ea6 100644
--- a/main/examples/assertion-tree/index.html
+++ b/main/examples/assertion-tree/index.html
@@ -1,4 +1,4 @@
- Assertion trees - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Assertion trees
 
Test steps:
 
     
  1. Creates a Deployment with 2 replicas
    2.  
  2. Asserts that the number of replicas is > 1 and that status.replicas == spec.replicas
    3.  
 
Setup
 
See Setup docs
 
Manifests
 
resources.yaml
 
apiVersion: apps/v1
+ Assertion trees - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Assertion trees
 
Test steps:
 
     
  1. Creates a Deployment with 2 replicas
    2.  
  2. Asserts that the number of replicas is > 1 and that status.replicas == spec.replicas
    3.  
 
Setup
 
See Setup docs
 
Manifests
 
resources.yaml
 
apiVersion: apps/v1
 kind: Deployment
 metadata:
   name: nginx-deployment
diff --git a/main/examples/basic/index.html b/main/examples/basic/index.html
index d9edd7b73..21e00b6b3 100644
--- a/main/examples/basic/index.html
+++ b/main/examples/basic/index.html
@@ -1,4 +1,4 @@
- Basic - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Basic
 
Test steps:
 
     
  1. Creates a ConfigMap
    2.  
  2. Asserts the ConfigMap contains the expected data
    3.  
 
Setup
 
See Setup docs
 
Manifests
 
resources.yaml
 
apiVersion: v1
+ Basic - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Basic
 
Test steps:
 
     
  1. Creates a ConfigMap
    2.  
  2. Asserts the ConfigMap contains the expected data
    3.  
 
Setup
 
See Setup docs
 
Manifests
 
resources.yaml
 
apiVersion: v1
 kind: ConfigMap
 metadata:
   name: quick-start
diff --git a/main/examples/index.html b/main/examples/index.html
index 353243905..d01780362 100644
--- a/main/examples/index.html
+++ b/main/examples/index.html
@@ -1,4 +1,4 @@
- Examples - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Setup
 
To use Chainsaw you will need a Kubernetes cluster, Chainsaw won't create one for you.
 
In these examples, we will use kind but feel free to use the tool of your choice.
 
 
Not a cluster management tool
 
We consider this is not the responsibility of Chainsaw to manage clusters.
 
There are plenty of solutions to create and manage local clusters that will do that better than Chainsaw.
 
 
Create a kind cluster
 
Please refer to the kind install docs to install it locally.
 
Once kind creating a local cluster is as simple as running:
 
# define kind image
+ Examples - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Setup
 
To use Chainsaw you will need a Kubernetes cluster, Chainsaw won't create one for you.
 
In these examples, we will use kind but feel free to use the tool of your choice.
 
 
Not a cluster management tool
 
We consider this is not the responsibility of Chainsaw to manage clusters.
 
There are plenty of solutions to create and manage local clusters that will do that better than Chainsaw.
 
 
Create a kind cluster
 
Please refer to the kind install docs to install it locally.
 
Once kind creating a local cluster is as simple as running:
 
# define kind image
 export KIND_IMAGE="kindest/node:v1.28.0"
 
 # create cluster
diff --git a/main/examples/inline/index.html b/main/examples/inline/index.html
index 6ff76de7b..233e6b368 100644
--- a/main/examples/inline/index.html
+++ b/main/examples/inline/index.html
@@ -1,4 +1,4 @@
- Inline resources - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Inline resources
 
Test steps:
 
     
  1. Creates a ConfigMap
    2.  
  2. Asserts the ConfigMap contains the expected data
    3.  
 
Setup
 
See Setup docs
 
Test
 
chainsaw-test.yaml
 
# yaml-language-server: $schema=https://raw.githubusercontent.com/kyverno/chainsaw/main/.schemas/json/test-chainsaw-v1alpha1.json
+ Inline resources - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Inline resources
 
Test steps:
 
     
  1. Creates a ConfigMap
    2.  
  2. Asserts the ConfigMap contains the expected data
    3.  
 
Setup
 
See Setup docs
 
Test
 
chainsaw-test.yaml
 
# yaml-language-server: $schema=https://raw.githubusercontent.com/kyverno/chainsaw/main/.schemas/json/test-chainsaw-v1alpha1.json
 apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
diff --git a/main/examples/labels-selector/index.html b/main/examples/labels-selector/index.html
index 4b9ec38f6..7a804cee9 100644
--- a/main/examples/labels-selector/index.html
+++ b/main/examples/labels-selector/index.html
@@ -1,4 +1,4 @@
- Labels selector - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Labels selector
 
Test steps:
 
     
  1. Creates a ConfigMap
    2.  
  2. Asserts the ConfigMap contains the expected data
    3.  
 
This test is similar to the basic example but Chainsaw is invoked with the --selector flag.
 
Setup
 
See Setup docs
 
Manifests
 
resources.yaml
 
apiVersion: v1
+ Labels selector - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Labels selector
 
Test steps:
 
     
  1. Creates a ConfigMap
    2.  
  2. Asserts the ConfigMap contains the expected data
    3.  
 
This test is similar to the basic example but Chainsaw is invoked with the --selector flag.
 
Setup
 
See Setup docs
 
Manifests
 
resources.yaml
 
apiVersion: v1
 kind: ConfigMap
 metadata:
   name: quick-start
diff --git a/main/examples/non-resource-assertion/index.html b/main/examples/non-resource-assertion/index.html
index 5fd405ca6..ed4e7939a 100644
--- a/main/examples/non-resource-assertion/index.html
+++ b/main/examples/non-resource-assertion/index.html
@@ -1,4 +1,4 @@
- Non resource assertion - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Non resource assertion
 
This test example demonstrates how to perform assertions not based on resources.
 
     
  1. Asserts that the number of nodes in the cluster is equal to 1
    2.  
 
Setup
 
See Setup docs
 
Manifests
 
assertions.yaml
 
(x_k8s_list($client, 'v1', 'Node')):
+ Non resource assertion - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Non resource assertion
 
This test example demonstrates how to perform assertions not based on resources.
 
     
  1. Asserts that the number of nodes in the cluster is equal to 1
    2.  
 
Setup
 
See Setup docs
 
Manifests
 
assertions.yaml
 
(x_k8s_list($client, 'v1', 'Node')):
   (length(items): 1
 
 
Test
 
chainsaw-test.yaml
 
# yaml-language-server: $schema=https://raw.githubusercontent.com/kyverno/chainsaw/main/.schemas/json/test-chainsaw-v1alpha1.json
 apiVersion: chainsaw.kyverno.io/v1alpha1
diff --git a/main/examples/test-output/index.html b/main/examples/test-output/index.html
index ed1c36a2e..db3ec6ea2 100644
--- a/main/examples/test-output/index.html
+++ b/main/examples/test-output/index.html
@@ -1,4 +1,4 @@
- Testing command output - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Testing command output
 
Chainsaw can be used to easily check terminal output from CLIs and other commands. This is useful in that convoluted bash scripts involving chaining together tools like grep can be avoided or at least minimized to only complex use cases. Output to both stdout and stderr can be checked for a given string or precise contents.
 
Checking Output Contains
 
One basic use case for content checking is that the output simply contains a given string or piece of content. For example, you might want to run automated tests on a CLI binary you build to ensure that a given command produces output that contains some content you specify somewhere in the output. Let's use the following output from the kubectl version command to show these examples.
 
kubectl version
+ Testing command output - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Testing command output
 
Chainsaw can be used to easily check terminal output from CLIs and other commands. This is useful in that convoluted bash scripts involving chaining together tools like grep can be avoided or at least minimized to only complex use cases. Output to both stdout and stderr can be checked for a given string or precise contents.
 
Checking Output Contains
 
One basic use case for content checking is that the output simply contains a given string or piece of content. For example, you might want to run automated tests on a CLI binary you build to ensure that a given command produces output that contains some content you specify somewhere in the output. Let's use the following output from the kubectl version command to show these examples.
 
kubectl version
 
 Client Version: v1.28.2
 Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
@@ -76,4 +76,4 @@
           ($error != null): true
           # This checks that the output is exactly as intended.
           ($stderr): "error: unknown command \"foo\" for \"kubectl\"\n\nDid you mean this?\n\ttop"
-
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/gh-action/index.html b/main/gh-action/index.html
index 2d81c3197..47654364a 100644
--- a/main/gh-action/index.html
+++ b/main/gh-action/index.html
@@ -1,4 +1,4 @@
- GitHub action - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
GitHub action
 
A GitHub action is available to easily install Chainsaw in your workflows.
 
The GitHub action is available at kyverno/action-install-chainsaw or in the marketplace.
 
Usage
 
This action currently supports GitHub-provided Linux, macOS and Windows runners (self-hosted runners may not work).
 
Add the following entry to your Github workflow YAML file:
 
uses: kyverno/action-install-chainsaw@v0.1.0
+ GitHub action - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
GitHub action
 
A GitHub action is available to easily install Chainsaw in your workflows.
 
The GitHub action is available at kyverno/action-install-chainsaw or in the marketplace.
 
Usage
 
This action currently supports GitHub-provided Linux, macOS and Windows runners (self-hosted runners may not work).
 
Add the following entry to your Github workflow YAML file:
 
uses: kyverno/action-install-chainsaw@v0.1.0
 with:
   release: v0.1.0 # optional
 
 
Example using a pinned version:
 
jobs:
diff --git a/main/index.html b/main/index.html
index fcbcee718..55e39e655 100644
--- a/main/index.html
+++ b/main/index.html
@@ -1,4 +1,4 @@
- Chainsaw - End-to-end testing tool - Chainsaw     
 
 
 
  
  
 
       
 
 
 
  
  
 
   
 
 
 
 
 
 
Kyverno Chainsaw
 
Kyverno end to end testing tool !
 
     
  • Used internally to continuously test Kyverno
    •  
  • Entirely low code and declarative
    •  
  • Provides an advanced and flexible assertion model
    •  
  • Run it locally or in your CI/CD pipelines
    •  
  • ... and much more!
    •  
  Get started   Learn more  
 
  
 
 
      
 
 
 
 
 
 
 
 
 Everything you would expect  
 
 
 
     
  •  
      
     
     
    Easy to install
     
     Install locally using a package manager like brew or nix, or simply download the binary from one of our releases. If you want to run using a Docker image, we have that too. 
     
     
    •  
  •  
      
     
     
    Easy to use
     
     Write tests in minutes, not hours. All it takes is a YAML file to define the steps of a test. Chainsaw will do the rest, no need to learn a programing language or write a single line of code! 
     
     
    •  
  •  
      
     
     
    Comprehensive reporting
     
     Understand and diagnose failures easily, thanks to a comprehensive output showing precisely what failed and why. Generate JUnit compatible reports to integrate with other test reporting tools. 
     
     
    •  
  •  
      
     
     
    Resource templating
     
     Kubernetes is all about resouces and tests need to work with resources. Chainsaw has built-in support for bindings, operation outputs and resource templating to describe complex test scenarios. 
     
     
    •  
  •  
      
     
     
    Stay focused
     
     Focus on the software you are building, write test scenarios using YAML and let Chainsaw tell you what passes or not. Integrate in your CI pipeline to prevent regressions and release with better confidence. 
     
     
    •  
  •  
      
     
     
    Multi cluster
     
     Native support for tests involving multiple clusters, either static or dynamically created ones, make Chainsaw an excellent tool for testing highly complex environments and architectures. 
     
     
    •  
 
 
 
 
 
 
 
 
 
 Widely adopted  
 
 
 
 
 
  Chainsaw cranked up the tempo, making our e2e tests dance to a rhythm of reliability and efficiency.  
 
 
 
  Chainsaw replaced Kuttl, and helped us get rid of many unreadable bash scripts.  
 
 
 
  Running all end to end tests for both Kyverno and the policies catalog.  
 
 
 
  Chainsaw cut down on hacks, improved code-reuse and enhanced test debugging.  
 
 
 
  Chainsaw replaced Kuttl and made our e2e tests much more readable and easier to debug.  
 
 
 
  Chainsaw helped a lot for declarative assertion of Redis Cluster state against various e2e test.  
 
 
 
 
 
 
 
 
 
 Discover Chainsaw in video  
 
 Watch this excellent review video to discover the unique power of Chainsaw. 
 
 
  
 
 
 
 
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+ 
 
 
 
 
 
 
Kyverno Chainsaw
 
Kyverno end to end testing tool !
 
     
  • Used internally to continuously test Kyverno
    •  
  • Entirely low code and declarative
    •  
  • Provides an advanced and flexible assertion model
    •  
  • Run it locally or in your CI/CD pipelines
    •  
  • ... and much more!
    •  
  Get started   Learn more  
 
  
 
 
      
 
 
 
 
 
 
 
 
 Everything you would expect  
 
 
 
     
  •  
      
     
     
    Easy to install
     
     Install locally using a package manager like brew or nix, or simply download the binary from one of our releases. If you want to run using a Docker image, we have that too. 
     
     
    •  
  •  
      
     
     
    Easy to use
     
     Write tests in minutes, not hours. All it takes is a YAML file to define the steps of a test. Chainsaw will do the rest, no need to learn a programing language or write a single line of code! 
     
     
    •  
  •  
      
     
     
    Comprehensive reporting
     
     Understand and diagnose failures easily, thanks to a comprehensive output showing precisely what failed and why. Generate JUnit compatible reports to integrate with other test reporting tools. 
     
     
    •  
  •  
      
     
     
    Resource templating
     
     Kubernetes is all about resouces and tests need to work with resources. Chainsaw has built-in support for bindings, operation outputs and resource templating to describe complex test scenarios. 
     
     
    •  
  •  
      
     
     
    Stay focused
     
     Focus on the software you are building, write test scenarios using YAML and let Chainsaw tell you what passes or not. Integrate in your CI pipeline to prevent regressions and release with better confidence. 
     
     
    •  
  •  
      
     
     
    Multi cluster
     
     Native support for tests involving multiple clusters, either static or dynamically created ones, make Chainsaw an excellent tool for testing highly complex environments and architectures. 
     
     
    •  
 
 
 
 
 
 
 
 
 
 Widely adopted  
 
 
 
 
 
  Chainsaw cranked up the tempo, making our e2e tests dance to a rhythm of reliability and efficiency.  
 
 
 
  Chainsaw replaced Kuttl, and helped us get rid of many unreadable bash scripts.  
 
 
 
  Running all end to end tests for both Kyverno and the policies catalog.  
 
 
 
  Chainsaw cut down on hacks, improved code-reuse and enhanced test debugging.  
 
 
 
  Chainsaw replaced Kuttl and made our e2e tests much more readable and easier to debug.  
 
 
 
  Chainsaw helped a lot for declarative assertion of Redis Cluster state against various e2e test.  
 
 
 
 
 
 
 
 
 
 Discover Chainsaw in video  
 
 Watch this excellent review video to discover the unique power of Chainsaw. 
 
 
  
 
 
 
 
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/install/index.html b/main/install/index.html
index a89fce627..141a5a136 100644
--- a/main/install/index.html
+++ b/main/install/index.html
@@ -1,4 +1,4 @@
- Install - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Install
 
You can install the pre-compiled binary (in several ways), compile from sources, or run with Docker.
 
We also provide a GitHub action to easily install Chainsaw in your workflows.
 
Install the pre-compiled binary
 
Homebrew tap
 
add tap:
 
brew tap kyverno/chainsaw https://github.com/kyverno/chainsaw
+ Install - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Install
 
You can install the pre-compiled binary (in several ways), compile from sources, or run with Docker.
 
We also provide a GitHub action to easily install Chainsaw in your workflows.
 
Install the pre-compiled binary
 
Homebrew tap
 
add tap:
 
brew tap kyverno/chainsaw https://github.com/kyverno/chainsaw
 
 
install chainsaw:
 
brew install kyverno/chainsaw/chainsaw
 
 
 
Don't forget to specify the tap name
 
Homebrew core already has a tool named chainsaw.
 
Be sure that you specify the tap name when installing to install the right tool.
 
 
Manually
 
Download the pre-compiled binaries for your system from the releases page and copy them to the desired location.
 
Install using go install
 
You can install with go install with:
 
go install github.com/kyverno/chainsaw@latest
 
 
Running with Docker
 
Chainsaw is also available as a Docker image which you can pull and run:
 
docker pull ghcr.io/kyverno/chainsaw:<version>
diff --git a/main/intro/index.html b/main/intro/index.html
index c0c85e477..c1b52c61a 100644
--- a/main/intro/index.html
+++ b/main/intro/index.html
@@ -1 +1 @@
- Introduction - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Introduction
 
Chainsaw is a tool developed to run end to end tests in Kubernetes clusters.
 
It is meant to test Kubernetes operators work as expected by running a sequence of test steps for:
 
     
  • Creating resources
    •  
  • Asserting operators react (or not) the way they should
    •  
 
Why we made it ?
 
While developing Kyverno we need to run end to end tests to make sure our admission controller works as expected.
 
 
A typical Kyverno end to end test
 
Kyverno can validate, mutate and generate resources based on policies installed in a cluster and a typical test is:
 
     
  1. Create a policy
    2.  
  2. Create a resource
    3.  
  3. Check that Kyverno acted as expected
    4.  
  4. Cleanup and move to the next test
    5.  
 
 
From KUTTL to Chainsaw
 
We started with another tool called KUTTL.
 
While KUTTL was a great tool to start with, we quickly identified some limitations and forked it to add the features we needed.
 
In the end we needed more flexibility than what KUTTL could offer and we started designing a new assertion model and at this point it was simpler to start a new tool from scratch than continuing making changes in our KUTTL fork.
 
The changes we were making was simply too large to have a chance to be incorporated upstream.
 
Chainsaw was born 🎉
 
KUTTL compatibility
 
Fortunately, Chainsaw assertion model is compatible with KUTTL and therefore migration to Chainsaw is relatively easy.
 
We provide chainsaw migrate kuttl config and chainsaw migrate kuttl tests commands to assist with the migration, see Migration from KUTTL for details.
 
Use cases
 
Chainsaw is built with CI tools in mind - you only really need to download and execute it in your build script.
 
Installing it in your machine is entirely up to you, but still possible.
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+ Introduction - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Introduction
 
Chainsaw is a tool developed to run end to end tests in Kubernetes clusters.
 
It is meant to test Kubernetes operators work as expected by running a sequence of test steps for:
 
     
  • Creating resources
    •  
  • Asserting operators react (or not) the way they should
    •  
 
Why we made it ?
 
While developing Kyverno we need to run end to end tests to make sure our admission controller works as expected.
 
 
A typical Kyverno end to end test
 
Kyverno can validate, mutate and generate resources based on policies installed in a cluster and a typical test is:
 
     
  1. Create a policy
    2.  
  2. Create a resource
    3.  
  3. Check that Kyverno acted as expected
    4.  
  4. Cleanup and move to the next test
    5.  
 
 
From KUTTL to Chainsaw
 
We started with another tool called KUTTL.
 
While KUTTL was a great tool to start with, we quickly identified some limitations and forked it to add the features we needed.
 
In the end we needed more flexibility than what KUTTL could offer and we started designing a new assertion model and at this point it was simpler to start a new tool from scratch than continuing making changes in our KUTTL fork.
 
The changes we were making was simply too large to have a chance to be incorporated upstream.
 
Chainsaw was born 🎉
 
KUTTL compatibility
 
Fortunately, Chainsaw assertion model is compatible with KUTTL and therefore migration to Chainsaw is relatively easy.
 
We provide chainsaw migrate kuttl config and chainsaw migrate kuttl tests commands to assist with the migration, see Migration from KUTTL for details.
 
Use cases
 
Chainsaw is built with CI tools in mind - you only really need to download and execute it in your build script.
 
Installing it in your machine is entirely up to you, but still possible.
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/jp/functions/index.html b/main/jp/functions/index.html
index 527b32fbf..b5b6345d9 100644
--- a/main/jp/functions/index.html
+++ b/main/jp/functions/index.html
@@ -1 +1 @@
- Functions - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Functions
 
 
Experimental functions
 
Experimental functions are denoted by the x_ prefix.
 
These are functions that are subject to signature change in a future version.
 
 
built-in functions
 
  
 Name Signature 
   
 abs abs(number) 
 
 avg avg(array[number]) 
 
 ceil ceil(number) 
 
 contains contains(array|string, any) 
 
 ends_with ends_with(string, string) 
 
 find_first find_first(string, string, number, number) 
 
 find_last find_last(string, string, number, number) 
 
 floor floor(number) 
 
 from_items from_items(array[array]) 
 
 group_by group_by(array, expref) 
 
 items items(object) 
 
 join join(string, array[string]) 
 
 keys keys(object) 
 
 length length(string|array|object) 
 
 lower lower(string) 
 
 map map(expref, array) 
 
 max max(array[number]|array[string]) 
 
 max_by max_by(array, expref) 
 
 merge merge(object) 
 
 min min(array[number]|array[string]) 
 
 min_by min_by(array, expref) 
 
 not_null not_null(any) 
 
 pad_left pad_left(string, number, string) 
 
 pad_right pad_right(string, number, string) 
 
 replace replace(string, string, string, number) 
 
 reverse reverse(array|string) 
 
 sort sort(array[string]|array[number]) 
 
 sort_by sort_by(array, expref) 
 
 split split(string, string, number) 
 
 starts_with starts_with(string, string) 
 
 sum sum(array[number]) 
 
 to_array to_array(any) 
 
 to_number to_number(any) 
 
 to_string to_string(any) 
 
 trim trim(string, string) 
 
 trim_left trim_left(string, string) 
 
 trim_right trim_right(string, string) 
 
 type type(any) 
 
 upper upper(string) 
 
 values values(object) 
 
 zip zip(array, array) 
  
 
kyverno-json functions
 
  
 Name Signature 
   
 at at(array, any) 
 
 concat concat(string, string) 
 
 json_parse json_parse(string) 
 
 wildcard wildcard(string, string) 
  
 
kyverno functions
 
  
 Name Signature 
   
 compare compare(string, string) 
 
 equal_fold equal_fold(string, string) 
 
 replace replace(string, string, string, number) 
 
 replace_all replace_all(string, string, string) 
 
 to_upper to_upper(string) 
 
 to_lower to_lower(string) 
 
 trim trim(string, string) 
 
 trim_prefix trim_prefix(string, string) 
 
 split split(string, string) 
 
 regex_replace_all regex_replace_all(string, string|number, string|number) 
 
 regex_replace_all_literal regex_replace_all_literal(string, string|number, string|number) 
 
 regex_match regex_match(string, string|number) 
 
 pattern_match pattern_match(string, string|number) 
 
 label_match label_match(object, object) 
 
 to_boolean to_boolean(string) 
 
 add add(any, any) 
 
 sum sum(array) 
 
 subtract subtract(any, any) 
 
 multiply multiply(any, any) 
 
 divide divide(any, any) 
 
 modulo modulo(any, any) 
 
 round round(number, number) 
 
 base64_decode base64_decode(string) 
 
 base64_encode base64_encode(string) 
 
 time_since time_since(string, string, string) 
 
 time_now time_now() 
 
 time_now_utc time_now_utc() 
 
 path_canonicalize path_canonicalize(string) 
 
 truncate truncate(string, number) 
 
 semver_compare semver_compare(string, string) 
 
 parse_json parse_json(string) 
 
 parse_yaml parse_yaml(string) 
 
 lookup lookup(object|array, string|number) 
 
 items items(object|array, string, string) 
 
 object_from_lists object_from_lists(array, array) 
 
 random random(string) 
 
 x509_decode x509_decode(string) 
 
 time_to_cron time_to_cron(string) 
 
 time_add time_add(string, string) 
 
 time_parse time_parse(string, string) 
 
 time_utc time_utc(string) 
 
 time_diff time_diff(string, string) 
 
 time_before time_before(string, string) 
 
 time_after time_after(string, string) 
 
 time_between time_between(string, string, string) 
 
 time_truncate time_truncate(string, string) 
  
 
chainsaw functions
 
  
 Name Signature 
   
 env env(string) 
 
 x_k8s_get x_k8s_get(any, string, string, string, string) 
 
 x_k8s_list x_k8s_list(any, string, string, string) 
 
 x_k8s_exists x_k8s_exists(any, string, string, string, string) 
 
 x_k8s_resource_exists x_k8s_resource_exists(any, string, string) 
 
 x_k8s_server_version x_k8s_server_version(any) 
  
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+ Functions - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Functions
 
 
Experimental functions
 
Experimental functions are denoted by the x_ prefix.
 
These are functions that are subject to signature change in a future version.
 
 
built-in functions
 
  
 Name Signature 
   
 abs abs(number) 
 
 avg avg(array[number]) 
 
 ceil ceil(number) 
 
 contains contains(array|string, any) 
 
 ends_with ends_with(string, string) 
 
 find_first find_first(string, string, number, number) 
 
 find_last find_last(string, string, number, number) 
 
 floor floor(number) 
 
 from_items from_items(array[array]) 
 
 group_by group_by(array, expref) 
 
 items items(object) 
 
 join join(string, array[string]) 
 
 keys keys(object) 
 
 length length(string|array|object) 
 
 lower lower(string) 
 
 map map(expref, array) 
 
 max max(array[number]|array[string]) 
 
 max_by max_by(array, expref) 
 
 merge merge(object) 
 
 min min(array[number]|array[string]) 
 
 min_by min_by(array, expref) 
 
 not_null not_null(any) 
 
 pad_left pad_left(string, number, string) 
 
 pad_right pad_right(string, number, string) 
 
 replace replace(string, string, string, number) 
 
 reverse reverse(array|string) 
 
 sort sort(array[string]|array[number]) 
 
 sort_by sort_by(array, expref) 
 
 split split(string, string, number) 
 
 starts_with starts_with(string, string) 
 
 sum sum(array[number]) 
 
 to_array to_array(any) 
 
 to_number to_number(any) 
 
 to_string to_string(any) 
 
 trim trim(string, string) 
 
 trim_left trim_left(string, string) 
 
 trim_right trim_right(string, string) 
 
 type type(any) 
 
 upper upper(string) 
 
 values values(object) 
 
 zip zip(array, array) 
  
 
kyverno-json functions
 
  
 Name Signature 
   
 at at(array, any) 
 
 concat concat(string, string) 
 
 json_parse json_parse(string) 
 
 wildcard wildcard(string, string) 
  
 
kyverno functions
 
  
 Name Signature 
   
 compare compare(string, string) 
 
 equal_fold equal_fold(string, string) 
 
 replace replace(string, string, string, number) 
 
 replace_all replace_all(string, string, string) 
 
 to_upper to_upper(string) 
 
 to_lower to_lower(string) 
 
 trim trim(string, string) 
 
 trim_prefix trim_prefix(string, string) 
 
 split split(string, string) 
 
 regex_replace_all regex_replace_all(string, string|number, string|number) 
 
 regex_replace_all_literal regex_replace_all_literal(string, string|number, string|number) 
 
 regex_match regex_match(string, string|number) 
 
 pattern_match pattern_match(string, string|number) 
 
 label_match label_match(object, object) 
 
 to_boolean to_boolean(string) 
 
 add add(any, any) 
 
 sum sum(array) 
 
 subtract subtract(any, any) 
 
 multiply multiply(any, any) 
 
 divide divide(any, any) 
 
 modulo modulo(any, any) 
 
 round round(number, number) 
 
 base64_decode base64_decode(string) 
 
 base64_encode base64_encode(string) 
 
 time_since time_since(string, string, string) 
 
 time_now time_now() 
 
 time_now_utc time_now_utc() 
 
 path_canonicalize path_canonicalize(string) 
 
 truncate truncate(string, number) 
 
 semver_compare semver_compare(string, string) 
 
 parse_json parse_json(string) 
 
 parse_yaml parse_yaml(string) 
 
 lookup lookup(object|array, string|number) 
 
 items items(object|array, string, string) 
 
 object_from_lists object_from_lists(array, array) 
 
 random random(string) 
 
 x509_decode x509_decode(string) 
 
 time_to_cron time_to_cron(string) 
 
 time_add time_add(string, string) 
 
 time_parse time_parse(string, string) 
 
 time_utc time_utc(string) 
 
 time_diff time_diff(string, string) 
 
 time_before time_before(string, string) 
 
 time_after time_after(string, string) 
 
 time_between time_between(string, string, string) 
 
 time_truncate time_truncate(string, string) 
  
 
chainsaw functions
 
  
 Name Signature 
   
 env env(string) 
 
 x_k8s_get x_k8s_get(any, string, string, string, string) 
 
 x_k8s_list x_k8s_list(any, string, string, string) 
 
 x_k8s_exists x_k8s_exists(any, string, string, string, string) 
 
 x_k8s_resource_exists x_k8s_resource_exists(any, string, string) 
 
 x_k8s_server_version x_k8s_server_version(any) 
  
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/json-schemas/index.html b/main/json-schemas/index.html
index 9477f8fbc..35e0c4607 100644
--- a/main/json-schemas/index.html
+++ b/main/json-schemas/index.html
@@ -1,4 +1,4 @@
- JSON schemas - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
JSON schemas
 
JSON schemas for Chainsaw resources are available to enable validation and autocompletion in your IDE:
  
VS code
 
In VS code, simply add a comment on top of your YAML resources.
 
Test
 
# yaml-language-server: $schema=https://raw.githubusercontent.com/kyverno/chainsaw/main/.schemas/json/test-chainsaw-v1alpha1.json
+ JSON schemas - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
JSON schemas
 
JSON schemas for Chainsaw resources are available to enable validation and autocompletion in your IDE:
  
VS code
 
In VS code, simply add a comment on top of your YAML resources.
 
Test
 
# yaml-language-server: $schema=https://raw.githubusercontent.com/kyverno/chainsaw/main/.schemas/json/test-chainsaw-v1alpha1.json
 apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
diff --git a/main/more/crds/index.html b/main/more/crds/index.html
index fea4127b4..e18bf8057 100644
--- a/main/more/crds/index.html
+++ b/main/more/crds/index.html
@@ -1,4 +1,4 @@
- Working with CRDs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Working with CRDs
 
New Custom Resource Definitions are not immediately available for use in the Kubernetes API until the Kubernetes API has acknowledged them.
 
If a Custom Resource Definition is being defined inside of a test step, be sure to wait for the CustomResourceDefinition object to appear.
 
For example, given this Custom Resource Definition:
 
apiVersion: apiextensions.k8s.io/v1beta1
+ Working with CRDs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Working with CRDs
 
New Custom Resource Definitions are not immediately available for use in the Kubernetes API until the Kubernetes API has acknowledged them.
 
If a Custom Resource Definition is being defined inside of a test step, be sure to wait for the CustomResourceDefinition object to appear.
 
For example, given this Custom Resource Definition:
 
apiVersion: apiextensions.k8s.io/v1beta1
 kind: CustomResourceDefinition
 metadata:
   name: mycrds.mycrd.k8s.io
diff --git a/main/more/events/index.html b/main/more/events/index.html
index 59ec11dd6..2374cee06 100644
--- a/main/more/events/index.html
+++ b/main/more/events/index.html
@@ -1,4 +1,4 @@
- Working with events - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Working with events
 
Kubernetes events are regular Kubernetes objects and can be asserted on just like any other object:
 
apiVersion: v1
+ Working with events - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Working with events
 
Kubernetes events are regular Kubernetes objects and can be asserted on just like any other object:
 
apiVersion: v1
 kind: Event
 reason: Started
 source:
diff --git a/main/more/kuttl-migration/index.html b/main/more/kuttl-migration/index.html
index 041e3a6ee..937138e97 100644
--- a/main/more/kuttl-migration/index.html
+++ b/main/more/kuttl-migration/index.html
@@ -1,3 +1,3 @@
- Migration from KUTTL - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Migration from KUTTL
 
Overview
 
The chainsaw migrate kuttl tests and chainsaw migrate kuttl config commands are designed for the migration of KUTTL tests to Chainsaw.
  
 
Reference documentation
 
You can view the full command documentation here.
 
 
Examples
 
Migrate tests
 
The command below will migrate KUTTL tests to Chainsaw and overwrite original files with converted ones.
 
chainsaw migrate kuttl tests path/to/kuttl/tests --save --cleanup
+ Migration from KUTTL - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Migration from KUTTL
 
Overview
 
The chainsaw migrate kuttl tests and chainsaw migrate kuttl config commands are designed for the migration of KUTTL tests to Chainsaw.
  
 
Reference documentation
 
You can view the full command documentation here.
 
 
Examples
 
Migrate tests
 
The command below will migrate KUTTL tests to Chainsaw and overwrite original files with converted ones.
 
chainsaw migrate kuttl tests path/to/kuttl/tests --save --cleanup
 
 
This will generate a chainsaw-test.yaml for every KUTTL test discovered.
 
Migrate configuration
 
The command below will migrate a KUTTL test suite file to the corresponding Chainsaw Configuration.
 
chainsaw migrate kuttl config path/to/kuttl/testsuite --save --cleanup
 
 
This will generate a .chainsaw.yaml configuration file.
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/more/lint/index.html b/main/more/lint/index.html
index b09fbd059..ade8372ff 100644
--- a/main/more/lint/index.html
+++ b/main/more/lint/index.html
@@ -1,4 +1,4 @@
- Lint tests - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Lint tests
 
Overview
 
Chainsaw comes with a lint command to detect ill-formated tests.
 
 
Reference documentation
 
You can view the full command documentation here.
 
 
Usage
 
To build the docs of a test, Chainsaw provides the chainsaw lint test -f path/to/chainsaw-test.yaml command.
 
chainsaw lint test -f - <<EOF
+ Lint tests - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Lint tests
 
Overview
 
Chainsaw comes with a lint command to detect ill-formated tests.
 
 
Reference documentation
 
You can view the full command documentation here.
 
 
Usage
 
To build the docs of a test, Chainsaw provides the chainsaw lint test -f path/to/chainsaw-test.yaml command.
 
chainsaw lint test -f - <<EOF
 apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
diff --git a/main/more/test-docs/index.html b/main/more/test-docs/index.html
index ac4e4a533..2799b8cb2 100644
--- a/main/more/test-docs/index.html
+++ b/main/more/test-docs/index.html
@@ -1,4 +1,4 @@
- Building test docs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Building test docs
 
Overview
 
Chainsaw makes it simple to build the documentation of your tests.
 
As test suites grow, it becomes important to document what a test does and how it is supposed to work.
 
Going through the implementation of a test to understand its purpose is not an efficient strategy.
 
 
Reference documentation
 
You can view the full command documentation here.
 
 
Usage
 
To build the docs of a test, Chainsaw provides the chainsaw build docs command.
 
chainsaw build docs --test-dir path/to/chainsaw/tests
+ Building test docs - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Building test docs
 
Overview
 
Chainsaw makes it simple to build the documentation of your tests.
 
As test suites grow, it becomes important to document what a test does and how it is supposed to work.
 
Going through the implementation of a test to understand its purpose is not an efficient strategy.
 
 
Reference documentation
 
You can view the full command documentation here.
 
 
Usage
 
To build the docs of a test, Chainsaw provides the chainsaw build docs command.
 
chainsaw build docs --test-dir path/to/chainsaw/tests
 
 
This will automatically discover tests and document steps and operations in try, catch and finally statements.
 
The description field
 
Additionally, you can set the description field in:
 
     
  • TestSpec
    •  
  • TestStepSpec
    •  
  • Operation
    •  
  • Catch
    •  
  • Finally
    •  
 
Chainsaw will output them nicely in the built docs.
 
Example
 
See below for an example test and the corresponding built docs.
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
diff --git a/main/operations/apply/index.html b/main/operations/apply/index.html
index 8d0aa8a73..c640d0364 100644
--- a/main/operations/apply/index.html
+++ b/main/operations/apply/index.html
@@ -1,4 +1,4 @@
- Apply - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Apply
 
The apply operation lets you define resources that should be applied to the Kubernetes cluster during the test step.
 
These can be configurations, deployments, services, or any other Kubernetes resource.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Apply is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
Usage examples
 
Below is an example of using apply in a Test resource.
 
 
Using a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Apply - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Apply
 
The apply operation lets you define resources that should be applied to the Kubernetes cluster during the test step.
 
These can be configurations, deployments, services, or any other Kubernetes resource.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Apply is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
Usage examples
 
Below is an example of using apply in a Test resource.
 
 
Using a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/assert/index.html b/main/operations/assert/index.html
index d8a468195..7ae19e911 100644
--- a/main/operations/assert/index.html
+++ b/main/operations/assert/index.html
@@ -1,4 +1,4 @@
- Assert - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Assert
 
The assert operation allows you to specify conditions that should hold true for a successful test.
 
For example, after applying resources, you might want to ensure that a particular pod is running or a service is accessible.
 
 
Assertion trees
 
Assertions in Chainsaw are based on assertion trees.
 
Assertion trees are a solution to declaratively represent complex conditions like partial array comparisons or complex operations against an incoming data structure.
 
Assertion trees are compatible with standard assertions that exist in tools like KUTTL but can do a lot more. Please see the assertion trees documentation in kyverno-json for details.
 
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Assert is documented here.
    •  
  • This operation supports bindings.
    •  
 
 
Usage examples
 
Below is an example of using assert in a Test resource.
 
 
Using a specific file for assertions
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Assert - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Assert
 
The assert operation allows you to specify conditions that should hold true for a successful test.
 
For example, after applying resources, you might want to ensure that a particular pod is running or a service is accessible.
 
 
Assertion trees
 
Assertions in Chainsaw are based on assertion trees.
 
Assertion trees are a solution to declaratively represent complex conditions like partial array comparisons or complex operations against an incoming data structure.
 
Assertion trees are compatible with standard assertions that exist in tools like KUTTL but can do a lot more. Please see the assertion trees documentation in kyverno-json for details.
 
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Assert is documented here.
    •  
  • This operation supports bindings.
    •  
 
 
Usage examples
 
Below is an example of using assert in a Test resource.
 
 
Using a specific file for assertions
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/check/index.html b/main/operations/check/index.html
index aa306a13f..3ca0e170c 100644
--- a/main/operations/check/index.html
+++ b/main/operations/check/index.html
@@ -1 +1 @@
- Operation checks - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Operation checks
 
Considering an operation's success or failure is not always as simple as checking an error code.
 
     
  • Sometimes an operation can fail but the failure is what you expected, hence the operation should be reported as successful.
    •  
  • Sometimes an operation can succeed but the result is not what you expected, in this case, the operation should be reported as a failure.
    •  
 
To support those kinds of use cases, some operations support an additional check field to evaluate the operation result against an assertion tree.
 
 
Assertion trees
 
Assertions in Chainsaw are based on assertion trees.
 
Assertion trees are a solution to declaratively represent complex conditions like partial array comparisons or complex operations against an incoming data structure.
 
Assertion trees are compatible with standard assertions that exist in tools like KUTTL but can do a lot more. Please see the assertion trees documentation in kyverno-json for details.
 
 
 
Checked model
 
Different operations have a different model passed through the assertion tree.
 
The object passed to the assertion tree is the output object of the operation. Additional data like error or standard logs are passed using bindings ($error, $stdout, $stderr)
 
 
Expect vs Check
 
While a simple check is enough to determine the result of a single operation, we needed a more advanced construct to cover apply and create operations. Those operations can operate on files containing multiple manifests and every manifest can have a different result.
 
To support more granular checks we use the expect field that contains an array of Expectations. Every expectation is made of an optional match and a check statement.
 
This way it is possible to control the scope of a check.
 
 
Null match
 
If the match statement is null, the check statement applies to all manifests in the operation.
 
If no expectation matches a given manifest, the default expectation will be used, checking that no error occurred.
 
 
Apply
 
apply supports expect and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
Command
 
command supports check and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 $stdout The content of the standard console output (if any) at the end of the operation string 
 
 $stderr The content of the standard console error output (if any) at the end of the operation string 
 
 @ Always null  
  
 
Create
 
create supports expect and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
Delete
 
delete supports check and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
Patch
 
patch supports expect and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
Script
 
script supports check and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 $stdout The content of the standard console output (if any) at the end of the operation string 
 
 $stderr The content of the standard console error output (if any) at the end of the operation string 
 
 @ Always null  
  
 
Update
 
update supports expect and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+ Operation checks - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Operation checks
 
Considering an operation's success or failure is not always as simple as checking an error code.
 
     
  • Sometimes an operation can fail but the failure is what you expected, hence the operation should be reported as successful.
    •  
  • Sometimes an operation can succeed but the result is not what you expected, in this case, the operation should be reported as a failure.
    •  
 
To support those kinds of use cases, some operations support an additional check field to evaluate the operation result against an assertion tree.
 
 
Assertion trees
 
Assertions in Chainsaw are based on assertion trees.
 
Assertion trees are a solution to declaratively represent complex conditions like partial array comparisons or complex operations against an incoming data structure.
 
Assertion trees are compatible with standard assertions that exist in tools like KUTTL but can do a lot more. Please see the assertion trees documentation in kyverno-json for details.
 
 
 
Checked model
 
Different operations have a different model passed through the assertion tree.
 
The object passed to the assertion tree is the output object of the operation. Additional data like error or standard logs are passed using bindings ($error, $stdout, $stderr)
 
 
Expect vs Check
 
While a simple check is enough to determine the result of a single operation, we needed a more advanced construct to cover apply and create operations. Those operations can operate on files containing multiple manifests and every manifest can have a different result.
 
To support more granular checks we use the expect field that contains an array of Expectations. Every expectation is made of an optional match and a check statement.
 
This way it is possible to control the scope of a check.
 
 
Null match
 
If the match statement is null, the check statement applies to all manifests in the operation.
 
If no expectation matches a given manifest, the default expectation will be used, checking that no error occurred.
 
 
Apply
 
apply supports expect and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
Command
 
command supports check and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 $stdout The content of the standard console output (if any) at the end of the operation string 
 
 $stderr The content of the standard console error output (if any) at the end of the operation string 
 
 @ Always null  
  
 
Create
 
create supports expect and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
Delete
 
delete supports check and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
Patch
 
patch supports expect and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
Script
 
script supports check and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 $stdout The content of the standard console output (if any) at the end of the operation string 
 
 $stderr The content of the standard console error output (if any) at the end of the operation string 
 
 @ Always null  
  
 
Update
 
update supports expect and has the following elements to be checked:
 
  
 Name Purpose Type 
   
 $values Values provided when invoking chainsaw with --values flag object 
 
 $namespace Name of the current test namespace string 
 
 $client Kubernetes client chainsaw is connected to (if not running with --no-cluster) object 
 
 $config Kubernetes client config chainsaw is connected to (if not running with --no-cluster) object 
 
 $test.id Current test id int 
 
 $step.id Current step id int 
 
 $operation.id Current operation id int 
 
 $operation.resourceId Current resource id int 
 
 $error The error message (if any) at the end of the operation string 
 
 @ The state of the resource (if any) at the end of the operation object 
  
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/operations/command/index.html b/main/operations/command/index.html
index 4decac18a..5df818768 100644
--- a/main/operations/command/index.html
+++ b/main/operations/command/index.html
@@ -1,4 +1,4 @@
- Command - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Command
 
The command operation provides a means to execute a specific command during the test step.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Command is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
Usage examples
 
Below is an example of using command in a Test resource.
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Command - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Command
 
The command operation provides a means to execute a specific command during the test step.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Command is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
Usage examples
 
Below is an example of using command in a Test resource.
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/create/index.html b/main/operations/create/index.html
index 5a5a675dd..1f306feef 100644
--- a/main/operations/create/index.html
+++ b/main/operations/create/index.html
@@ -1,4 +1,4 @@
- Create - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Create
 
The create operation lets you define resources that should be created in the Kubernetes cluster during the test step. These can be configurations, deployments, services, or any other Kubernetes resource.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Create is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
 
Warning
 
If the resource to be created already exists in the cluster, the step will fail.
 
 
Usage examples
 
Below is an example of using create in a Test resource.
 
 
Using a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Create - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Create
 
The create operation lets you define resources that should be created in the Kubernetes cluster during the test step. These can be configurations, deployments, services, or any other Kubernetes resource.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Create is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
 
Warning
 
If the resource to be created already exists in the cluster, the step will fail.
 
 
Usage examples
 
Below is an example of using create in a Test resource.
 
 
Using a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/delete/index.html b/main/operations/delete/index.html
index 7a632b3e7..e4dcde939 100644
--- a/main/operations/delete/index.html
+++ b/main/operations/delete/index.html
@@ -1,4 +1,4 @@
- Delete - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Delete
 
The delete operation allows you to specify resources that should be deleted from the Kubernetes cluster before a particular test step is executed.
 
 
Info
 
The propagation policy is forced to Background because some types default to Orphan (this is the case for unmanaged jobs for example) and we don't want to let dangling pods run in the cluster after cleanup.
 
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Delete is documented here.
    •  
  • This operation supports bindings.
    •  
 
 
Usage examples
 
Below is an example of using delete in a Test resource.
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Delete - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Delete
 
The delete operation allows you to specify resources that should be deleted from the Kubernetes cluster before a particular test step is executed.
 
 
Info
 
The propagation policy is forced to Background because some types default to Orphan (this is the case for unmanaged jobs for example) and we don't want to let dangling pods run in the cluster after cleanup.
 
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Delete is documented here.
    •  
  • This operation supports bindings.
    •  
 
 
Usage examples
 
Below is an example of using delete in a Test resource.
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/error/index.html b/main/operations/error/index.html
index 2a54e10c8..555443731 100644
--- a/main/operations/error/index.html
+++ b/main/operations/error/index.html
@@ -1,4 +1,4 @@
- Error - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Error
 
The error operation lets you define a set of expected errors for a test step. If any of these errors occur during the test, they are treated as expected outcomes. However, if an error that's not on this list occurs, it will be treated as a test failure.
 
 
Assertion trees
 
Errors in Chainsaw are based on assertion trees.
 
Assertion trees is a solution to declaratively represent complex conditions like partial array comparisons or complex operations against an incoming data structure.
 
Assertion trees are compatible with standard assertions that exist in tools like KUTTL but can do a lot more. Please see the assertion trees documentation in kyverno-json for details.
 
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Error is documented here.
    •  
  • This operation supports bindings.
    •  
 
 
Usage examples
 
Below is an example of using error in a Test resource.
 
 
Expecting an error from a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Error - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Error
 
The error operation lets you define a set of expected errors for a test step. If any of these errors occur during the test, they are treated as expected outcomes. However, if an error that's not on this list occurs, it will be treated as a test failure.
 
 
Assertion trees
 
Errors in Chainsaw are based on assertion trees.
 
Assertion trees is a solution to declaratively represent complex conditions like partial array comparisons or complex operations against an incoming data structure.
 
Assertion trees are compatible with standard assertions that exist in tools like KUTTL but can do a lot more. Please see the assertion trees documentation in kyverno-json for details.
 
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Error is documented here.
    •  
  • This operation supports bindings.
    •  
 
 
Usage examples
 
Below is an example of using error in a Test resource.
 
 
Expecting an error from a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/index.html b/main/operations/index.html
index d6eab6fb6..a17575d05 100644
--- a/main/operations/index.html
+++ b/main/operations/index.html
@@ -1 +1 @@
- Operations - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Operations
 
While tests are made of test steps, test steps can be considered made of operations.
 
Every operation in a test step runs sequentially.
 
 
Only one action per operation
 
Every operation consists of a single action. While it is syntactically possible to create an operation with multiple actions, Chainsaw will verify and reject tests if operations containing multiple actions are found.
 
The reasoning behind this intentional choice is that it becomes harder to understand in which order actions will be executed in case an operation consists of multiple actions. For this reason, operations consisting of multiple actions are disallowed.
 
 
Common fields
 
All operations share some configuration fields.
 
 
Reference documentation
 
The full structure of the Operation is documented here.
 
 
ContinueOnError
 
Determines whether a test step should continue or not in case the operation is not successful.
 
 
Even if the test continues executing, it will still be reported as failed.
 
 
Available operations
  
Non-resource assertions
 
It is possible to evaluate assertions that do not depend on resources.
 
See Non-resource assertions for details.
 
Operation checks
 
Some operations support checking the operation execution result against specific expectations.
 
See Operation checks for use case details and supported operations.
 
Resource templating
 
Chainsaw can apply transformations to the resources before they are processed by the operation.
 
See Resource templating for use case details and supported operations.
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+ Operations - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Operations
 
While tests are made of test steps, test steps can be considered made of operations.
 
Every operation in a test step runs sequentially.
 
 
Only one action per operation
 
Every operation consists of a single action. While it is syntactically possible to create an operation with multiple actions, Chainsaw will verify and reject tests if operations containing multiple actions are found.
 
The reasoning behind this intentional choice is that it becomes harder to understand in which order actions will be executed in case an operation consists of multiple actions. For this reason, operations consisting of multiple actions are disallowed.
 
 
Common fields
 
All operations share some configuration fields.
 
 
Reference documentation
 
The full structure of the Operation is documented here.
 
 
ContinueOnError
 
Determines whether a test step should continue or not in case the operation is not successful.
 
 
Even if the test continues executing, it will still be reported as failed.
 
 
Available operations
  
Non-resource assertions
 
It is possible to evaluate assertions that do not depend on resources.
 
See Non-resource assertions for details.
 
Operation checks
 
Some operations support checking the operation execution result against specific expectations.
 
See Operation checks for use case details and supported operations.
 
Resource templating
 
Chainsaw can apply transformations to the resources before they are processed by the operation.
 
See Resource templating for use case details and supported operations.
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/operations/non-resource-assert/index.html b/main/operations/non-resource-assert/index.html
index 211aecc35..471f7e86e 100644
--- a/main/operations/non-resource-assert/index.html
+++ b/main/operations/non-resource-assert/index.html
@@ -1,4 +1,4 @@
- Non-resource assertions - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Non-resource assertions
 
Under certain circumstances, it makes sense to evaluate assertions that do not depend on resources. For example, when asserting the number of nodes in a cluster is equal to a known value.
 
Usage examples
 
Below is an example of using assert in a Test resource.
 
 
Using a file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Non-resource assertions - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Non-resource assertions
 
Under certain circumstances, it makes sense to evaluate assertions that do not depend on resources. For example, when asserting the number of nodes in a cluster is equal to a known value.
 
Usage examples
 
Below is an example of using assert in a Test resource.
 
 
Using a file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: non-resource-assertion
diff --git a/main/operations/patch/index.html b/main/operations/patch/index.html
index 91ea70aee..dc155f0e4 100644
--- a/main/operations/patch/index.html
+++ b/main/operations/patch/index.html
@@ -1,4 +1,4 @@
- Patch - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Patch
 
The patch operation lets you define resources that should be modified in the Kubernetes cluster during the test step. These can be configurations, deployments, services, or any other Kubernetes resource.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Patch is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
 
Warning
 
If the resource to be modified does not exist in the cluster, the step will fail.
 
 
Usage examples
 
Below is an example of using patch in a Test resource.
 
 
Using a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Patch - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Patch
 
The patch operation lets you define resources that should be modified in the Kubernetes cluster during the test step. These can be configurations, deployments, services, or any other Kubernetes resource.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Patch is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
 
Warning
 
If the resource to be modified does not exist in the cluster, the step will fail.
 
 
Usage examples
 
Below is an example of using patch in a Test resource.
 
 
Using a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/script/index.html b/main/operations/script/index.html
index 16aacce84..7dc075257 100644
--- a/main/operations/script/index.html
+++ b/main/operations/script/index.html
@@ -1,4 +1,4 @@
- Script - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Script
 
The script operation provides a means to run a script during the test step.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Script is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
Usage examples
 
Below is an example of using script in a Test resource.
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Script - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Script
 
The script operation provides a means to run a script during the test step.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Script is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
Usage examples
 
Below is an example of using script in a Test resource.
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/sleep/index.html b/main/operations/sleep/index.html
index 2a202c59a..cd69979bc 100644
--- a/main/operations/sleep/index.html
+++ b/main/operations/sleep/index.html
@@ -1,4 +1,4 @@
- Sleep - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Sleep
 
The sleep operation provides a means to sleep for a configured duration.
 
Configuration
 
 
Reference documentation
 
The full structure of the Sleep is documented here.
 
 
Usage examples
 
Below is an example of using sleep in a Test resource.
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Sleep - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Sleep
 
The sleep operation provides a means to sleep for a configured duration.
 
Configuration
 
 
Reference documentation
 
The full structure of the Sleep is documented here.
 
 
Usage examples
 
Below is an example of using sleep in a Test resource.
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/templating/index.html b/main/operations/templating/index.html
index b5b78a916..5184d9981 100644
--- a/main/operations/templating/index.html
+++ b/main/operations/templating/index.html
@@ -1,4 +1,4 @@
- Resource templating - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Resource templating
 
 
Experimental status
 
This is an experimental feature, and implementation could change slightly in the next versions.
 
 
 
Info
 
Templating was disabled by default in v0.1.* but is now enabled by default since v0.2.1.
 
 
Chainsaw can apply transformations to the resources before they are processed by the operation.
 
This is useful when a resource needs some runtime configuration.
 
Templating must be enabled at the configuration, test, step, or operation level for the templating process to kick in. Alternatively, templating can be enabled using the --template flag when invoking chainsaw from the command line.
 
 
Note
 
Unlike assertion trees, templating can only be specified in leave nodes of the YAML tree.
 
 
Supported operations
 
Resource templating is supported in the following operations:
  
Assert and Error
 
When templating assert or error operations, the content is already an assertion tree.
 
For this reason, only the elements used for looking up the resources to be processed by the operation will be considered for templating. That is, only apiVersion, kind, name, namespace and labels are considered for templating. Other fields are not, they are part of the assertion tree only.
 
 
assert and error example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Resource templating - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Resource templating
 
 
Experimental status
 
This is an experimental feature, and implementation could change slightly in the next versions.
 
 
 
Info
 
Templating was disabled by default in v0.1.* but is now enabled by default since v0.2.1.
 
 
Chainsaw can apply transformations to the resources before they are processed by the operation.
 
This is useful when a resource needs some runtime configuration.
 
Templating must be enabled at the configuration, test, step, or operation level for the templating process to kick in. Alternatively, templating can be enabled using the --template flag when invoking chainsaw from the command line.
 
 
Note
 
Unlike assertion trees, templating can only be specified in leave nodes of the YAML tree.
 
 
Supported operations
 
Resource templating is supported in the following operations:
  
Assert and Error
 
When templating assert or error operations, the content is already an assertion tree.
 
For this reason, only the elements used for looking up the resources to be processed by the operation will be considered for templating. That is, only apiVersion, kind, name, namespace and labels are considered for templating. Other fields are not, they are part of the assertion tree only.
 
 
assert and error example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: template
diff --git a/main/operations/update/index.html b/main/operations/update/index.html
index c913ef4fb..babbde87e 100644
--- a/main/operations/update/index.html
+++ b/main/operations/update/index.html
@@ -1,4 +1,4 @@
- Update - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Update
 
The update operation lets you define resources that should be updated in the Kubernetes cluster during the test step. These can be configurations, deployments, services, or any other Kubernetes resource.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Update is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
 
Warning
 
If the resource to be updated doesn't exist in the cluster, the step will fail.
 
 
Usage examples
 
Below is an example of using update in a Test resource.
 
 
Using a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Update - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Update
 
The update operation lets you define resources that should be updated in the Kubernetes cluster during the test step. These can be configurations, deployments, services, or any other Kubernetes resource.
 
Configuration
 
 
Reference documentation
 
     
  • The full structure of the Update is documented here.
    •  
  • This operation supports bindings.
    •  
  • This operation supports outputs.
    •  
 
 
 
Warning
 
If the resource to be updated doesn't exist in the cluster, the step will fail.
 
 
Usage examples
 
Below is an example of using update in a Test resource.
 
 
Using a specific file
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/operations/wait/index.html b/main/operations/wait/index.html
index 3563eb142..dbeb20027 100644
--- a/main/operations/wait/index.html
+++ b/main/operations/wait/index.html
@@ -1,4 +1,4 @@
- Wait - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Wait
 
The wait operation is a wrapper around kubectl wait. It allows to wait for deletion or conditions against resources.
 
Configuration
 
 
Reference documentation
 
The full structure of the Wait is documented here.
 
 
 
Deprecated syntax
 
You can specify the resource directly instead of using apiVersion and kind.
 
This is a deprecated syntax though and will be removed in a future version.
 
 
Clustered resources
 
When used with a clustered resource, the namespace is ignored and is not added to the corresponding kubectl command.
 
All resources
 
If you don't specify a name or a selector, the wait operation will consider all resources.
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Below is an example of using wait in a Test resource.
 
 
Wait pod ready
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Wait - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Wait
 
The wait operation is a wrapper around kubectl wait. It allows to wait for deletion or conditions against resources.
 
Configuration
 
 
Reference documentation
 
The full structure of the Wait is documented here.
 
 
 
Deprecated syntax
 
You can specify the resource directly instead of using apiVersion and kind.
 
This is a deprecated syntax though and will be removed in a future version.
 
 
Clustered resources
 
When used with a clustered resource, the namespace is ignored and is not added to the corresponding kubectl command.
 
All resources
 
If you don't specify a name or a selector, the wait operation will consider all resources.
 
All namespaces
 
When used with a namespaced resource, it is possible to consider all namespaces in the cluster by setting namespace: '*'.
 
Usage examples
 
Below is an example of using wait in a Test resource.
 
 
Wait pod ready
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/quick-start/index.html b/main/quick-start/index.html
index a228bb4bd..fc1d81115 100644
--- a/main/quick-start/index.html
+++ b/main/quick-start/index.html
@@ -1,4 +1,4 @@
- Quick start - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Quick start
 
To use Chainsaw you will need a Kubernetes cluster, Chainsaw won't create one for you.
 
In this Quick start we will use kind but feel free to use the tool of your choice.
 
 
Not a cluster management tool
 
We consider this is not the responsibility of Chainsaw to manage clusters.
 
There are plenty of solutions to create and manage local clusters that will do that better than Chainsaw.
 
 
Create a kind cluster
 
Please refer to the kind install docs to install it locally.
 
Once kind creating a local cluster is as simple as running:
 
# define kind image
+ Quick start - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Quick start
 
To use Chainsaw you will need a Kubernetes cluster, Chainsaw won't create one for you.
 
In this Quick start we will use kind but feel free to use the tool of your choice.
 
 
Not a cluster management tool
 
We consider this is not the responsibility of Chainsaw to manage clusters.
 
There are plenty of solutions to create and manage local clusters that will do that better than Chainsaw.
 
 
Create a kind cluster
 
Please refer to the kind install docs to install it locally.
 
Once kind creating a local cluster is as simple as running:
 
# define kind image
 export KIND_IMAGE="kindest/node:v1.28.0"
 
 # create cluster
diff --git a/main/resources/index.html b/main/resources/index.html
index 2e8dec732..ebb06773b 100644
--- a/main/resources/index.html
+++ b/main/resources/index.html
@@ -1 +1 @@
- Resources - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
  
  
  
  
 
 
 
     
\ No newline at end of file
+ Resources - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
  
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/steps/catch/index.html b/main/steps/catch/index.html
index 4f5707928..3abeb12d0 100644
--- a/main/steps/catch/index.html
+++ b/main/steps/catch/index.html
@@ -1,4 +1,4 @@
- Catch - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Catch
 
A catch statement is also a sequence of operations or collectors.
 
Operations and collectors contained in a catch statement will be executed only if the step failed when executing the operations in the step's try statement.
 
 
Tip
 
All operations and collectors of a catch statement will be executed regardless of the success or failure of each of them.
 
 
More general catch blocks
 
Under certain circumstances, it can be useful to configure catch blocks at a higher level than the step grain. At the test or configuration level.
 
This allows for declaring common catch statements we want to execute when an error occurs. Those catch blocks are combined to produce the final catch block in the following order:
 
     
  1. catch statements from the configuration level are executed first (if any)
    2.  
  2. catch statements from the test level are executed next (if any)
    3.  
  3. catch statements from the step level are executed last (if any)
    4.  
 
Operations
 
A catch statement supports only the following operations:
  
Collectors
 
A catch statement supports all collectors:
  
Examples
 
 
step level catch block
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Catch - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Catch
 
A catch statement is also a sequence of operations or collectors.
 
Operations and collectors contained in a catch statement will be executed only if the step failed when executing the operations in the step's try statement.
 
 
Tip
 
All operations and collectors of a catch statement will be executed regardless of the success or failure of each of them.
 
 
More general catch blocks
 
Under certain circumstances, it can be useful to configure catch blocks at a higher level than the step grain. At the test or configuration level.
 
This allows for declaring common catch statements we want to execute when an error occurs. Those catch blocks are combined to produce the final catch block in the following order:
 
     
  1. catch statements from the configuration level are executed first (if any)
    2.  
  2. catch statements from the test level are executed next (if any)
    3.  
  3. catch statements from the step level are executed last (if any)
    4.  
 
Operations
 
A catch statement supports only the following operations:
  
Collectors
 
A catch statement supports all collectors:
  
Examples
 
 
step level catch block
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/steps/finally/index.html b/main/steps/finally/index.html
index 90b25b467..0dd19efcf 100644
--- a/main/steps/finally/index.html
+++ b/main/steps/finally/index.html
@@ -1,4 +1,4 @@
- Finally - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Finally
 
A finally statement is similar to a catch statement but will always execute after the try and eventual catch statements finished executing regardless of the success or failure of the test step.
 
 
Tip
 
All operations and collectors of a finally statement will be executed regardless of the success or failure of each of them.
 
 
Operations
 
A finally statement supports only the following operations:
  
Collectors
 
A finally statement supports all collectors:
  
Example
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Finally - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Finally
 
A finally statement is similar to a catch statement but will always execute after the try and eventual catch statements finished executing regardless of the success or failure of the test step.
 
 
Tip
 
All operations and collectors of a finally statement will be executed regardless of the success or failure of each of them.
 
 
Operations
 
A finally statement supports only the following operations:
  
Collectors
 
A finally statement supports all collectors:
  
Example
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/steps/index.html b/main/steps/index.html
index f7d4f77e7..6a528e844 100644
--- a/main/steps/index.html
+++ b/main/steps/index.html
@@ -1,4 +1,4 @@
- What is a test step - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
What is a test step
 
A test step is made of three main components used to determine the actions Chainsaw will perform when executing the step.
 
     
  1. The try statement (required)
    2.  
  2. The catch statement (optional)
    3.  
  3. The finally statement (optional)
    4.  
 
 
Reference documentation
 
The full structure of the TestStep is documented here.
 
 
Test step lifecycle
 
 
Test step lifecycle
 
     
  1. The step starts executing operations in the try statement
    2.  
  2. If an operation fails in the try statement
       
    1. If a catch statement is present, all operations and collectors are executed
      2.  
     
    3.  
  3. If a finally statement is present, all operations and collectors are executed
    4.  
 
 
Example
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ What is a test step - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
What is a test step
 
A test step is made of three main components used to determine the actions Chainsaw will perform when executing the step.
 
     
  1. The try statement (required)
    2.  
  2. The catch statement (optional)
    3.  
  3. The finally statement (optional)
    4.  
 
 
Reference documentation
 
The full structure of the TestStep is documented here.
 
 
Test step lifecycle
 
 
Test step lifecycle
 
     
  1. The step starts executing operations in the try statement
    2.  
  2. If an operation fails in the try statement
       
    1. If a catch statement is present, all operations and collectors are executed
      2.  
     
    3.  
  3. If a finally statement is present, all operations and collectors are executed
    4.  
 
 
Example
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/steps/try/index.html b/main/steps/try/index.html
index 9a204c8d6..153b6c9da 100644
--- a/main/steps/try/index.html
+++ b/main/steps/try/index.html
@@ -1,4 +1,4 @@
- Try - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Try
 
A try statement is a sequence of operations executed in the same order they are declared. If an operation fails the entire step is considered failed.
 
The try statement is at the heart of a test step, it represents what the step is supposed to be about.
 
catch and finally statements should be viewed as complementary to the try statement.
 
 
Continue on error
 
By default, a test step stops executing when an operation fails and the following operations are not executed.
 
This behavior can be changed using the continueOnError field, if continueOnError is set to true the step will still be considered failed but execution will continue with the next operations.
 
 
Operations
 
A try statement supports all operations:
  
Example
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Try - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Try
 
A try statement is a sequence of operations executed in the same order they are declared. If an operation fails the entire step is considered failed.
 
The try statement is at the heart of a test step, it represents what the step is supposed to be about.
 
catch and finally statements should be viewed as complementary to the try statement.
 
 
Continue on error
 
By default, a test step stops executing when an operation fails and the following operations are not executed.
 
This behavior can be changed using the continueOnError field, if continueOnError is set to true the step will still be considered failed but execution will continue with the next operations.
 
 
Operations
 
A try statement supports all operations:
  
Example
 
 
Example
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: example
diff --git a/main/tests/index.html b/main/tests/index.html
index f8ea24e62..84a59f4bd 100644
--- a/main/tests/index.html
+++ b/main/tests/index.html
@@ -1 +1 @@
- What is a test - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
What is a test
 
To put it simply, a test can be represented as an ordered sequence of test steps.
 
Test steps within a test are run sequentially: if any of the test steps fail, the entire test is considered failed.
 
A test step can consist in one or more operations:
 
     
  • To delete resources present in a cluster
    •  
  • To create or update resources in a cluster
    •  
  • To assert one or more resources in a cluster meet the expectations (or the opposite)
    •  
  • To run arbitrary commands or scripts
    •  
 
Different syntaxes
 
Chainsaw supports two different test definition syntaxes. Each syntax has pros and cons, see the descriptions below for more details on advantages and pitfalls.
 
Manifests based syntax
 
This is the simplest and less verbose syntax.
 
You provide bare Kubernetes resource manifests and Chainsaw will use those manifests to create, update, or assert expectations against a cluster.
 
While this syntax is extremly simple, not all operations are supported. For example, delete, command, script and sleep operations are not.
 
Another strong limitation is that it is not possible to specify additional configuration per test, step or operation.
 
Finally, this syntax relies heavily on file naming conventions, it can be error prone and makes it hard to reuse files across multiple tests.
 
Test based syntax
 
The Test based syntax is a more verbose and explicit syntax.
 
It does not rely on file naming conventions to determine test steps order and allows to easily reuse files accross multiple tests.
 
This syntax also comes with no limitations to provide additional configuration at the test, step or operation level.
 
 
Making a choice
 
Choosing one syntax over the other is not a trivial choice, every one will have its own preference and/or constraints.
 
It's usually easier to start with the manifests based syntax. However, as test suites grow and tests become more complex, it is often necessary to configure options on a per test, step or operation basis and the Test based syntax becomes necessary.
 
 
Namespaced resources
 
Kubernetes organizes resources into two primary scopes: namespaced and cluster-scoped.
 
While namespaced resources belong to a specific namespace, cluster-scoped resources span across the entire Kubernetes cluster.
 
Purpose of the Namespacer Interface
 
The Namespacer interface ensures automated and consistent namespace assignment to Kubernetes resources.
 
     
  •  
    Automated Namespacing
     
    Automatically assign namespaces to resources that don't have one.
     
    •  
  •  
    Ephemeral Namespaces
     
    Handles temporary namespaces for specific tasks.
     
    •  
 
Cleanup
 
Unless configured differently, by default Chainsaw will automatically cleanup the resources it created after a test finishes. Cleanup happens in reverse order of creation (created last, cleaned up first).
 
Note that Chainsaw performs a blocking deletion, that is, it will wait the resource is actually not present anymore in the cluster before proceeding with the next resource cleanup.
 
This is important, especially when the controller being tested makes use of finalizers.
 
 
Overriding cleanup timeout
 
A global cleanup timeout can be defined at the configuration level or using command line flags.
 
It can also be overriden on a per test or per test step basis but not at the operation level.
 
 
Parallel Execution of Tests
 
While Chainsaw ensures that the steps within a test are executed sequentially, it is designed to run multiple tests in parallel to each other. This parallel execution helps in significantly reducing the overall time required to run an entire suite of tests, making the testing process more efficient, especially in scenarios with a large number of tests.
 
 
Parallel execution of tests
 
By default, Chainsaw will run tests in parallel.
 
This can be configured at the configuration level or using command line flags. However, individual tests can be configured to run concurrently by setting Concurrent: true in their TestSpec.
 
All non-concurrent tests are executed first, followed by the concurrent tests in parallel.
 
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+ What is a test - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
What is a test
 
To put it simply, a test can be represented as an ordered sequence of test steps.
 
Test steps within a test are run sequentially: if any of the test steps fail, the entire test is considered failed.
 
A test step can consist in one or more operations:
 
     
  • To delete resources present in a cluster
    •  
  • To create or update resources in a cluster
    •  
  • To assert one or more resources in a cluster meet the expectations (or the opposite)
    •  
  • To run arbitrary commands or scripts
    •  
 
Different syntaxes
 
Chainsaw supports two different test definition syntaxes. Each syntax has pros and cons, see the descriptions below for more details on advantages and pitfalls.
 
Manifests based syntax
 
This is the simplest and less verbose syntax.
 
You provide bare Kubernetes resource manifests and Chainsaw will use those manifests to create, update, or assert expectations against a cluster.
 
While this syntax is extremly simple, not all operations are supported. For example, delete, command, script and sleep operations are not.
 
Another strong limitation is that it is not possible to specify additional configuration per test, step or operation.
 
Finally, this syntax relies heavily on file naming conventions, it can be error prone and makes it hard to reuse files across multiple tests.
 
Test based syntax
 
The Test based syntax is a more verbose and explicit syntax.
 
It does not rely on file naming conventions to determine test steps order and allows to easily reuse files accross multiple tests.
 
This syntax also comes with no limitations to provide additional configuration at the test, step or operation level.
 
 
Making a choice
 
Choosing one syntax over the other is not a trivial choice, every one will have its own preference and/or constraints.
 
It's usually easier to start with the manifests based syntax. However, as test suites grow and tests become more complex, it is often necessary to configure options on a per test, step or operation basis and the Test based syntax becomes necessary.
 
 
Namespaced resources
 
Kubernetes organizes resources into two primary scopes: namespaced and cluster-scoped.
 
While namespaced resources belong to a specific namespace, cluster-scoped resources span across the entire Kubernetes cluster.
 
Purpose of the Namespacer Interface
 
The Namespacer interface ensures automated and consistent namespace assignment to Kubernetes resources.
 
     
  •  
    Automated Namespacing
     
    Automatically assign namespaces to resources that don't have one.
     
    •  
  •  
    Ephemeral Namespaces
     
    Handles temporary namespaces for specific tasks.
     
    •  
 
Cleanup
 
Unless configured differently, by default Chainsaw will automatically cleanup the resources it created after a test finishes. Cleanup happens in reverse order of creation (created last, cleaned up first).
 
Note that Chainsaw performs a blocking deletion, that is, it will wait the resource is actually not present anymore in the cluster before proceeding with the next resource cleanup.
 
This is important, especially when the controller being tested makes use of finalizers.
 
 
Overriding cleanup timeout
 
A global cleanup timeout can be defined at the configuration level or using command line flags.
 
It can also be overriden on a per test or per test step basis but not at the operation level.
 
 
Parallel Execution of Tests
 
While Chainsaw ensures that the steps within a test are executed sequentially, it is designed to run multiple tests in parallel to each other. This parallel execution helps in significantly reducing the overall time required to run an entire suite of tests, making the testing process more efficient, especially in scenarios with a large number of tests.
 
 
Parallel execution of tests
 
By default, Chainsaw will run tests in parallel.
 
This can be configured at the configuration level or using command line flags. However, individual tests can be configured to run concurrently by setting Concurrent: true in their TestSpec.
 
All non-concurrent tests are executed first, followed by the concurrent tests in parallel.
 
 
 
  
  
  
 
 
 
     
\ No newline at end of file
diff --git a/main/tests/manifests-based/index.html b/main/tests/manifests-based/index.html
index 9ac12e91c..832377881 100644
--- a/main/tests/manifests-based/index.html
+++ b/main/tests/manifests-based/index.html
@@ -1,4 +1,4 @@
- Manifests based syntax - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Manifests based syntax
 
This is the simplest and less verbose supported syntax.
 
You provide bare Kubernetes resource manifests and Chainsaw will use those manifests to create, update, or assert expectations against a cluster.
 
While this syntax is simple, it doesn't support deletion operations and doesn't allow specifying additional configuration per test or step.
 
It also relies a lot on file naming conventions and makes it hard to reuse files across multiple tests.
 
File naming convention
 
Manifest files must follow the naming convention <step index>-<name|assert|errors>.yaml.
 
As an example 00-configmap.yaml, 01-assert.yaml and 02-errors.yaml can all be considered valid file names.
 
It's also perfectly valid to have multiple files for the same step. Let's imagine we have the following files 00-resources.yaml, 00-more-resources.yaml, 00-assert.yaml and 00-errors.yaml:
 
     
  • 00-resources.yaml and 00-more-resources.yaml contain resources that will be applied in step 00
    •  
  • 00-assert.yaml contains assert statements in step 00
    •  
  • 00-errors.yaml contains error statements in step 00
    •  
 
With the four files above, Chainsaw will assemble a test step made of the combination of all those files.
 
Manifests loading process
 
The logic to determine the content of a step is always:
 
     
  • The step index is obtained from the beginning of the file name, it must be composed of two numbers between 0 and 9 (from 00 to 99)
    •  
  • The next character acts as a separator and is expected to be -
    •  
  • The rest of the file name (without extension) is then evaluated
       
    • If it is equal to assert, the content is considered assertion statements
      •  
    • If it is equal to error, the content is considered error statements
      •  
    • Else the content is considered resources to be applied
      •  
     
    •  
  • The extension must be .yaml or .yml
    •  
 
Example
 
01-configmap.yaml
 
The manifest below contains a config map in a file called 01-configmap.yaml. Chainsaw will associate this manifest with an apply operation in step 01.
 
apiVersion: v1
+ Manifests based syntax - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Manifests based syntax
 
This is the simplest and less verbose supported syntax.
 
You provide bare Kubernetes resource manifests and Chainsaw will use those manifests to create, update, or assert expectations against a cluster.
 
While this syntax is simple, it doesn't support deletion operations and doesn't allow specifying additional configuration per test or step.
 
It also relies a lot on file naming conventions and makes it hard to reuse files across multiple tests.
 
File naming convention
 
Manifest files must follow the naming convention <step index>-<name|assert|errors>.yaml.
 
As an example 00-configmap.yaml, 01-assert.yaml and 02-errors.yaml can all be considered valid file names.
 
It's also perfectly valid to have multiple files for the same step. Let's imagine we have the following files 00-resources.yaml, 00-more-resources.yaml, 00-assert.yaml and 00-errors.yaml:
 
     
  • 00-resources.yaml and 00-more-resources.yaml contain resources that will be applied in step 00
    •  
  • 00-assert.yaml contains assert statements in step 00
    •  
  • 00-errors.yaml contains error statements in step 00
    •  
 
With the four files above, Chainsaw will assemble a test step made of the combination of all those files.
 
Manifests loading process
 
The logic to determine the content of a step is always:
 
     
  • The step index is obtained from the beginning of the file name, it must be composed of two numbers between 0 and 9 (from 00 to 99)
    •  
  • The next character acts as a separator and is expected to be -
    •  
  • The rest of the file name (without extension) is then evaluated
       
    • If it is equal to assert, the content is considered assertion statements
      •  
    • If it is equal to error, the content is considered error statements
      •  
    • Else the content is considered resources to be applied
      •  
     
    •  
  • The extension must be .yaml or .yml
    •  
 
Example
 
01-configmap.yaml
 
The manifest below contains a config map in a file called 01-configmap.yaml. Chainsaw will associate this manifest with an apply operation in step 01.
 
apiVersion: v1
 kind: ConfigMap
 metadata:
   name: chainsaw-quick-start
diff --git a/main/tests/test-based/index.html b/main/tests/test-based/index.html
index 2b1c40ef1..7450dbab6 100644
--- a/main/tests/test-based/index.html
+++ b/main/tests/test-based/index.html
@@ -1,4 +1,4 @@
- Test based syntax - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Test based syntax
 
The Test based syntax is more verbose than the manifests based syntax but offers more flexibility and features:
 
     
  • Does not rely on file naming conventions for operations ordering
    •  
  • Allows to easily reuse files accross multiple tests
    •  
  • Offers the flexibility to provide additional configuration at the test, step and operation level
    •  
  • Supports all operations and collectors
    •  
 
The Test resource
 
A Test resource, like any Kubernetes resource has an apiVersion, kind and metadata section.
 
It also comes with a spec section used to declaratively represent the steps of a test and other configuration elements belonging to the test being defined.
 
 
Reference documentation
 
The full structure of the Test resource is documented here.
 
 
Test steps
 
A Test is mostly made of test steps. Test steps are detailed in a dedicated documentation.
 
Example
 
chainsaw-test
 
The manifest below contains a Test in a file called chainsaw-test.yaml (or chainsaw-test.yml).
 
Chainsaw will load the Test and steps defined in its spec section.
 
The Test uses a custom timeouts for the whole test. Note that timeouts could have been overridden in specific steps if needed.
 
apiVersion: chainsaw.kyverno.io/v1alpha1
+ Test based syntax - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
Test based syntax
 
The Test based syntax is more verbose than the manifests based syntax but offers more flexibility and features:
 
     
  • Does not rely on file naming conventions for operations ordering
    •  
  • Allows to easily reuse files accross multiple tests
    •  
  • Offers the flexibility to provide additional configuration at the test, step and operation level
    •  
  • Supports all operations and collectors
    •  
 
The Test resource
 
A Test resource, like any Kubernetes resource has an apiVersion, kind and metadata section.
 
It also comes with a spec section used to declaratively represent the steps of a test and other configuration elements belonging to the test being defined.
 
 
Reference documentation
 
The full structure of the Test resource is documented here.
 
 
Test steps
 
A Test is mostly made of test steps. Test steps are detailed in a dedicated documentation.
 
Example
 
chainsaw-test
 
The manifest below contains a Test in a file called chainsaw-test.yaml (or chainsaw-test.yml).
 
Chainsaw will load the Test and steps defined in its spec section.
 
The Test uses a custom timeouts for the whole test. Note that timeouts could have been overridden in specific steps if needed.
 
apiVersion: chainsaw.kyverno.io/v1alpha1
 kind: Test
 metadata:
   name: test-name
diff --git a/main/writing-tests/index.html b/main/writing-tests/index.html
index 1ddd2eb86..91ef96c54 100644
--- a/main/writing-tests/index.html
+++ b/main/writing-tests/index.html
@@ -1 +1 @@
- What is Chainsaw - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
What is Chainsaw
 
Overview
 
Chainsaw provides a declarative approach to testing production-grade Kubernetes operators and controllers.
 
It provides a way to inject an operator (subject under test) during the setup and allows tests to be standard YAML files.
 
 
In Chainsaw everything is YAML. We use YAML to manipulate resources, define cluster state assertions, describe commands to run, etc... Everything is declarative.
 
 
Motivation
 
Testing Kubernetes operators is not easy.
 
At Kyverno we are building complex controllers and admission controllers that need to be deeply end to end tested.
 
 
Advantages of a declarative approach
 
It made sense to be able to declaratively create end to end tests for a couple of reasons:
 
     
  • Easily translate a reported issue to an end to end test
    •  
  • Add new end to end tests without writing a single line of code
    •  
 
 
When would you use Chainsaw
 
The testing eco-system is vast and includes at a minimum low level unit tests, integration tests and end-to-end testing.
 
Chainsaw is built to support some kubernetes integration test scenarios and is most valuable as an end to end testing tool.
 
 
Chainsaw is great for
 
     
  • Provide tests against your Custom Resource Definitions (CRDs)
    •  
  • Inject a controller and assert states in a running cluster
    •  
  • Run same tests against multiple implementations and multiple versions of Kubernetes clusters
    •  
 
 
 
  
  
  
 
 
 
     
\ No newline at end of file
+ What is Chainsaw - Chainsaw      
 
  
  
 
  
 
 
 
 
  
 
 
 
 
 
  
 
 
 
 
    
What is Chainsaw
 
Overview
 
Chainsaw provides a declarative approach to testing production-grade Kubernetes operators and controllers.
 
It provides a way to inject an operator (subject under test) during the setup and allows tests to be standard YAML files.
 
 
In Chainsaw everything is YAML. We use YAML to manipulate resources, define cluster state assertions, describe commands to run, etc... Everything is declarative.
 
 
Motivation
 
Testing Kubernetes operators is not easy.
 
At Kyverno we are building complex controllers and admission controllers that need to be deeply end to end tested.
 
 
Advantages of a declarative approach
 
It made sense to be able to declaratively create end to end tests for a couple of reasons:
 
     
  • Easily translate a reported issue to an end to end test
    •  
  • Add new end to end tests without writing a single line of code
    •  
 
 
When would you use Chainsaw
 
The testing eco-system is vast and includes at a minimum low level unit tests, integration tests and end-to-end testing.
 
Chainsaw is built to support some kubernetes integration test scenarios and is most valuable as an end to end testing tool.
 
 
Chainsaw is great for
 
     
  • Provide tests against your Custom Resource Definitions (CRDs)
    •  
  • Inject a controller and assert states in a running cluster
    •  
  • Run same tests against multiple implementations and multiple versions of Kubernetes clusters
    •  
 
 
 
  
  
  
 
 
 
     
\ No newline at end of file