This commit removes the Red Hat builders from the built in templates
for Go, TypeScript and Node.js, replacing them with paketo builders.
For Go, the builder is augmented with a simple buildpack that installs
the Go wrapper code and its dependencies. For TypeScript, the paketo
buildpacks oddly don't support an `npm build` step, so these templates
are also dependent on a small Boson buildpack. These buildpacks are
currently at https://github.com/lance/boson-buildpacks but should find
a home either in the boson-project organization, or the knative-sandbox
organization.
This change also slightly modifies how the Node.js and TypeScript
templates are structured, reducing the coupling between the buildpack
and a function project.
This commit includes the code in https://github.com/knative-sandbox/kn-plugin-func/pull/465
and is dependent on it in the use of manifest.yaml.
Provide sane defaults for health endpoints
Note that this will need to be documented as a requirement for
language packs that do not wish to provide explicit endpoints for
these kube health checks. In that case, the language pack should
specify these both as the root path, with a query parameter. For
example, `/?health=readiness` and `/?health=liveness`, or some other
similar construct.
Signed-off-by: Lance Ball <lball@redhat.com>
This commit introduces the concept of a `manifest.yaml` file which
can be added to each template directory to specify things such as health
endpoints, builders and buildpacks for the function.
It problematic that, because we don't yet have the concept
of a global configuration file, the only place to store this metadata is
in a project's `func.yaml` file. There is no reason a function dev
should be exposed to things like health endpoints. This information is
determined by the language pack and integrated by the builder. The only
reason we need it is that it's necessary to determine these endpoints when
deploying. Otherwise, we would have to insist that all language packs
provide endpoints at `/health/readiness` and `/health/liveness`.
This commit also adds support for a `buildpacks` property in `manifest.yaml`
which will be used to set the buildpacks when a function is being built.
Signed-off-by: Lance Ball <lball@redhat.com>
* 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>
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 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>
There are some places where I've changed variable and function names
where it wasn't strictly necessary. If you don't mind the bit of churn
that results, changing these makes `rg -i envvars` a nice way to check
for anything that could be overlooked.
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>
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.
* feat: add init/build/deploy commands and customizable namespace
This commit comprises some fairly large changes in the codebase.
The 'create' command has been extracted into 'init', 'bulid' and
'deploy' commands. The 'create' command remains, but now delegates
most of its work to these other three. This also has resulted in
some rework of the various flags.
In addition, it is now possible to specify the cluster namespace to
which the function will be deployed.