* feat: repository management API
Adds a Repositories memeber to Client which enables management of
extensible repositories via methods Add, Rename, Remove, and List.
* fix: repositories urls
Validates that .Add input is parseable as a URL
Tests explicitly convert path to slashes
* 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>
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
* 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>
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.
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.
Lance Ball
Luke Kingland
Matej Vasek
Luke Kingland
Zbynek Roubalik