* example message changes between standalone and plugin
Signed-off-by: Fabian Lopez <lfabian@vmware.com>
* make template name a parameter in replaceNameInTemplate
Signed-off-by: Fabian Lopez <lfabian@vmware.com>
* use ExecuteTemplate error
Signed-off-by: Fabian Lopez <lfabian@vmware.com>
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>
* fix: hide progress indicator if asking for creds
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* fix: NPE in integration test
Signed-off-by: Matej Vasek <mvasek@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>
* feat: client progress listener 'stopping' state
* src: testable commands
Restructures commands to accept a fn.Client constructor on command
instantiation. This allows the concrete implementations, or entire
client to be mocked for testing.
Also some minor refacotring as necessary to shoehorn into the pattern.
* fix: increase default timeout to 120s for service creation
* chore: bump kind, knative and kubectl versions
The flag pointing to extensible template repositories is now called
repositories. This fits with the expectation that this location
will most likely be filled with git repositories containing templates.
This commit is a breaking change.
Change the `--trigger` flag to be `--template` and the `--templates` flag
to be `--packages`. This is being done in anticipation of future work focused
on making `func` extensibility friendlier, and in an attempt to finalized some
of the naming conventions we have used to date.
In fact, the `--trigger` flag used to be `--template` but we decided to
change that a few months ago. This commit reverses that decision. The reason
behind this is twofold.
1. Using 'trigger' has proved to be confusing. Even if I create a function
with an HTTP trigger, it will still be invoked when a CloudEvent is sent
to the function process. Or alternatively, it is possible to send a raw
HTTP request to a function with an event trigger. Using 'template' instead
implies that the incoming request does not determine how the function is
invoked - rather it is the structure of the function signature that informs
the invocation.
2. The `trigger` terminology is not inclusive enough for our use cases. For
example, a third party provider of function templates may provide a template
for multiplexing incoming HTTP requests in Go using `gorilla-mux`. It doesn't
really make sense to say that `gorilla-mux` is the trigger. It's just a
defining feature of how the template is structured. I think this:
```sh
func create --runtime go --template gorilla-mux
```
Makes more sense than this:
```sh
func create --runtime go --trigger gorilla-mux
```
In changing this flag to be `--template`, we then need to come up with
another name for our existing `--templates` flag. I chose `--packages`
because what is being specified here is more than just the template. The
user sees only the function template when they run `func create...` but
the filesystem from which this template is pulled also contains metadata
about the template - most importantly right now, `.builders.yaml`. It is
conceivable that we may ultimately want to stuff these directories with
event more metadata in the future.
Something like `--packages` makes sense to me, but I am open to suggestion.
Thinking of these as a package also allows for better extensibility features
down the road. For example, users could reference packages at a URI like so.
```
func create --packages https://mycompany.com/function/templates.tgz
```
This would result in `func` downloading the tarball, extracting it to the
config directory, and using it for additional templates.
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 an Emitter to be used by the CLI commands
for sending CloudEvents to functions, either locally, on
the cluster, or at a specified endpoint.
Signed-off-by: Lance Ball <lball@redhat.com>
This commit modifies the progress meter so that, by default there is no
step counter. It also modifies the responsibility for calling `Done()`,
making it the job of the command rather than the client. This is because
the client does not know how many commands will be executed and therefore
cannot know when the progress bar is done.
This commit also adds String() to the progress bar, and moves logging
responsibility out of the deployer itself and fully into the client.
Deployer#Deploy() now returns a DeploymentResult.
Fixes: https://github.com/boson-project/func/issues/296
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>
* chore: Update help messages and adding examples.
This commit introduces fixes for the top-level help message as described in #187.
It does not address:
* #216 - Use `kn function` in help message when run as a plugin to kn
* #215 - Group main help message to put important commands to the top
* #214 - Make examples in usage message parameterizable
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.
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.
The CLI commands all printed confirmation prompts for the various flags
they exposed. This commit modifies that logic, so that there is no longer
a `-y` flag, but instead a `--confirm` or `-c` flag for each command, and
prompts are only displayed if using this flag. In most cases, the derived
values are printed even if not prompted for.
In call cases where the user is prompted, I have removed the "Verbose"
prompt, as that seems less like a configuration option that needs to be
confirmed, and more like just a CLI option for the current run which we
can just accept as-is.
The text for the prompts has also been reduced to one or two words.
Also added are some checks around image naming and repositories, short
circuiting failures that could occur if these are not specified or are
unknown. For example, if a user does `faas init` and then `faas deploy`
we don't yet know what the image name should be - one hasn't been built.
Fixes: https://github.com/boson-project/faas/issues/91
Fixes: https://github.com/boson-project/faas/issues/90
Fixes: https://github.com/boson-project/faas/issues/89
- Replaces globally-scoped formatter function with methods
- Defines enumerated Format types
- Renames the 'output' flag 'format' due to confusion with command file descriptors
- FunctionDescription now Function
- Global verbose flag replaced with config struct based value throughout
* 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.
* Add version subcommand
* Update builtin version template to raw version number output
* Prefix environment variables with "FAAS_" namespace
* Combine Execute with root.
Fabian Lopez
Zbynek Roubalik
Senthilnathan M
Matej Vasek
Lance Ball
jrangelramos
Luke Kingland
Markus Thömmes
Luke Kingland
Jim Crossley
Kamesh Sampath
Roland Huß
David Simansky