* src: refactor commands
Commands are constructed from root,
not by using init() blocks.
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* fixup the prefix issue
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* fixup style
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* fixup nolint:misspell
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* feat: completion --build flag of deploy sub-cmd
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* src: refactor
Moved functionality.
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* 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>
* Use common functionality for docker cred retrieval
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* fixup: docker auth secret for tekton pipeline
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* fixup: style
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* allow build to be triggered from run when fn.Image is missing
* add build check when run by the run command
* added unit test for run command
* remove log output
* rename run test
* change build trigger to be managed by a flag and not a prompt
* tlet users know about the --build flag in the error message
* fix code check issue
* add some debug info to the run_test
* Update cmd/run.go
Co-authored-by: Luke Kingland <58986931+lkingland@users.noreply.github.com>
* add build field to runConfig
* fix issue with cmd args for testing
* refactor run tests to use mocks
* update imageless function run error message
* add check for build error test case
* run unit test cleanup
* empty commit
Co-authored-by: Luke Kingland <58986931+lkingland@users.noreply.github.com>
* src: dialer pod auto-exit
The pod should exit (be Completed) when func exits.
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* feat: use in cluster dialer by default
This sets http.DefaultTransport to our specialized RoundTripper.
The RoundTripper first tries dial in standard way.
If dial operation fails due to hostname resolution error
in cluster dialer will be used.
Signed-off-by: Matej Vasek <mvasek@redhat.com>
These flags are used by multiple commands, and explicitly setting them for
each command risks errors that may not be easily detected (see the deleted
flag text for `namespace` in deploy.go). The downside to this is that wording
is not sligtly tweaked for the command - see again some of the removed text
for `namespace` that was slightly different for each command, but usefully so.
I'm not 100% convinced this change is needed, since it does reduce the flexibility
of the user facing text. But if it had existed before we wouldn't have had
incorrect text for `deploy`.
Fixes: https://github.com/knative-sandbox/kn-plugin-func/issues/221
Signed-off-by: Lance Ball <lball@redhat.com>
* feat: config and repository path creation
Removes need to use a client to trigger creation of paths
Adds back static path accessors
Enables creation of paths when configured repos is outside config
Cleans up instantiation logic, including removal of some setters
* fix spelling mistakes per review
* add flag to push image at the end of a successful build
* ensure that push flag is binded to viper
* add unit test to build command
* change build test name
* add registry to build test
* fix e2e test problem
* fix compile error
* add push fail test case
* avoid pusher instanciation in absence of push flag
* fix: make registry validation work again
In ccf00152be
the behavior of `NewFunction()` changed slightly, such that it no longer actually
works without a provided and valid path. This was not caught in any of the
tests, because it's the CLI code that was making this call, and the end to end
tests that exercise the build command, use the `--repository` flag, causing
the repository validation code path to be slightly different.
This commit just adds the path so that `func build` without a `--repository` flag will work again.
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: add validation for registry flag and a test
Signed-off-by: Lance Ball <lball@redhat.com>
* making language as required flag
* create tests fixed
* gofmt
* more tests fixed
* more tests added for invalid runtime and template
* changes removed from client library
Co-authored-by: Luke Kingland <58986931+lkingland@users.noreply.github.com>
* src: directly serialize Function metadata as func.yaml
Functions now save directly to func.yaml using .Write().
Fixes a serialization error where defaults were not respected on load.
Moves runtime and template defaults into function constructor.
Extracts Function validation (was config validation) into separate functions.
Extracts associated test files (validation) into separate unit test files.
Updates schema generator to use Function
* comment spelling and re-enabling tests
`func list` prints the header when it gets `No functions found`.
This patch stops displaying the header.
ASIS
```
$ func list
No functions found
NAME NAMESPACE RUNTIME URL READY
```
The header `NAME NAMESPACE RUNTIME URL READY` should not be print.
TOBE (by this patch)
```
$ func list
No functions found
```
* feat!: add support for manifest.yaml and runtime.yaml
BREAKING CHANGE
This commit adds the concepts of a manifest.yaml file at the top level
of a template repository, and a runtime.yaml file for each language/runtime
within the repository. Prior to this, repository metadata was primarily
restricted to information that could be gleaned from the file system, such
as the directory name used as the Name.
A manifest.yaml file contains a Name, URL, Version, and a list of supported
runtimes; and if all of the runtimes expose the same health endpoints, these
can be set here.
Within a runtime directory, there may exist a runtime.yaml file which allows
language pack providers to set the health endpoints, overriding the values
set in manifest.yaml, as well as Builders and Buildpacks.
This change removes support for a builders.yaml file in a runtime/template
directory, as this was guaranteed to be redundant with the builders.yaml
file in a sibling template directory. The choice was to move these up a
level to runtime/runtime.yaml.
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: bump go version for unit tests
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: using go 1.16 now requires 'go mod tidy'
See: https://golang.org/doc/go1.16
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: restore support for directory traversal
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: whitespace linting
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: update func_yaml-schema.json
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: spelling errors caught by reviewdog
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: use os.ReadDir
Signed-off-by: Lance Ball <lball@redhat.com>
* squash: restore project creation from remote repos
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: remove billyFilesystem
Signed-off-by: Lance Ball <lball@redhat.com>
* doc: expand on language pack documentation
Adds more detail around how language packs can be provided by third
parties, and the expected structure and metadata required.
Fixes: https://github.com/knative-sandbox/kn-plugin-func/issues/452
Signed-off-by: Lance Ball <lball@redhat.com>
* doc: update language pack documentation
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: cleanup deps
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: cleanup deps - again
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: reviewdog whitespace cleanup
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: custom repo template listing
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: bump go version for integration tests
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: adjust test-templates repo uri for e2e
Signed-off-by: Lance Ball <lball@redhat.com>
* fix: don't fail when extended templates don't support a given runtime
Signed-off-by: Lance Ball <lball@redhat.com>
* src: repo and template type hierarchy
As the client API increases in complexity, upgrading to a more correct
type hierarchy for the object managers serves to keep things clean. In
this update, the Repository and Templates manager now use constructors
with private members, including a backreference to the root Client
object, which provides the mangers with full access to the current
client instance API for implementing their (growing) features.
* src: template manager writes
The templateWriter struct has now been upgraded to integrate with the
newly-added type system which includes a Templates Manager by adding a
.Write method which writes a template at the given location. This
encapsulation of the write functionality moves us towards having a
cleaner abstraction atop writing any template to disk from any
repository.
In addition, the "Get" prefix was removed from many accessor methods, as
this is standard a Go idiom.
* src: templates write including denormalize
- merges templateWriter into templates manager
- denormalization of builders, health endpoints etc. made part of .Write
- write logic now works on a Template rather than string paths etc
The templates manager can now write out a template given a function directy.
Included internnaly to write is the denormalization logic, which is now closer
to where it is used, which should improve cohesion and decouple the template
implementation detail from the Client. Also moves the write logic closer to the
template itself, with the expectation the same will happen for functions when
Config and Function are merged.
* src: vendor
* src: merge manifests into domain model
In general, the manifests sytsem is merged more tightly into the overall
system while also expalding it to use a path to templates to avoid
having to create a full filesystem shadow-copy in yaml. Preserves
backwards-compatiblity by keeping the base case a yaml-free repo of only
templates. Creaets a hierarchical inheritance from repository to
runtime to template for builders, endpoints etc. whcih allows for the
manifest within templates to be a first-class citizen, though its use
will be rather rare. Some more in-depth explanations of the more
substantive changes are as follows:
- Merges Manifest with Repository
The Manifest structure is essentially a serialized Repository, so they
are now the same object.
- Converts repo URL to a calculated field
The URL is informative and entirely dependent on the current state of
the repo, so it should be calculated to avoid confusion and avoid being
serialized to the manifest.
- Merge FunctionTemplate with Template
The struct being serialized here is a Template, so they are now the same object
- Extracts new "BuildConfig" embedded struct
The Builders and Buildpacks members are shared between Repository,
Runtime and Template, so they are now an embedded stuct in the same
manner as HealthEndpoints.
- yaml 'inline' declaration for embedded structs
The HealthEndpoints and other embedded structs were not actually being
read from their configs because of a nuance of yaml which (in contrast
to json unmarshallers) requires the `,inline` tag on the struct member
to trigger inclusion in decode.
- Replaces Repository's runtimes member with templates
While it is true that on disk templates are subdivided into their
effective runtime, this is for ease of development. The logical
structure is: repositories have templates. Templates are applicabe to
runtimes. Therefore the correct API is to have templates a direct
member of repository but requiring a runtime filter for access.
- Use repository templates path instead of full list
The goal is to support the use of repositories which contain more than
just templates. The solution is to define an alternate location for
templates (such as ./templates). Creating an entire exhaustive manifest
where each runtime and each template is defined with a name and path is
a usurpation of the responsibilities of a filesystem, and causes
unintend negative knock-on effects. Let's try this simple solution
before jumping to the nuclear option of defining a filesystem-in-yaml.
- Use filesystems when loading repository objects
The fact that a file exists on the disk, embedded, or remote should be
of no concern to most of the code. This is accomplished by using the
filesystem abstraction which is used during template writing. This will
be further improved in future versions by upgrading to use the fs.FS
interface and tooling.
- Uses manifest.yaml at all levels
Once the hierarchical nature of the manifest was instituted, it seemed
more intuitive to have the same filename at each level. This also has
the nice benefit of being backwards-compatible with template-level
manifest. This is not a correctness issue, but a guess that remembering
a single filename which can exist at different levels in a hierarchy is
easier to remember than different filenames, and its location in the
hierearchy sufficient differentiator making the different filenames
_perhaps_ unencssary. The constants are left as separate for an easy
revert.
- Moves static defaults into code wherever possible
Wherever yaml was being statically compiled in, it was updated such that
canonical values for static defaults were defined on the Go structure,
with the yaml being for overrides. For example Default Readiness and
Liveness endpoints.
Some notable benefits of letting the filesystem do it's thing:
* Preserves the ability to create a repository of templates without
hacking yaml
* Reflects changes directly in IDEs which have native support for
filesystem, not so for a proprietary manifest.yaml
* the builtin repository has no name, so parsing a manifest from within
it is both prone to error and confusing, as it could lead future
developers to submit PRs which change its name.
* fix: revert repository.git to a bare server repo
* src: repository default name
The Repository struct now includes a Name and DefaultName. The former is
the current name of the repository, and corresponds to the path on disk.
The latter is the name specified in the manifest.yaml, and is used as
the default name of the repository when no name is provided.
Fixes an issue where there could be name collisions using a uuid for the
initial name until the manifest is read in.
Restructures the embedded repositories such that one exemplifies a base
case repo with no metadata and only templates, the other specifying a
manifest to exemplify for example a complete language pack.
Adds a test such that all three cases are covered: explicit name, no
name but manifest-defined default name, URI-derived name.
* feat: single repo mode
Enables single repository mode suystem-wide, which fully implements the
logic intended by the WithRepository option.
The default repoisitory is now programatically defined, and while by
default is the embedded repo, it can be overriden using the
WithRepository option. This keeps the logic internal to the
repositories managet, removeing the need for a crossp-cutting concern in
other parts of the system.
* src: manifest inheritance and existence tests
Respects alternate templates location when defined in a manifest.
Respects manifest embedded structs HealthEndpoints and BuildConfig at
each of the three levels, with inheritance: Repo, Runtime and Template.
Separates test repositories into the two cases of a templates-only repo
(with no manifest) and a complex repo (with manifests) such as for
language packs.
Leaves the BuildConfig struct as inline but sets the HealthEndpoints as
being named, such that the latter has its fields in the yaml under the
key 'healthEndpoints' but the former does not (passthrough).
Adds error checks when attempting to access named repo when in
single-repo mode.
* src: remove function merge
Removes feature of mergine a func.yaml defined in a template in favor of
sticking with the manifest.yaml until such time as this is requested.
Assuming YAGNI.
* src: repo filesystems
- Embeds repositories with an internal filesystem
- Replaces filesystem disk checkouts with in-memory until final write
- Combines template Write of various types into a single write which uses the
filesystem of the applicable templates's repository
- Template is now a simple noun, with logic localized to the templates manager
- Adds better error message regarding single repo mode conditions
The reason for replacing filesystem-based repository instances with in-memory
(especially remote for WithRepository mode) is for a few reasons: First, 'Add'
will fail without using the temporary UUID hack if there already exists a
repository of the _repo_ name (due to a filesystem collision). We have
to read the repo to determine the default name as well, so it's messy to avoid.
Second, using an on-disk version is potentially leaky because it may leave
files on the system in the event of a process interruption; able to be
mitigated, but with a likewise hacky use of a os temp directory. Third, it
may cause racing conditions when using multiple instances the Client as a lib.
Lastly, it precludes our ability to run without touching the filesystm: a
useful mode when running as a pure library or in security-restricted
environments.
* fix: paths within embedded fs
* src: repositories code cleanup
* Removes the manual 0_18 version suffix
* Reanames "single" (uri for single-mode) to the more descriptive
"remote" (with associated accessor api)
* Default repo name when no URI provided is set to default
* Various wording improvements in error text and comments
* src: error formatting
* feat: templates from local file paths
Adds back the local os filesystem as a fallthrough to support loading
template repositories from file:// paths on disk, without the
requirement that they also be git repositories.
* fix: clone once
Fixes the shortcut of performing a clone to read the manifest prior to
cloning the repository to disk. This double-clone was replaced by a
single clone (applying the manifest) followed by a file copy from the
in-memory FS to the on-disk repository location.
* src: test fixes
* respect explict name on repository .Add
* fail if repository already exists
* update expected test filenames to new general (non-go-specific) setup
* adds the default repo name to the NewRepository constructor,
internalizing the somewhat tricky default logic.
* move repo write logig to repo itself, as it will contain impl-specific
nuances.
* invalid repo path is an error, but only if defined
* temporarily disable repository URL test
* src: update templates test to reflect new name 'cloudevents'
* src: fix go templates and repackage
* fixup: reviewdog spelling errors
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: reviewdog whitespace cleanup
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: run ./hack/update-codegen.sh
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: restore boson-project templates for e2e
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: do not error if default repo location does not exist
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: typo
Signed-off-by: Lance Ball <lball@redhat.com>
* paketo builder and paket community rust buildpack (#599)
* fixup: apply f161d50084
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: update documentation to match impl
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: add git attributes to ignore linting on binary files
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: remove whitespace
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: tweak linter rules
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: tweak .gitattributes
Signed-off-by: Lance Ball <lball@redhat.com>
Co-authored-by: Luke Kingland <lkingland2038@gmail.com>
Co-authored-by: Shashankft9 <48708039+Shashankft9@users.noreply.github.com>
* feat: create cli prompts
* feat: display effective runtimes in prompt
replaces the static list of supported runtimes with a dynamic list of
currently installed+available runtimes; called the effective runtimes.
Used for both prompting and validation.
* feat: dynamic create help and error text
Output from create help text and the create commands now show valid
options for both language runtimes and templates.
* feat: runtime tab completion for runtmes and templates
* feat: support FUNC_PARENT_COMMAND in help
* feat: confirmation of successful create
* fix: include name in initial creation
* src: remove unnecessary comments on create name
* fix: associate prompt questions with struct members in create
* e2e: update tests for language flag
* fix: support nonexistent repositories path
Listing installed repositories considers a missing path equivalent to a
lack of installed repositories. This will change to an error when the
logic to determin default config directory, and automatically create
initial structure, is moved into the client library.
* fix: only CLI-validate when no repo override
* 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.
Lance Ball
Matej Vasek
Luke Kingland
Senthilnathan M
Zbynek Roubalik
Fabian Lopez
Shashank Sharma
Kenjiro Nakayama
salaboy
knative-automation
Fabian Lopez
jrangelramos
Markus Thömmes
Luke Kingland
Jim Crossley
Kamesh Sampath
Roland Huß
David Simansky