* chore: update all references to kn-plugin-func
I did not change references in CHANGELOG.md but otherwise, I believe
this should cover all configuration settings, image names, package
names, etc.
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: fix instances_test.go
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: still some stray kn-plugin-func
Signed-off-by: Lance Ball <lball@redhat.com>
Signed-off-by: Lance Ball <lball@redhat.com>
* rebased and updated func struct
* fixing migration to 1.0.0 struct
* fixing on cluster tests
* updaating migration version to 0.34.0
* adding tests for marshalling and migration errors
* adding EOF new line
* updating migrations
* fixing wrong name
* fixing marshalling test
* adding EOF line
* fixing assertion
* chore: shared builder constants etc
* pretty-print the shared unknown builder error
* update builder impls to use shared defs and validators
* error and docs text formatting
* include static default short names
* comment updates and typos
* docs paths
* use the constants for the in-package builder defaults
* use builders.All but with caviat
* Fix docker client lifecycle
Avoid premature Close() of docker client.
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* Guard for usage of docker client after close
Signed-off-by: Matej Vasek <mvasek@redhat.com>
Tekton pipeline runs now use the same logic for determining default builder image as a local buildpack build.
In order to implement varying build strategies (s2i vs buildpacks), we were unable to rely on hard-coded builder images. These defaults were moved in-code, with builders defined in func.yaml being an optional manual overrdide. This PR updates the Tekton deployment process to rely on this defaulting logic, rather than require the func.yaml override (which would preclude a Function from being able to be built using other strategies).
All runtimes were actually using paketo builders already, but the
builders were still being explicitly set in manifest.yaml instead of
existing as a default in builder.go like all of the others.
Signed-off-by: Lance Ball <lball@redhat.com>
This commit changes the Python functions to use the open source Paketo
builders. The Paketo builders allow the use of a Procfile to indicate
the desired default start process for the container, so this has been
added to invoke Parliament at startup.
Also, there were no README.md files for Python, so I added them too.
Signed-off-by: Lance Ball <lball@redhat.com>
* update root and version structure and help text
* fix: limit openshift int test with tag
* src: verbosity to constructor param
* fix misspelling
* fix merge error
* chore: bump lifecycle version to 0.13.0
And add docker.io/paketobuildpacks as another trusted builder prefix.
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: bump to 0.13.2
Signed-off-by: Lance Ball <lball@redhat.com>
* chore: remove dead code
The default builders configured in builder.go were not only wrong, but
also not even used anymore. Removing them...
Signed-off-by: Lance Ball <lball@redhat.com>
* fixup: fix failing e2e tests
Signed-off-by: Lance Ball <lball@redhat.com>
* feat: automatically start podman service
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* src: refactor rename function
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* src: add commnets to tests
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* src: refactor rename function
Signed-off-by: Matej Vasek <mvasek@redhat.com>
* Enhance func.yaml to provide build envs to buildpacks
* Add schema file deleted by make clean
* Add function ValidateBuildEnvs to config.go
* Addressed review comments
* Revert makefile changes to pkged.go
* Fixed buildpack env update lost in rebase
* Add support for local env in buildEnvs
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>
This commit introduces the concept of a `manifest.yaml` file which
can be added to each template directory to specify things such as health
endpoints, builders and buildpacks for the function.
It problematic that, because we don't yet have the concept
of a global configuration file, the only place to store this metadata is
in a project's `func.yaml` file. There is no reason a function dev
should be exposed to things like health endpoints. This information is
determined by the language pack and integrated by the builder. The only
reason we need it is that it's necessary to determine these endpoints when
deploying. Otherwise, we would have to insist that all language packs
provide endpoints at `/health/readiness` and `/health/liveness`.
This commit also adds support for a `buildpacks` property in `manifest.yaml`
which will be used to set the buildpacks when a function is being built.
Signed-off-by: Lance Ball <lball@redhat.com>
* chore: bump to buildpacks v0.8.2 for all versions
This is causing me to rethink using versions in these templates, and our
overall buildpack version/release strategy. But for now, we should land
this before 0.16.0
* adds trust for any quay.io/boson builder
Signed-off-by: Lance Ball <lball@redhat.com>
* Rust templates for http/event triggers
Each template is a fully-formed actix-web application that includes a
main.rs providing the server configuration and a handler.rs showing an
example function and a few simple unit tests. A README.md provides a
bit more detail to get the user started. The events handler is similar
to the example in the old faas-rust-runtime project.
* With developer guide for Rust
* feat: add typescript templates
Bumps the faas-js-runtime dependency to 0.7.1 and Node.js buildpack dependency to v0.8.1
fix file globbing on windows
adjust eslint/prettier for windows
improve READMEs
add usage guide
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>
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
salaboy
Matej Vasek
Luke Kingland
Zbynek Roubalik
Shashank Sharma
Preetham
Markus Thömmes
Luke Kingland
Jim Crossley
Zbynek Roubalik
Kamesh Sampath