* 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
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>
The event template was just returning a string, but the default response
content type is application/json so browsers were failing to parse the string
as JSON.
Signed-off-by: Lance Ball <lball@redhat.com>
This commit modifies the Node.js template so that it returns a CloudEvent. The
tests are also modified to test for CloudEvent attributes and headers. Additionally
the faas-js-runtime bump reverses the parameters for the function.
Fixes: https://github.com/boson-project/faas/issues/190
Fixes: https://github.com/boson-project/faas/issues/194
Signed-off-by: Lance Ball <lball@redhat.com>
The 0.4.0 version of faas-js-runtime extracts the CloudEvent data from
an incoming event and provides that as the first parameter when invoking
a function which receives a CloudEvent. This commit bumps to that version
as well as improves the overall readability and code documentation for the
Node.js CloudEvent function.
Signed-off-by: Lance Ball <lball@redhat.com>
* chore(templates): bump faas-js-runtime to 0.3.0 and update the name
The module name lost its @redhat prefix, and bumped a version. This
pulls in that latest dependency.
Running pkger for the first time on a new system also resulted in a
minor version bump for that dependency.
Signed-off-by: Lance Ball <lball@redhat.com>
This commit adds a .builder.yaml file to each template directory. In the file
there is at the moment a single key/value pair, "default: <image>", where the
actual builder image name is <image>. Using a mapping allows the future
possibility that a user may specify a builder image by name via a flag on the
command line. For example,
```console
faas build --builder native
```
When a project is initialized, the .builder.yaml file is read, and the default
builder is saved in the project's .faas.yaml file. The .faas.yaml file is then
consulted when building an image with `faas build`. If the builder image is
specified, then the builder will use it. Otherwise, it will fallback to the
defaults. This allows developers to create custom builders, and specify them
in the configuration file.
After extracting the builder image from .builder.yaml in the project directory,
this file is deleted.
This commit also adds Verbose to the init command.
Currently the templates have a `local.js` file and an explicit dependency
on the @redhat/faas-js-runtime module. This removes that build-time
dependency and replaces it with a runtime dependency by using the (pending)
CLI from the module.
This is nice for a couple of reasons.
- Reduces the build time during `faas deploy`
- Eliminates the need for `faas` to bump with updates to faas-js-runtime
See: https://github.com/boson-project/faas-js-runtime
This commit updates the Node.js templates to use the latest faas-js-runtime
framework, and fixes a couple of dependency issues and broken tests. I have
also added a build time test for these templates so that if/when they change
again, we can be sure to catch any problems.
Note that this template currently points to boson-project/faas-js-runtime
for it's framework dependency as it depends on currently unreleased features.
Once 0.3.0 of that project is released, this template should be updated.
This dependency is only needed for local testing and development.
Lance Ball