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>
Until the next release of Quarkus in November, we'll need to have some special
checks so that we don't add these probes to Quarkus based functions. In the
meantime, we can at least set the liveness and readiness endpoints on the
Node.js/Go functions to /health/liveness and /health/readiness respectively.
Fixes: https://github.com/boson-project/faas/issues/169
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>
This commit modifies the CI action so that it should bump minor versions
until we explicitly have a 1.0.0 release. I've also bumped the version
of release-please-action to the latest 2.5.5.
Signed-off-by: Lance Ball <lball@redhat.com>
When dealing with images, instead of referring to an image repository,
let's instead use the more correct term "registry", even though we're
actually using "registry/namespace" in most case.
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>
Also adjusted some dependencies and overwrite version to align
transitive dependencies.
Not sure why buildpack uses such an older docker dependency but that
clases with the docker dependency that is introduced by knative-dev/test-infra
(which is a dependency of the knative direct dependencies)
If there is a way to exclude a transitive dependency like that on test-infra,
this could be the better way to achieve the same result.
The build now works on macOs natively which was not the case before.
There was a typo in the upload part of the CI. Also, there was a section
that (thankfully) did not run, which would have created a second release.
Moved the release-please action later in CI so less time elapses between
the creation of the release, and the upload of the binaries.
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
```
* fix: correct value for config path and robustify
The hardcoded, initial value for the configuration path was set to
`.faas/config`. But `configPath()` immediately sets this to the correct
value of ~/.config. Both the create and init commands use `configPath()`
to search for additional templates, if they exist, and were each doing
`filepath.Join(configPath(), "faas", "templates")`. This commit also
changes `configPath()` so that it is `~/.config/faas` and does so in a
cross platform friendly way. If the `$HOME` directory cannot be
determined, the config is assumed to be at `./.config/faas`.
* squash: remove config variable entirely
The cobra package, magically appends "[flags]" to the usage string
if a command has flags. By adding "[options]" to the usage string,
we end up with help text that looks like this.
```
faas init <name> [options] [flags]
```
This commit fixes that.