Skip to content

cub run where-filter

cub run where-filter

Returns true if all terms of the conjunction of relational expressions evaluate to true for at least one matching path of a resource of the specified type. Intended to be used for filtering rather than validating, though it returns the same output type. Validating. Supported toolchains: AppConfig/Env, AppConfig/INI, AppConfig/JSON, AppConfig/Properties, AppConfig/TOML, AppConfig/Text, AppConfig/YAML, ConfigHub/YAML, Kubernetes/YAML

cub run where-filter [flags]

Options

  -h, --help                   help for where-filter
      --resource-type string   (required) Resource type (Schema) to match
      --where-expression AND   (required) The specified string is an expression for the purpose of evaluating whether the configuration data matches the filter. It supports conjunctions using AND of relational expressions of the form *path* *operator* *literal*. The path specifications are dot-separated, for both map fields and array indices, as in `spec.template.spec.containers.0.image = 'ghcr.io/headlamp-k8s/headlamp:latest' AND spec.replicas > 1`. Path expressions support `*` for wildcard array or map segments and `?key=value` syntax for associative matches of array elements containing objects with a `key` attribute. Strings support the following operators: `<`, `>`, `<=`, `>=`, `=`, `!=`, `LIKE`, `NOT LIKE`, `ILIKE`, `~~`, `!~~`, `~`, `!~`, `~*`, `!~*`, `IN`, `NOT IN`. String pattern operators: `LIKE` and `~~` for pattern matching with `%` and `_` wildcards, `ILIKE` for case-insensitive pattern matching, `NOT LIKE` and `!~~` for negated pattern matching. String regex operators: `~` for regex matching, `~*` for case-insensitive regex, `!~` and `!~*` for regex not matching (case-sensitive and insensitive). Integers support the following operators: `<`, `>`, `<=`, `>=`, `=`, `!=`, `IN`, `NOT IN`. Boolean values support equality and inequality only. The `IN` and `NOT IN` operators accept a comma-separated list of values in parentheses, such as `spec.template.spec.containers.0.image#reference IN (':latest', ':arm64-latest')`. The syntax `.|` splits the path: the left side selects, and the right side is a property of what was selected. On the right side of a `.|`, and only there, `!=` is true when the property is absent: `spec.containers.*.|image != 'nginx'` selects the containers and asks that none of their images be nginx, which a container with no image satisfies. Everywhere else a path that is not present is not a match, `!=` included. String literals are quoted with single quotes, such as `'string'`. Integer and boolean literals are also supported for attributes of those types.

Options inherited from parent commands

      --change-desc string      change description
      --changeset string        changeset to associate units with
      --clearance stringArray   class of guarded reason this change is cleared for, as KEY, KEY=VALUE[;VALUE...], KEY!=VALUE[;VALUE...], or !KEY to refuse any path carrying KEY (repeatable). A guarded path this does not cover is not written, and the withheld change is reported as a conflict
      --component string        the Component of --variant, when that names the variant alone; --variant <component>/<variant> says the same in one flag
      --context string          The context to use for this command
      --debug                   Debug output
      --dry-run                 dry run mode: execute functions but skip updating configuration data
      --executor-space string   Space ID or slug whose executor to use for builtin functions (org-level only)
      --filter string           filter to apply (slug, space/filter, or UUID)
      --guard stringArray       reason to record on the paths this change writes, as KEY=VALUE (repeatable). A later operation must be cleared for it before overwriting those paths, this one included, so --clearance has to cover it. Adds and overwrites only; retiring a guard is cub unit set-guard --remove-guard
      --include-conflicts       pass each unit's outstanding merge conflicts to the functions, for functions that reason about them (e.g. vet-no-merge-conflicts)
      --include-link-findings   pass what the resolves of each unit's links could not do to the functions, for functions that reason about it (e.g. vet-no-link-findings)
  -o, --output string           Output format. One of: json, yaml, name, wide, mutations, jq=<expr>, yq=<expr>, custom-columns=<spec>
      --protect                 record the paths this change writes as protected local overrides, so a later merge from upstream does not overwrite them; by default a change claims nothing and each path keeps the protection it already has
      --quiet                   No output
      --show string             Select which part of the function response to display. One of: output, values, data
      --space string            space to operate in, by slug or UUID. Omitted, a list or bulk operation spans the organization and a single entity is named as <space>/<slug>; "*" means the same as omitting it
      --toolchain string        Toolchain type for the function invocations (default "Kubernetes/YAML")
      --unit strings            target specific units by slug or UUID (can be repeated or comma-separated)
      --variant string          variant to operate in, as <component>/<variant>, or as <variant> with --component: the space naming that Component whose Variant label is <variant>. The same scope as --space, named by what it is rather than by the space's slug; the two cannot be combined
      --wait                    wait for completion
      --where string            where filter
      --where-data string       where data filter
      --where-resource string   filter which resources the function operates on
      --worker string           worker to execute the function

SEE ALSO