github.com/argoproj/argo-cd/v3@v3.2.1/docs/proposals/argocd-cli-pluin.md (about)

     1  ---
     2  title: Argo CD CLI Plugin
     3  authors:
     4    - "@christianh814"
     5    - "@alexmt"
     6    - "@nitishfy"
     7    
     8  sponsors:
     9    - TBD
    10  reviewers:
    11    - TBD
    12  approvers:
    13    - TBD
    14  
    15  creation-date: 2024-08-21
    16  ---
    17  
    18  # Argo CD CLI Plugin Support
    19  
    20  Support for `kubectl`-like plugins for the `argocd` CLI.
    21  
    22  ## Summary
    23  
    24  Enhance the Argo CD `argocd` 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 `argocd` to be more of a "building block" or "interface" for interacting with Argo CD and plugins can be a means to develop more complex workflows while leaving the baseline argocd use-case small. 
    25  
    26  ## Motivation
    27  
    28  Currently, the `argocd` 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](https://github.com/argoproj-labs/argocd-autopilot) and [Vault Plugin](https://github.com/argoproj-labs/argocd-vault-plugin)).
    29  
    30  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 `argocd` CLI "lean" but also extensible and keep things "out of tree". As mentioned before, other tools that can benefit from this besides the Argo CD OCI cli is a tool like `argocd-autopilot`. Also, there is a potential for other Argo Project tools to have plugins, like a Rollouts plugin or an `argocd-image-updater` plugin for Argo CD.
    31  
    32  The idea initially came up during a discussion about [adding CLI support for the upcoming OCI integration](https://cloud-native.slack.com/archives/C06Q17QJPJR/p1721227926706059?thread_ts=1720731234.357799&cid=C06Q17QJPJR).
    33  
    34  ## Goals
    35  
    36  The goal is to provide a plugin mechanism without changing the current behavior of `argocd`'s subcommands and options. 
    37  
    38  ## Non Goals
    39  
    40  Make any guarantees for any public `argocd` plugins provided by any third party. 
    41  
    42  ## Proposal
    43  
    44  Similarly to how `kubectl` plugins are handled, The `argocd` CLI tool will look in the end user's `$PATH` for any binaries that start with `argocd-` and execute that binary. For example if I had a binary called `argocd-mytool` in my `$PATH`, I could call it by running `argocd mytool`. Support for tab completion should also be taken into account.
    45  
    46  ## Outstanding Questions
    47  
    48  Things to consider:
    49  
    50  * Should it act exactly like `kubectl` and just look in `$PATH` or be more stringent and have users store plugins in `~/.config/argocd/plugins`? Similar to [Tekton plugins](https://tekton.dev/vault/cli-main/tkn-plugins/#location)
    51  * Is there a way to integrate this with [Krew](https://krew.sigs.k8s.io/) for installing plugins?
    52  * Should we let each plugin manage its own configuration settings or make plugins use `~/.config/argocd/config` and provide a new field called `.pluginConfigs`? For example the `argocd-mytool` plugin's config will be under `.pluginConfigs.mytool` Should we even care/have an opinion?
    53  * Should we provide any guidelines to submit a plugin? Do we only "accept" plugins that are in argoproj-labs?
    54