kudobuilder / kudobuilder/kuttl

Proposal: Generate expected yaml from a command

Open
#552 1 comment 1 reaction 0 assignees View on GitHub
enhancement help wanted
Dominant language
Go
Stars
824
Forks
103
Avg merge
1d 11h
Merged PRs (30d)
6

Description

Hi everyone, what do you think of making it possible to generate the expected yaml from a command? Currently there are two ways of writing the expected state:
1. Directly in yaml
2. Together with an assertion in a script

My use case is a controller that installs Helm charts, where I would like to make assertions against the `helm status` output. Since that output does not live on a cluster I currently have to write a script like this:
```

apiVersion: kuttl.dev/v1beta1
kind: TestAssert
commands:
- script: |
expectedNamespace=test-chart
expectedRelease=test-chart
expectedStatus=deployed

helmStatus=$(helm status -n $expectedNamespace $expectedRelease)
if [ $? -ne 0 ]; then
echo "Failed to get Helm release status for $expectedRelease in namespace $expectedNamespace"
exit 1
fi

status=$(echo "$helmStatus" | grep STATUS | awk '{print $2}')

if [ "$status" != "$expectedStatus" ]; then
echo "Expected Helm release $expectedRelease in namespace $expectedNamespace to have status '$expectedStatus', but got '$status'"
exit 1
fi
```

It would be much nicer if I could give a command that produces a yaml and an expected yaml, then rely on Kuttls internal machinery to compare the two. E.g. something like:
```
expected:
status: deployed
actual: helm status -o yaml
```

Do you think it would be possible to add something like this? And if so, what would be the best way to implement it?

Contributor guide

Open the contributing guide

Research direction

The issue does not name implementation files, tests, or entry points. Begin by locating Kuttl's expected-state comparison and command assertion handling, then define how command output becomes YAML and how expected versus actual data is compared; done means the Helm status example works through the normal assertion machinery.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
cli, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.