-
Notifications
You must be signed in to change notification settings - Fork 95
Support for test run labels/selectors #483
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| package cmd | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not sure about name of file...
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I called it values because the type implements a But sure, this can be |
||
|
|
||
| import ( | ||
| "fmt" | ||
|
|
||
| "k8s.io/apimachinery/pkg/labels" | ||
| ) | ||
|
|
||
| type labelSetValue labels.Set | ||
|
|
||
| func (v *labelSetValue) String() string { | ||
| return labels.Set(*v).String() | ||
| } | ||
|
|
||
| func (v *labelSetValue) Set(s string) error { | ||
| l, err := labels.ConvertSelectorToLabelsMap(s) | ||
| if err != nil { | ||
| return fmt.Errorf("cannot parse label set: %w", err) | ||
| } | ||
| *v = labelSetValue(l) | ||
| return nil | ||
| } | ||
|
|
||
| func (v *labelSetValue) Type() string { | ||
| return "labelSet" | ||
| } | ||
|
|
||
| func (v labelSetValue) AsLabelSet() labels.Set { | ||
| return labels.Set(v) | ||
| } | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm curious why we use this structure... this doesn't feel like a selector... the selector is on the command line of running kuttl. This feels more like a label (that a selector would select on) which makes me wonder why we wouldn't use the standard k8s model which would look more like:
thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This particular arrangement of which side labels vs selectors go was @eddycharly 's idea, so maybe he can chime in on where it came from. Maybe it's following some pattern seen elsewhere?
I guess you can think about this in two ways:
kuttlinvocation) comes with a set of labels attached. These labels represent some characteristics of this test invocation. In my use case, there would would be a single label with just two possible values:openshift=trueoropenshift=false, but you could imagine multiple labels and values for a more elaborate test matrix (such as the cartesian product ofplaform={openshift,vanilla,eks},k8s-version={1.28,1.29,1.30}). Then individual files in the test suite provide an optional label selector, which needs to match the label set in order for the file to be considered for the test run. Obviously the selector can contain a subset of label keys that the test run has. For example a given file might only select one or morek8s-versionvalues and be neutral w.r.t.platform. The notable edge case is a file that (be default) has no selector attached - an empty selector matches all possible label sets, meaning this feature is fully backwards-compatible - a file without aTestFileis included in all test invocations, just like before this change.feature-foo={true,false}. Then, each test run can have a label selector attached, and this selector would need to select the APIs supported. This could quickly create an explosion of labels and combinations. What's worse, files which are agnostic about a given API would have to somehow advertise that fact, in order to be selected by a selector which does mention a given API.So it looks to me that only solution 1 is in fact realistic.