Support for managing UI extensions

[reubenmiller]

Whilst working on the addition of the c8y applications versions subcommand group, its usage for managing UI extensions does not seem to align with user's expectation of "easy to use".

The following proposal is to add a new abstraction to managed ui extensions in the same essence as the c8y microservices command which is just a user friend abstraction over the c8y applications api.

ui extensions Proposal

Create extension version

To create a new extension, or add a new version, use the single command. This command is similar in semantics as the c8y microservices create where it is a smart create/update command, and perform additional steps automatically.

c8y ui extensions create --file myextension.zip

The above will

• Create an application (if it does not already exist)
• Upload the binary
• Set the activeVersionId (if not already set)
• version will be detected from the zip (under cumulocity.json .version) - or detect from the file name if all else fails

Delete version

c8y ui extensions versions delete --extension myextension --version 1.0.x

Or delete all of the versions of the same extension using:

c8y ui extensions delete --id myextension

List extensions

c8y ui extensions list --extension

List versions of a give a specific extension

c8y ui extensions versions list --extension 1.0.0

Install plugin to application

A plugin can be installed to an application using:

c8y ui extension install --application devicemanagement --extension <name>

Or an explicit version can be set using:

c8y ui extension install --application devicemanagement --extension <name> --version "1.0.0"

Uninstall plugin from application

A plugin can be uninstalled from an application using:

c8y ui extension uninstall --application devicemanagement --extension <name>

Upgrade all extensions

Currently an upgrade of all available extensions won't be provided in the first drop

[janhommes]

looks useful and easy to use. Tagging might be a good idea to add:

c8y ui extensions create --file myextension.zip --tag beta

c8y ui extensions tag --extension <<name>> --tag beta

One thing about the naming: In the first iteration the extensions were called packages. However, PM decided to rename it for better understanding. This might lead to confusion. The term packages was used, as an application (aka package, aka extension) could contain multiple plugins and/or be a blueprint. Therefore I am not sure if your --extension <name> would work standalone. Maybe we also need to add a --package=<name> or similar? Naming is hard :(

[reubenmiller]

looks useful and easy to use. Tagging might be a good idea to add:

c8y ui extensions create --file myextension.zip --tag beta

c8y ui extensions tag --extension <<name>> --tag beta

One thing about the naming: In the first iteration the extensions were called packages. However, PM decided to rename it for better understanding. This might lead to confusion. The term packages was used, as an application (aka package, aka extension) could contain multiple plugins and/or be a blueprint. Therefore I am not sure if your --extension <name> would work standalone. Maybe we also need to add a --package=<name> or similar? Naming is hard :(

Yeah all the api will be covered so there will be a dedicated tagging command to allow changing the tags after creating the version (as well defining tags when creating a new version). I'll see if I can post a full list of the proposed cli commands soonish

[reubenmiller]

Though the "--extension" flag still needs to be finalized. Generally I like to align to the names used in the UI as this is general the users first exposure to such concepts. Otherwise if the context is clear in the command then I'd go with "--id" (as this is consistent with the other go-c8y-cli commands)

[reubenmiller]

Resolved by #354. This will be part of the next release v2.40.0