vmware-tanzu / tanzu-plugin-runtime Goto Github PK

Bug description

Created a new helloworld plugin bootstrapped wth

tanzu builder cli add-plugin <plugin-name> command and was able to successfully build and install the plugin locally. However when I tried to run the test plugin it fails

❯ tanzu test plugin helloworldplugin
[x] : invalid PluginDescriptor specified: plugin "helloworldplugin-test": target is not valid
Error: exit status 1
Usage:
tanzu test plugin helloworldplugin [flags]

Expected behavior

Should be able to run the test plugin.

Steps to reproduce the bug / Relevant debug output

Plugin Runtime version (also obtainable from tanzu <pluginName> info)
v0.81.0

Environment where the bug was observed (cloud, OS, etc)

Describe the feature request
To support CEIP , CLI should prompt and store the users CEIP Opt-in choice in the configuration. So APIs are needed to set/get the CEIP OptIn configuration
Describe alternative(s) you've considered

Additional context

Currently api/config/v1alpha1/clientconfig is defined as a k8s API, plugin-runtime is still dependent on these k8s dependency.
We should make changes to clientconfig to move away from k8s API and there by avoid the k8s module dependencies in plugin-runtime.

Describe the feature request
With the recent changes of introducing the target concept in the Tanzu CLI, the uniqueness of the plugin is identified with the name and target of the plugin.

Currently, the target of the plugin is determined based on the context or the discovery mechanism. However, the plugin itself is not advertising the target for which it is built. This makes it challenging to know the plugin's target during build time and to get additional details about the plugins.

Each plugin binary should advertise its target information. This can be done as part of the tanzu <plugin> info contract by adding an additional required field called target in the PluginDescriptor. This will make each plugin develop to provide/configure the target field while compiling the plugin using the builder plugin.

Describe alternative(s) you've considered

Additional context

Describe the feature request

To configure plugin discovery sources in the CLI a configuration section exists on the path: clientOptions.cli.discoverySources.

The problem is that since we allow old CLIs and plugins as well as the new CLI and plugins to use the same config file, we cannot mix old discovery sources (which the new CLI should not read) and the new discovery sources (which old CLIs should not read). If therefore becomes impossible to re-use the same configuration section for the new CLI.

Furthermore, old plugins automatically configure a "default" discovery source whenever they are run, but that entry should not be used with the new CLI.

Finally, we also expect to have to extend the configuration information for a discovery source to accommodate for the air-gapped case which will need ca-certificates and an insecure option.

Therefore, to respect backwards-compatibility, the new CLI will need to stop using the existing discoverySources section and introduce a new one in the config-ng.yaml configuration file.

Describe alternative(s) you've considered

Additional context

Bug description
No supported plugins should be using this file.
So handling said file should be removed from the config code.
In particular CopyLegacyConfigDir() that attempts to copy said file into the main CLI config should be eliminated, before we transition to using the solely the config-ng.yaml.

Expected behavior

Steps to reproduce the bug / Relevant debug output

Plugin Runtime version (also obtainable from tanzu <pluginName> info)

Environment where the bug was observed (cloud, OS, etc)

The CI for Cross-version API Compatibility Tests is not running as part of this PR.

We need to update compatibility_tests.yaml#L7 with ** or completely remove the path section so that those tests run for all PRs

Originally posted by @anujc25 in #58 (comment)

Describe the feature request

Provide clear developer documentation. More TBA

Describe the feature request

As a plugin developer, I would like my plugin command implementation that creates or updates a Context to ensure that the plugins that are discoverable via said context are automatically installed on the CLI when said context becomes an active one.

Describe alternative(s) you've considered

Without an API to ensure the above, the plugin would have to resort to explicitly invoke another CLI command directly (e.g. 'tanzu plugin sync') to achieve the same effect, or implore that the user performs the equivalent

Additional context