pluto detect-files: Find Deprecated APIs
pluto detect-files scans files for Kubernetes apiVersions that are deprecated or removed in a target version, so an upgrade does not silently break your workloads.
Kubernetes removes API versions on a schedule, and a manifest using a removed apiVersion just stops applying after an upgrade. Pluto (via detect-files) finds those references in your repo so you fix them in a PR, not in an outage.
What it does
pluto detect-files reads YAML manifests (and can render Helm charts) under a directory and flags any apiVersion that is deprecated or removed as of the target Kubernetes version. It reports the resource, the deprecated version, and the replacement. Exit code is non-zero when removed (and optionally deprecated) APIs are found.
Common usage
# scan a directory against the default target versions
pluto detect-files -d ./manifests
# check against a specific Kubernetes version, wide output
pluto detect-files -d ./manifests --target-versions k8s=v1.29.0 -o wide
# fail only on removed APIs (not merely deprecated)
pluto detect-files -d ./manifests --ignore-deprecationsOptions
| Flag | What it does |
|---|---|
| -d, --directory <path> | Directory of manifests to scan |
| --target-versions <k=v> | Target versions, e.g. k8s=v1.29.0, cert-manager=... |
| -o, --output <fmt> | Output: normal, wide, json, yaml, markdown, csv |
| --ignore-deprecations | Do not exit non-zero for merely deprecated APIs |
| --ignore-removals | Do not exit non-zero for removed APIs |
| --only-show-removed | Only list APIs that are already removed |
In CI
Run pluto detect-files with the --target-versions of the cluster you are about to move to, as a required check before an upgrade PR merges. Use -o markdown to paste a readable table into the PR. By default deprecated APIs also fail; add --ignore-deprecations if you only want to block on removed ones.
Common errors in CI
When it finds problems it prints a table of resources with a "DEPRECATED" or "REMOVED" flag and exits non-zero (removals exit 3, deprecations exit 2 by default). "No output to display" with exit 0 means nothing matched the target versions. Un-rendered Helm templates ({{ }} left in) parse as invalid; use pluto detect-helm or render first.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes