You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
// Publisher is the name of the publisher of this plugin
// (e.g., a product group within a company)
Publisherstring
// Vendor is the name of the vendor of this plugin (e.g., a company's name)
Vendorstring
// Recommended version that Tanzu CLI should install by default.
// The value should be a valid semantic version as defined in
// https://semver.org/. E.g., 2.0.1
RecommendedVersionstring
// Hidden tells whether the plugin is marked as hidden or not.
Hiddenbool
// Artifacts contains an artifact list for every available version.
Artifacts distribution.Artifacts
}
A PluginInventoryEntry represents an entire plugin including all its versions.
On the other hand the concept of a "hidden" plugin applies to individual versions of a plugin and not to the entire plugin.
For example, if a team has published plugin1 versions 1.0.0 and 1.1.0 (not hidden) and then has a new version v2.0.0 they want to test, they will publish only v2.0.0 as hidden and not the entire plugin.
This is actually all working because the previously mentioned Hidden field is not really used; instead, we handle "hidden" plugins through appropriate DB queries as seen here:
This works because we normally insert a single version at a time so we don't need to fill the plugin structure with all versions, but only with the newly published version and then the Hidden field happens to only apply to that version.
I suggest we simply remove it.
If we need to actually keep track of which version of a plugin is hidden and which is not after the DB query is completed, then we can add a different Hidden field at the level of a version of a plugin. I suggest we only do this when needed as we re-use existing types for the plugin versions.
For publishing a new plugin version, we can adapt the interface to add an hidden argument to the InsertPlugin() function call.
Note that as we introduce versions for plugin groups, we will face a similar situation.
Expected behavior
The plugin data structure properly reflects the reality of information for plugins.
Steps to reproduce the bug / Relevant debug output
N/A
Output of tanzu version
Today's main: f4963fff1
Environment where the bug was observed (cloud, OS, etc)
N/A
The text was updated successfully, but these errors were encountered:
Bug description
The
PluginInventoryEntry
structure has aHidden
field as can be seen towards the end of:tanzu-cli/pkg/plugininventory/plugin_inventory.go
Lines 52 to 72 in f4963ff
A
PluginInventoryEntry
represents an entire plugin including all its versions.On the other hand the concept of a "hidden" plugin applies to individual versions of a plugin and not to the entire plugin.
For example, if a team has published
plugin1
versions1.0.0
and1.1.0
(not hidden) and then has a new versionv2.0.0
they want to test, they will publish onlyv2.0.0
as hidden and not the entire plugin.This is actually all working because the previously mentioned
Hidden
field is not really used; instead, we handle "hidden" plugins through appropriate DB queries as seen here:tanzu-cli/pkg/plugininventory/sqlite_inventory.go
Lines 193 to 196 in f4963ff
I find that having a
Hidden
field at the plugin level in thePluginInventoryEntry
structure is confusing and can lead to errors in future development.Note that the
Hidden
field is actually used when writing plugin entries as can be seen here:tanzu-cli/pkg/plugininventory/sqlite_inventory.go
Line 501 in f4963ff
This works because we normally insert a single version at a time so we don't need to fill the plugin structure with all versions, but only with the newly published version and then the
Hidden
field happens to only apply to that version.I suggest we simply remove it.
If we need to actually keep track of which version of a plugin is hidden and which is not after the DB query is completed, then we can add a different
Hidden
field at the level of a version of a plugin. I suggest we only do this when needed as we re-use existing types for the plugin versions.For publishing a new plugin version, we can adapt the interface to add an
hidden
argument to theInsertPlugin()
function call.Note that as we introduce versions for plugin groups, we will face a similar situation.
Expected behavior
The plugin data structure properly reflects the reality of information for plugins.
Steps to reproduce the bug / Relevant debug output
N/A
Output of
tanzu version
Today's main:
f4963fff1
Environment where the bug was observed (cloud, OS, etc)
N/A
The text was updated successfully, but these errors were encountered: