* chore: bump to buildpacks v0.8.2 for all versions
This is causing me to rethink using versions in these templates, and our
overall buildpack version/release strategy. But for now, we should land
this before 0.16.0
* adds trust for any quay.io/boson builder
Signed-off-by: Lance Ball <lball@redhat.com>
* Rust templates for http/event triggers
Each template is a fully-formed actix-web application that includes a
main.rs providing the server configuration and a handler.rs showing an
example function and a few simple unit tests. A README.md provides a
bit more detail to get the user started. The events handler is similar
to the example in the old faas-rust-runtime project.
* With developer guide for Rust
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 specific version numbers to each of the builder images
referenced in function templates, func.yaml file. Because the API for
at least some of the runtimes has changed over time (looking at you,
faas-js-runtime), we should consider publishing our func.yaml files with
known-to-be-working-with-this-release versioned builder images.
Signed-off-by: Lance Ball <lball@redhat.com>
* feat: add typescript templates
Bumps the faas-js-runtime dependency to 0.7.1 and Node.js buildpack dependency to v0.8.1
fix file globbing on windows
adjust eslint/prettier for windows
improve READMEs
add usage guide
Signed-off-by: Lance Ball <lball@redhat.com>
* Simplify the nodejs events template
Pretty-printing the contents of the event and its envelope for each
request. This is handy when invoked as a Knative event sink as some
sources, e.g. Kafka, ignore the response body.
Co-authored-by: Lance Ball <lball@redhat.com>
* Expect the event parameter to be the entire CloudEvent
This will require a change to the faas-js-runtime, but at least the
template won't need to change when that's released
* Update nodejs guide to reflect 2nd arg's type is CloudEvent
* Templates now using faas-js-runtime 0.7.1
Co-authored-by: Lance Ball <lball@redhat.com>
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>
Luke Kingland
github-actions[bot]
Lance Ball
Luke Kingland
Zbynek Roubalik
Matej Vasek
Jim Crossley
Lucas Holmquist
jrangelramos
Helio Frota