The bump of a major version of the Node.js dependencies changed
the format for the data received over HTTP (string vs. object).
This fixes that test to use JSON.stringify().
Signed-off-by: Lance Ball <lball@redhat.com>
* Add ability to add all custom function configuration in a separate module.
Co-authored-by: Dejan Bosanac <dejan@sensatic.net>
Co-authored-by: Jim Crossley <jcrossley3@gmail.com>
Co-authored-by: Jim Crossley <jcrossley3@gmail.com>
* ci: increase dns update max retries
* src: Makefile accessibility
Restructures the Makefile for better readibility
Separates core unit tests from template unit tests
Adds a `help` target highlighting core targets
Removes unused 'cluser' and 'release' targets
Removes unused targets
Restructures repository cluster setup and configuration scripts
to be used both for local testing as well as in CI. Adds a
CI-specific ci.sh script for the differences. Additionally:
- Upgrades to knative v0.23.0
- Upgrades eventing from v1beta1 API to v1
- Adds binary installation script (linux)
- Serializes Build, Int Test, e2e test steps
- Installs Broker and Channel to support Knative Quickstart tutorial.
- Runs a test echo server during installation
- Adds event-based waits in place of most blind time-based waits
- Adds explicit Kubernetes version for KinD
- Replaces a NodePort patched Koourier with an explicit ingress
- Adds retries while activator webhook becomes available
- Merges allocate and configure
This should simplify the unit tests. Only the invalid_event test uses
the actix-web test helpers, just as an example to show it's the HTTP
plumbing that will fail the request when it tries to construct an
Event from invalid (or missing) headers.
* feat: client progress listener 'stopping' state
* src: testable commands
Restructures commands to accept a fn.Client constructor on command
instantiation. This allows the concrete implementations, or entire
client to be mocked for testing.
Also some minor refacotring as necessary to shoehorn into the pattern.
* fix: increase default timeout to 120s for service creation
* chore: bump kind, knative and kubectl versions
* 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.
Lance Ball
Markus Thömmes
Julian Friedman
Dejan Bosanac
Luke Kingland
jrangelramos
Matej Vasek
Jim Crossley
Zbynek Roubalik
Luke Kingland
github-actions[bot]
Lucas Holmquist