cli

cli copied to clipboard

A plugin is a binary that can communicate with ignite using github.com/hashicorp/go-plugin. When ignite is executed under a chain configuration, it checks if the config contains plugins. If yes the plugins are fetched, compiled and ran, which will add more commands to the existing ones.

Fetching and compilation are cached under .ignite/plugins folder.

A new command ignite plugin has been added to manage plugins and make new ones.

To give plugins the ability to load the chain, the function cmd.NewChainWithHomeFlags is now public.

---

This is a rebase of #1959, with some small additional changes:

• updated go.mod and go.sum for scaffolded plugins
• upgraded hashicorp/go-plugins to 1.4.4
• git init and commit scaffolded plugins

Are we running go mod tidy when we "install" a new plugin?

If so, we don't need to include go.sum

we don't, but I'll add it and remove the go.sum :+1:

Are we running go mod tidy when we "install" a new plugin? If so, we don't need to include go.sum

we don't, but I'll add it and remove the go.sum +1

@aljo242 I removed the go.sum and also all the indirect dependencies (we could probably do that also for chain go.mod.plush), and then run go mod tidy :ok_hand: aabb88ae

Another approach to load the plugins that would allow to get the command execution context could be done in the ignite/cmd/ignite/main.go file with something like:

func main() {
    ctx := clictx.From(context.Background())
    cmd := ignitecmd.New()

    // Load plugins before executing the command
    err := ignitecmd.LoadPlugins(ctx, cmd)
    if err == nil {
        err = cmd.ExecuteContext(ctx)
    }

    // ...
}

But the loadPlugins would have to be public in that case.

Another approach to load the plugins that would allow to get the command execution context could be done in the ignite/cmd/ignite/main.go file with something like:

func main() {
    ctx := clictx.From(context.Background())
    cmd := ignitecmd.New()

    // Load plugins before executing the command
    err := ignitecmd.LoadPlugins(ctx, cmd)
    if err == nil {
        err = cmd.ExecuteContext(ctx)
    }

    // ...
}

But the loadPlugins would have to be public in that case.

Sold! 5f974f55b23b22901810c6d156acd09035cd389e

Thanks for the suggestion, that improves the error handling.

Awesome feature @tbruyelle 🥇

:warning: before the merge, we need to fix this https://github.com/ignite/cli/pull/2877/files#diff-41932ae29776984f039f7f6ab3a4319e410533ba4161c70a263e8e38fd4c424aR55-R57

@fadeev As you requested, I removed the plugin.name field which wasn't really useful. 17ec702073d4d5608f591edb01525e14af085017

And why don't we turn it to a simple array?

plugins:
  - github.com/...
  - ...

And why don't we turn it to a simple array?

plugins:
  - github.com/...
  - ...

Because you can add parameters like github actions :

    path: github.com/org/repo/my-plugin
    // Additional parameters can be passed to the plugin
    with:
      key: value

And why don't we turn it to a simple array?

I agree with Thomas, at the cost of just a few characters per plugin (the path field name), we get the extensibility that we might need for hooks and such.

Great feature @tbruyelle I would like to propose we add the functionality mentioned in this proposal