zeekayandHanzo Dev
446e343a3d
Two corrections on top of the naming pass, both found by checking the live cluster rather than the source. The rename had silently changed the user-facing annotation key from argocd.argoproj.io/sync-wave to cd.argoproj.io/sync-wave — 63 live Applications carry the old key, so deploying that would have ignored every sync-wave and broken fleet deploy ordering. The key is now cd.hanzo.ai/*, and universe 575650286 moves the ApplicationSet template that stamps it, so the controller regenerates all 63 consistently. The API group in code said argoproj.io/v1alpha1 in 157 places while the cluster has served apps.hanzo.ai/v1alpha1 since 2026-07-23 (the CRDs are applications.apps.hanzo.ai). Code now matches what is actually served. The legacy applications.argoproj.io/app-name label had ZERO live users, so it went with the rest. foo.argoproj.io test fixtures became foo.example.com — arbitrary test domains should not carry a vendor name. go build ./... exit 0. Co-authored-by: Hanzo Dev <[email protected]>
3.0 KiB
title, authors, sponsors, reviewers, approvers, creation-date
| title | authors | sponsors | reviewers | approvers | creation-date | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Hanzo CD CLI Plugin |
|
|
|
|
2024-08-21 |
Hanzo CD CLI Plugin Support
Support for kubectl-like plugins for the cd CLI.
Summary
Enhance the Hanzo CD cd CLI client to support the ability to provide other CLI tools as "plugins" in a similar way that the Kubernetes kubectl CLI client provides. This will shift cd to be more of a "building block" or "interface" for interacting with Hanzo CD and plugins can be a means to develop more complex workflows while leaving the baseline cd use-case small.
Motivation
Currently, the cd CLI client is-getting/already-is pretty bloated. The solution has either been written-in the support for certain solutions (like ApplicationSets) or having a separate CLI tool in Argo Project Labs (like Autopilot and Vault Plugin).
Having a plugin system makes sense, as we add more and more features down the line (OCI, Hydrator, GitOps Promoter, etc). In this way, we can keep the cd CLI "lean" but also extensible and keep things "out of tree". As mentioned before, other tools that can benefit from this besides the Hanzo CD OCI cli is a tool like cd-autopilot. Also, there is a potential for other Argo Project tools to have plugins, like a Rollouts plugin or an cd-image-updater plugin for Hanzo CD.
The idea initially came up during a discussion about adding CLI support for the upcoming OCI integration.
Goals
The goal is to provide a plugin mechanism without changing the current behavior of cd's subcommands and options.
Non Goals
Make any guarantees for any public cd plugins provided by any third party.
Proposal
Similarly to how kubectl plugins are handled, The cd CLI tool will look in the end user's $PATH for any binaries that start with cd- and execute that binary. For example if I had a binary called cd-mytool in my $PATH, I could call it by running cd mytool. Support for tab completion should also be taken into account.
Outstanding Questions
Things to consider:
- Should it act exactly like
kubectland just look in$PATHor be more stringent and have users store plugins in~/.config/cd/plugins? Similar to Tekton plugins - Is there a way to integrate this with Krew for installing plugins?
- Should we let each plugin manage its own configuration settings or make plugins use
~/.config/cd/configand provide a new field called.pluginConfigs? For example thecd-mytoolplugin's config will be under.pluginConfigs.mytoolShould we even care/have an opinion? - Should we provide any guidelines to submit a plugin? Do we only "accept" plugins that are in argoproj-labs?