Extension execution model

[vdemeester]

Feature request

It should be possible to have a simple extension execution model. It would be similar to git or kubectl, in that, if a command is prefixed by tkn- it could be seens as a sub command.

$ ls /usr/local/bin
tkn-foo
$ tkn foo --bar
# invokirng /usr/local/bin/tkn-foo with following args
# […]

It would, however not be able to shadow existing subcommands, aka if I define a tkn-task and put it in my PATH, it wouldn't affect tkn.

Use case

There is at least two use case that would benefit from this feature:

• experimental projects and other repositories could use this to be able to quickly enhance the tkn experience and gather feedback before integrating in tkn directly
• it would reduce the potential dependencies headaches that we may have by integrating all tekton components. We already can have this with the triggers integration if the dependency of pipeline we track and the one triggers track differs.

We could think of quite some use case

# the hub (https://github.com/tektoncd/hub)
$ tkn hub search kaniko
…
$ tkn hub import buildah
$ tkn hub import buildah/0.2 --as  buildah-0_2
# the result API (https://github.com/tektoncd/experimental/tree/master/results)
$ tkn result list
$ tkn result logs an-old-archived-pipeline
# the OCI experiment
$ tkn oci create --from ./tasks/my-task.yaml --as quay.io/vdemeest/foo:is-bar
$ tkn oci extract quay.io/vdemeester/foo:is-baz
$ tkn oci add …
# the dashboard (https://github.com/tektoncd/dashboard)
$ tkn dashboard deploy …
# the operator (https://github.com/tektoncd/operator)
$ tkn operator install …

Note that the distribution part of this is not covered and can be discussed later on. Once we have that feature we can decide what could be the distribution model (we can also decide it's not in the tkn responsabilies and the distribution can be handle separately — by package managers, krew, …).

/cc @chmouel @sthaha @imjasonh

/kind feature
/milestone "0.12.0"

[chmouel]

👍

[danielhelfand]

For clarification, this would mean every project basically supporting some project-specific cli (e.g. triggers, dashboard, operator, etc.)? Think the only thing needed would be some way to avoid overlap between projects, but in favor of the basic concept.

We might also want to develop some type of CLI style guide to enforce some level of consistency for these projects.

[vdemeester]

For clarification, this would mean every project basically supporting some project-specific cli (e.g. triggers, dashboard, operator, etc.)? Think the only thing needed would be some way to avoid overlap between projects, but in favor of the basic concept.

Yeah, could if they want.

We might also want to develop some type of CLI style guide to enforce some level of consistency for these projects.

Definitely 🙃 we could even define some "helper" to make it easy to create those sub cli.

[wlynch]

Generally in support of this (for more validation- this follows a similar model to tektoncd/pipeline#2590).

One question (mainly because I'm not super familiar on how this works) - would this model cause any issues for autocompletion?

[vdemeester]

Generally in support of this (for more validation- this follows a similar model to tektoncd/pipeline#2590).

One question (mainly because I'm not super familiar on how this works) - would this model cause any issues for autocompletion?

Not necessarly. We can "update" our tkn completion code to take into account this (and call tkn-foo completion to get the completion from the called binaries)

[wlynch]

/cc @dorismeixing @dibyom

[kameshsampath]

@vdemeester I think this is a great add. Instead of import shall we have it as install , so we can have its uninstall counterpart ?

[sthaha]

/assign

[sthaha]

/unassign
/assign vdemeester