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.
Lance Ball
Luke Kingland
Zbynek Roubalik
Matej Vasek