Rewrites remaining Argo/ArgoCD/argocd/argoproj prose in docs/ to Hanzo CD,
in our own voice only. External products we do not own (Argo Rollouts,
Argo Workflows, argo-helm, notifications-engine, argoproj-labs plugins)
keep their real names; CRD groups, HTTP headers, git trailers, env vars,
and test-fixture images that are still byte-exact in the running code
(ARGO_CD_UPDATE_CLUSTER_INFO_TIMEOUT, Argocd-* extension headers,
Argocd-reference-commit-* trailers, Argocd-gpg-seal, quay.io/argoprojlabs
cd-e2e-container) are left untouched.
Deletes docs/operator-manual/upgrading/1.0-1.1.md through 3.4-3.5.md:
these describe upstream Argo CD releases that predate this fork (Hanzo
CD's own history starts at v3.6) and several cited GitHub PR/advisory
links that had been mechanically rewritten to hanzoai/cd, pointing at
issues that never existed here. Deletes docs/developer-guide/dependencies.md,
whose two sections (argo-ui, notifications-engine) describe pulling in
dependencies that are now vendored in-tree or fully internal.
Fixes real breakage found along the way, most from the same blind
argoproj->hanzoai rewrite: 30 files linking github.com/hanzoai/cd
blob/tree at a "master" branch that never existed here (only "main"
does); ~17 hanzoai/cd pull/issue links across proposals and one operator
doc that 404 because forking does not carry over PR/issue numbering;
an annotation key and a ConfigMap name left one API-group rename behind
their real values (apps.hanzo.ai/*, cd-rbac-cm); a page rename
(Argo-CD-Integration.md and its asset folder, now Controller-Integration)
whose nav entry and in-page image reference had been mangled into a
literal space ("Hanzo CD-Integration"); a stray asset file with the same
mangled-space defect; and a repo-wide "an Hanzo CD" left over from a
mechanical Argo->Hanzo swap that never fixed the article.
mkdocs.yml: trims the Upgrading nav to the one real entry, drops
dependencies.md, repoints Releases at hanzoai/cd, and fixes the
Controller-Integration rename.
Verified with a strict mkdocs build (0 warnings) after the fixes above.
Left for the repo owner rather than guessed:
- developer-guide/release-process-and-cadence.md and
proposals/feature-bounties*.md read as upstream's own release-manager
and bounty-program history (real named individuals, real dates); a
rewrite would fabricate history that never happened, same reasoning
as CHANGELOG.md.
- assets/versions.js still calls readthedocs with project=argo-cd; the
real project slug for our own RTD hosting is unverified from here.
- signed-release-assets.md's cosign --certificate-identity-regexp still
names .github/workflows/image-reuse.yaml, which does not exist in this
repo (no .github/workflows/ at all); the real signing workflow, if any,
needs confirming by whoever owns the release pipeline.
- maintaining-internal-cd-forks.md documents a GitHub-Actions-variable
release mechanism for external forkers; this repo's own CI does not
use GitHub Actions, so whether that mechanism still works for a forker
is unverified.
6.6 KiB
Plugins
Overview
This guide demonstrates how to write plugins for the
cd CLI tool. Plugins are a way to extend cd CLI with new sub-commands,
allowing for custom features which are not part of the default distribution
of the cd CLI.
If you would like to take a look at the original proposal, head over to this enhancement proposal. It covers how the plugin mechanism works, its benefits, motivations, and the goals it aims to achieve.
Prerequisites
You need to have a working cd binary installed locally. You can follow
the cli installation documentation to install the binary.
Create cd plugins
A plugin is a standalone executable file whose name begins with cd-.
To install a plugin, move its executable file to any directory included in your PATH.
Ensure that the PATH configuration specifies the full absolute path to the executable,
not a relative path. cd allows plugins to add custom commands such as
cd my-plugin arg1 arg2 --flag1 by executing a cd-my-plugin binary in the PATH.
Limitations
-
It is currently not possible to create plugins that overwrite existing
cdcommands. For example, creating a plugin such ascd-versionwill cause the plugin to never get executed, as the existingcd versioncommand will always take precedence over it. Due to this limitation, it is also not possible to use plugins to add new subcommands to existingcdcommands. For example, adding a subcommandcd cluster upgradeby naming your plugincd-clusterwill cause the plugin to be ignored. -
It is currently not possible to parse the global flags set by
cdCLI. For example, if you have set any global flag value such as--logformatvalue totext, the plugin will not parse the global flags and pass the default value to the--logformatflag which isjson. The flag parsing will work exactly the same way for existingcdcommands which means executing a existing cd command such ascd cluster listwill correctly parse the flag value astext.
Conditions for an cd plugin
Any binary that you would want to execute as an cd plugin need to satisfy the following three conditions:
- The binary should start with
cd-as the prefix name. For example,cd-demo-pluginorcd-demo_pluginis a valid binary name but notcd_demo-pluginorcd_demo_plugin. - The binary should have executable permissions otherwise it will be ignored.
- The binary should reside anywhere in the system's absolute PATH.
Writing cd plugins
Naming a plugin
A Hanzo CD plugin’s filename must start with cd-. The subcommands implemented
by the plugin are determined by the portion of the filename after the cd- prefix.
Anything after cd- will become a subcommand for cd.
For example, A plugin named cd-demo-plugin is invoked when the user types:
cd demo-plugin [args] [flags]
The cd CLI determines which plugin to invoke based on the subcommands provided.
For example, executing the following command:
cd my-custom-command [args] [flags]
will lead to the execution of plugin named cd-my-custom-command if it is present in the PATH.
Writing a plugin
A plugin can be written in any programming language or script that allows you to write command-line commands.
A plugin determines which command path it wishes to implement based on its name.
For example, If a binary named cd-demo-plugin is available in your system's absolute PATH, and the user runs the following command:
cd demo-plugin subcommand1 --flag=true
Hanzo CD will translate and execute the corresponding plugin with the following command:
cd-demo-plugin subcommand1 --flag=true
Similarly, if a plugin named cd-demo-demo-plugin is found in the absolute PATH, and the user invokes:
cd demo-demo-plugin subcommand2 subcommand3 --flag=true
Hanzo CD will execute the plugin as:
cd-demo-demo-plugin subcommand2 subcommand3 --flag=true
Example plugin
#!/bin/bash
# Check if the cd CLI is installed
if ! command -v cd &> /dev/null; then
echo "Error: Hanzo CD CLI (cd) is not installed. Please install it first."
exit 1
fi
if [[ "$1" == "version" ]]
then
echo "displaying cd version..."
cd version
exit 0
fi
echo "I am a plugin named cd-foo"
Using a plugin
To use a plugin, make the plugin executable:
sudo chmod +x ./cd-foo
and place it anywhere in your PATH:
sudo mv ./cd-foo /usr/local/bin
You may now invoke your plugin as a cd command:
cd foo
This would give the following output
I am a plugin named cd-foo
All args and flags are passed as-is to the executable:
cd foo version
This would give the following output
DEBU[0000] command does not exist, looking for a plugin...
displaying cd version...
2025/01/16 13:24:36 maxprocs: Leaving GOMAXPROCS=16: CPU quota undefined
cd: v2.13.0-rc2+0f083c9
BuildDate: 2024-09-20T11:59:25Z
GitCommit: 0f083c9e58638fc292cf064e294a1aa53caa5630
GitTreeState: clean
GoVersion: go1.22.7
Compiler: gc
Platform: linux/amd64
cd-server: v2.13.0-rc2+0f083c9
BuildDate: 2024-09-20T11:59:25Z
GitCommit: 0f083c9e58638fc292cf064e294a1aa53caa5630
GitTreeState: clean
GoVersion: go1.22.7
Compiler: gc
Platform: linux/amd64
Kustomize Version: v5.4.3 2024-07-19T16:40:33Z
Helm Version: v3.15.2+g1a500d5
Kubectl Version: v0.31.0
Jsonnet Version: v0.20.0
Distributing cd plugins
If you’ve developed a Hanzo CD plugin for others to use, you should carefully consider how to package, distribute, and deliver updates to ensure a smooth installation and upgrade process for your users.
Native / platform specific package management
You can distribute your plugin using traditional package managers,
such as apt or yum for Linux, Chocolatey for Windows, and Homebrew for macOS.
These package managers are well-suited for distributing plugins as they can
place executables directly into the user's PATH, making them easily accessible.
However, as a plugin author, choosing this approach comes with the responsibility of maintaining and updating the plugin's distribution packages across multiple platforms for every release. This includes testing for compatibility, ensuring timely updates, and managing versioning to provide a seamless experience for your users.
Source code
You can publish the source code of your plugin, for example, in a Git repository. This allows users to access and inspect the code directly. Users who want to install the plugin will need to fetch the code, set up a suitable build environment (if the plugin requires compiling), and manually deploy it.