Skip to content

Add completion spec for talosctl (Talos Linux CLI) #293

Description

@maxmilian

Link to @that70schris's main issue: warpdotdev/warp#12693

talosctl (the Talos Linux CLI for out-of-band management of Kubernetes nodes) has no completion spec yet — command-signatures/json/ covers the adjacent kubectl and helm, but not talosctl. Warp's Oz triage on the main issue confirmed this is a native completion feature gap and marked it ready-to-implement.

Since talosctl is Cobra-based like kubectl/oc, the plan mirrors the existing precedent:

  • Static spec walked from talosctl v1.13.6's command tree (106 nodes, 49 top-level commands)
  • A talosctl_builtin_completion generator delegating dynamic completions (config contexts, node services, resource types, --nodes/--endpoints/--context values) to the CLI's hidden Cobra __complete command, same approach as oc_builtin_completion in oc.rs
  • filepaths/folders templates on path-like flags (--talosconfig, --file, --*-path, --*-dir, …)

Implementation is ready; PR to follow. @lucieleblanc could you add ready-to-implement when you get a chance (for the Oz review gate)? 🙏

Activity

  1. warp-for-oss commented on Jul 16, 2026

    @warp-for-oss

    @maxmilian

    Here's what I found while triaging this issue:

    This appears to be a valid completion-spec feature gap: talosctl is not currently covered by Warp command signatures. I’m labeling it as an enhancement; a maintainer can decide whether it is scoped enough for the reserved ready-to-implement gate.

    Maintainer details

    I concluded that add native Warp command-signature coverage for the Talos Linux talosctl CLI..

    Triage summary

    This is an enhancement request to add Warp command-signature support for talosctl. The current command-signatures repo has adjacent Kubernetes CLI coverage for kubectl and helm, plus Rust dynamic completion generators for kubectl and oc, but no talosctl JSON spec or registered dynamic generator.

    Reproducibility

    High. Inspecting the current tree shows no command-signatures/json/talosctl.json, no talosctl generator implementation, and no talosctl entry in command-signatures/src/generators/mod.rs.

    Likely root cause

    The requested behavior is currently unsupported because talosctl is missing from the command-signatures package. The reporter's proposed Cobra __complete-based generator is plausible based on the existing kubectl/oc precedent and Talos' own Cobra completion support, but the exact static command tree and dynamic completion coverage should still be verified during implementation review.

    Duplicate check

    No matching open issues or issues closed in the last 7 days were found in warpdotdev/command-signatures. The currently open issues cover unrelated Git, Vite+, SSH, and Make completion work.

    Follow-up questions

    None for initial triage. The request is sufficiently scoped for an enhancement label; ready-to-implement remains reserved for maintainers and is not applied by automated triage.

    This is my automated analysis and may be incorrect. A maintainer will verify the details.

    Powered by Oz

  2. maxmilian commented on Jul 30, 2026

    @maxmilian
    ContributorAuthor

    @lucieleblanc — small label request when you get a chance.

    Oz triaged this as a valid completion-spec gap and applied enhancement on 07-16, noting that ready-to-implement is reserved for maintainers. The implementation is already up as #294 (CLA signed, checks green), but Oz won't review it until this issue carries that label, so both have been parked for two weeks.

    If the spec is wanted, applying ready-to-implement here is all that's needed — I'll comment /oz-review on #294 to re-trigger. If talosctl isn't a coverage target you want, I'm equally happy for you to close both; I'd just rather not leave the pair sitting in the queue indefinitely.

  3. maxmilian commented on Aug 7, 2026

    @maxmilian
    ContributorAuthor

    @acarl005 — could you take a quick look at whether this tracking issue is scoped for ready-to-implement?

    The source request, warpdotdev/warp#12693, is already labeled ready-to-implement, and the implementation is ready in #294 (CLA signed and mergeable). Oz's only blocker is that it requires the same-repo tracking issue to carry the label before it will review the diff.

    If talosctl is not a coverage target you want for this repository, closing #293 and #294 is also completely fine. A yes/no decision is all I need; no rush on reviewing the implementation itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew capability or improvement request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions