CLI Extensions #98
CLI Extensions #98
Conversation
| And that can do anything programmatically and also get the benefit of having access to the Temporal client. So it could | ||
| access some company resource (e.g. a database) and send an update to a workflow with some value. | ||
|
|
||
| ### Contributions |
There was a problem hiding this comment.
Will all contributions/extensions be in their own repos and have an extension discovery platform, or will we have some extensions live in the CLI repo (either temporal authored or external that meet a certain bar/requirement)?
There was a problem hiding this comment.
All extensions will be external, even Temporal authored ones (unless we decide to make them built-in commands). We have things like https://temporal.io/code-exchange to help build a marketplace of these as needed. I need to change the title of this section to "Extension Ecosystem" since they are not contributions in the traditional sense.
| `temporal-foo-bar_baz` executable is called for both `temporal foo bar-baz qux` and `temporal foo bar_baz qux` though | ||
| help text only shows the former. | ||
|
|
||
| Built-in commands cannot be overridden by extensions, but subcommands can be added to existing commands. |
There was a problem hiding this comment.
I'm maybe sliiiightly concerned about the possibility of this being an attack vector, where someone could sit on
temporal workflow strt or something, and hijack a mistype of workflow start and because it can load up profile info it might be able to do something bad to your instance.
This applies to any command, too (and I wouldn't want to sacrifice profile loading), but the chance is higher with a typo like this.
Maybe this means we should plan to (at some point) build in something like this is a new extension from XXX signed by ZZZ do you want to enable running this extension? y/n
| `temporal workflow --address foo start`, and `temporal workflow start --address foo` are all the same. It is still a | ||
| subject of active research on whether flags of _parent_ commands can still be placed before the extension command in the | ||
| CLI. Regardless, flags of the extension command _must_ come after the extension command because CLI does not know |
There was a problem hiding this comment.
I would want the answer to whether parent flags can come before children to be yes. Extension flags coming after commands being a must is a good thing I think, regardless of the technical reason behind it.
| There is not a plan to expose a printer at this time, so extensions will have to handle the possible `output` enumerates | ||
| of `text`, `json`, `jsonl`, and `none` themselves. This is because the current CLI printer has too many quirks and is |
There was a problem hiding this comment.
My feeling is it's very likely they just won't
That's not really the end of the world or anything but I just want to acknowledge that's the likely outcome if we don't start with a helper.
Alternatively we could require them to always do jsonl, and just transform that into the desired format for them. I don't have a strong feeling on it, but it's an option.
Summary
This is a proposal for supporting extensions in the CLI.
RENDERED
Please leave comments/feedback. If the comment list grows unwieldy and/or we've resolved most but still have more to say, this PR can be closed and another will be opened. All alternative options/suggestions welcome. Requests for clarifications or justification on anything welcome.
Note, some things are missing by intention because they require more research, but we didn't want to hold up the ability to review.
As part of this, all legacy CLI proposals for
tctlwere moved to apreviousfolder since they aren't weren't for what is currently termed the "CLI".