* feat: add support for labels in func.yaml and `func config`
This change adds support for setting labels on deployed functions. It uses
the interactive CLI prompt introduced by Zbynek to add, remove and list
labels applied on a deployed function.
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: fix string output for Pair type
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: review feedback
Signed-off-by: Lance Ball <lball@redhat.com>
Removes python caches on template test. This appears to be the original
cause of unnecessary rebuilds.
Adds pkger.go as an explict entry in the CODE prerequisite var. This
ensures pkged.go is generated if it doesn't exist, and removes the need
to explicitly enumerate it as a prerequisite to other targets.
Adds pkger.go to the clean target. This allows a 'make clean && make' to
work as one might expect. For example ensuring a rebuild if a template
files is removed.
The notable conceptual change here is that this does not induce a build of
pkged.go by explicitly enumarating it as a prerequisite (a difficult
thing to get right, and prone to errors in the future), but rather
directly enumerates ./templates as its prerequisite.
Additional minor modifications include:
- regenerated pkged.go such that this takes effect for main on merge
- adds an explicit target for the 'func' binary and aliases 'build'
- Makefile help text cleanup and consolidation
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>
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.
* 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>
This commit adds limited support for annotations in the func.yaml
config file. The feature is limited, because it's only additive. A
user can add an annotation `foo: bar` in the config and deploy the
function, successfully setting that annotation on the Service.
However, if they subsequently remove `foo: bar` from the config
file, it will _not_ be removed from the deployment. This is because
it's not possible to know, from the set of annotations that currently
exist on the deployment, which ones were set by us and which were not.
So, removing any annotations that are not in func.yaml is unsafe.
It may be possible to store in a hidden file somewhere all of the
user-supplied annotations, allowing us to diff func.yaml with that file,
but I'm not sure I want to go down that path. It might just be best to
document this limitation.
We may also want to document that annotations added through func.yaml
should be user supplied settings/values, and not annotations that are
managed by knative (e.g. the autoscaling annotations).
Fixes: https://github.com/boson-project/func/issues/307
Signed-off-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.
Uses the Cobra "Long" configuration for each command to provide more
descriptive text.
Example:
```console
faas help create 1.3m Mon 21 Sep 2020 09:55:40 PM EDT
Create a new Function, including initialization of local files and deployment
Creates a new Function project at 'path'. If 'path' does not exist, it is
created. The function name is the name of the leaf directory at path. After
creating the project, a container image is created and is deployed. This
command wraps 'init', 'build' and 'deploy' all up into one command.
The runtime, trigger, image name, image repository, and namespace may all be
specified as flags on the command line, and will subsequently be the default
values when an image is built or a Function is deployed. If the image name and
image repository are both unspecified, the user will be prompted for a
repository name, and the image name can be inferred from that plus the function
name. The function name, namespace, image name and repository name are all
persisted in the project configuration file .faas.yaml.
Usage:
faas create <path> [options] [flags]
Flags:
-c, --confirm Prompt to confirm all configuration options - $FAAS_CONFIRM
-h, --help help for create
-i, --image string Optional full image name, in form [registry]/[namespace]/[name]:[tag] for example quay.io/myrepo/project.name:latest (overrides --repository) - $FAAS_IMAGE
-n, --namespace string Override namespace into which the Function is deployed (on supported platforms). Default is to use currently active underlying platform setting - $FAAS_NAMESPACE
-r, --repository string Repository for built images, ex 'docker.io/myuser' or just 'myuser'. Optional if --image provided. - $FAAS_REPOSITORY
-l, --runtime string Function runtime language/framework. - $FAAS_RUNTIME (default "go")
--templates string Extensible templates path. - $FAAS_TEMPLATES (default "/home/lanceball/.config/faas/templates")
-t, --trigger string Function trigger (ex: 'http','events') - $FAAS_TRIGGER (default "http")
Global Flags:
--config string config file path (default "~/.faas/config")
-v, --verbose print verbose logs
```