* update root and version structure and help text
* fix: limit openshift int test with tag
* refactor: commands to use simplifed, unified constructor
* fix ineffectual assignment lint error
* cleanup
* add repository to run command
* callout for forthcoming s2i builder impl
* lint errors
* re-add the deferred client factory
* remove setNamespaceFlag now that it is persistent
* avoid side-effect of global-mutating deploy tests
* reduce line-by-line difference for PR ease
* simplificaiton of tests and comment lines for further PR ease purposes
* reduce inconsequential differences for ease of PR
* tests to RootCommandConfig
* review comment updates
* fix lint errors
* replace stdlib Setenv in tests
Using t.Setenv will require an update to go1.17, which is out of scope
for this PR.
* pass ClientFactory throughout
* explicitly empty test command args
See https://github.com/spf13/cobra/pull/155
Errors can still be encountered when, for example, using precomiled
tests. Explicitly setting constructed command args to the empty slice
ensures we avoid hitting any futher edge cases.
* feat!: rename 'emit' to 'invoke' and default to local
This commit renames 'func emit' command to 'func invoke' and makes the
default behavior to send an event to localhost. The special '--sink'
value 'local' is changed to 'cluster' to indicate that the function
should be invoked on the cluster instead of locally. All other behavior
has remained the same.
BREAKING CHANGE
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: update commands.md doc
Signed-off-by: Lance Ball <lball@redhat.com>
* squash: change Emitter interface to Invoker
Changes Emit() to Send() in the (now named) Invoker interface, and changes
Emit() to Invoke() in the client.
BREAKING CHANGE
Signed-off-by: Lance Ball <lball@redhat.com>
* squash: use a common Invoker interface for HTTP and events
Signed-off-by: Lance Ball <lball@redhat.com>
* checkpoint
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: change Emitter to EventInvoker
Signed-off-by: Lance Ball <lball@redhat.com>
* Invoke v2 Draft
* feat: client invoke function
* static invoke defaults and methods
* remove assimilated invoker package
* includes an ignored .func directory on create
* Instances manager with local and remote defaults
Funciton Info is now Instance, representing a Function in a given
environment.
Describing a Function instance is now Instances().Get(f, environment)
Moves Runner to be async with a Stop method to enable returning runtime pid
and port for persisting.
Instances now have a place for primary Route in addition to all routes slice
Running Functions write PID and Port to .func
* cascading targets: local vs remote vs ad-hoc endpoint
* runner start signals and cancel cleanup
* return run on context done or err on channel
* async runner
Refactors the image runner to start the container asynchronously,
reporting back the port on which it started. Errors are communicated
back via a provided channel and stop is signaled using context
cancelation.
* pid neither required nor available
* add withTransport option
Incorporates addition of custom transport of the emitter into the
renamed version invoker. Flag and help text cleanup. Re-additionof the
Info accessor.
* schema now includes invocation data
* loop build msg
* run jobs
Externally exposed port is now chosen based on availability, with 8080
preferred and falling back to an os-chosen open port.
The Client Run method is now async, returning the port assigned to the
running Function, a stop/cleanup function and a runtime errors channel.
The Runner is internally divided into the runner and its started Jobs.
* job metadata
Extracts job metadata tracking to a Job object in the core,
Handles multiple instances of the same Function by creating a single
file for each instances in .func/instances/<port>
* remove superfluous error types and flag bindings
* feat: enable invoke target remote
* feat: preferentially invoke local, remote if running
* feat: read --file for invoke
* feat: invoke confirm prompts
* fixup cli tests
- Updates to handle asynchronous Runner
- Standardize on the naming convention for selective running
* docker runner tests and lint errors
* test refactor
* feat: invoke format override
* comments, spelling and other cleanup
* invoke command doc
* feat: invoke format interactive option
* rename runjob.go to job.go
* e2e test flag update
* test naming homoginization
* silence build activity messages when verbose
* test debugging
* code review updates
- return Job from Client.Run rather than constituent members
- Treat .gitignore as contentious, punting on feature to mutate if
extant.
- docs wording changes
- add invocation format to pertinent manifest.yaml files
* help text spelling etc.
Co-authored-by: Lance Ball <lball@redhat.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>
* 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
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.
Luke Kingland
Matej Vasek
Lance Ball
Markus Thömmes
Luke Kingland
Zbynek Roubalik
Jefferson Ramos