The flag pointing to extensible template repositories is now called
repositories. This fits with the expectation that this location
will most likely be filled with git repositories containing templates.
This commit is a breaking change.
Change the `--trigger` flag to be `--template` and the `--templates` flag
to be `--packages`. This is being done in anticipation of future work focused
on making `func` extensibility friendlier, and in an attempt to finalized some
of the naming conventions we have used to date.
In fact, the `--trigger` flag used to be `--template` but we decided to
change that a few months ago. This commit reverses that decision. The reason
behind this is twofold.
1. Using 'trigger' has proved to be confusing. Even if I create a function
with an HTTP trigger, it will still be invoked when a CloudEvent is sent
to the function process. Or alternatively, it is possible to send a raw
HTTP request to a function with an event trigger. Using 'template' instead
implies that the incoming request does not determine how the function is
invoked - rather it is the structure of the function signature that informs
the invocation.
2. The `trigger` terminology is not inclusive enough for our use cases. For
example, a third party provider of function templates may provide a template
for multiplexing incoming HTTP requests in Go using `gorilla-mux`. It doesn't
really make sense to say that `gorilla-mux` is the trigger. It's just a
defining feature of how the template is structured. I think this:
```sh
func create --runtime go --template gorilla-mux
```
Makes more sense than this:
```sh
func create --runtime go --trigger gorilla-mux
```
In changing this flag to be `--template`, we then need to come up with
another name for our existing `--templates` flag. I chose `--packages`
because what is being specified here is more than just the template. The
user sees only the function template when they run `func create...` but
the filesystem from which this template is pulled also contains metadata
about the template - most importantly right now, `.builders.yaml`. It is
conceivable that we may ultimately want to stuff these directories with
event more metadata in the future.
Something like `--packages` makes sense to me, but I am open to suggestion.
Thinking of these as a package also allows for better extensibility features
down the road. For example, users could reference packages at a URI like so.
```
func create --packages https://mycompany.com/function/templates.tgz
```
This would result in `func` downloading the tarball, extracting it to the
config directory, and using it for additional templates.
Signed-off-by: Lance Ball <lball@redhat.com>
Renames trigger to template, removing it as an unnecessary configuration.
This reiterates that a Function implementation can change function sig
implemented at any time, and it is not part of the configuration. This
sets the stage for renaming 'templates', and the finalization of the
use cases enabling extensible templates.
This commit adds an Emitter to be used by the CLI commands
for sending CloudEvents to functions, either locally, on
the cluster, or at a specified endpoint.
Signed-off-by: Lance Ball <lball@redhat.com>
This commit modifies the progress meter so that, by default there is no
step counter. It also modifies the responsibility for calling `Done()`,
making it the job of the command rather than the client. This is because
the client does not know how many commands will be executed and therefore
cannot know when the progress bar is done.
This commit also adds String() to the progress bar, and moves logging
responsibility out of the deployer itself and fully into the client.
Deployer#Deploy() now returns a DeploymentResult.
Fixes: https://github.com/boson-project/func/issues/296
Signed-off-by: Lance Ball <lball@redhat.com>
There are some places where I've changed variable and function names
where it wasn't strictly necessary. If you don't mind the bit of churn
that results, changing these makes `rg -i envvars` a nice way to check
for anything that could be overlooked.
Signed-off-by: Lance Ball <lball@redhat.com>
* chore: Update help messages and adding examples.
This commit introduces fixes for the top-level help message as described in #187.
It does not address:
* #216 - Use `kn function` in help message when run as a plugin to kn
* #215 - Group main help message to put important commands to the top
* #214 - Make examples in usage message parameterizable
Luke Kingland