Controllers for riff CRDs
riff System contains three API groups with CustomResourceDefinitions that are the public API for riff.
Application- applications built from source using application buildpacks
Function- functions built from source using function buildpacks
Container- watch a container repository for the latest image
Deployer- deployers map HTTP requests to applications, functions, containers or images with Kubernetes core resources
Provider- an abstraction over a message broker
Stream- streams of messages
Processor- processors apply functions to messages on streams
Adapter- adapters map applications, functions or container images into an existing Knative Service or Configuration.
Deployer- deployers map HTTP requests to applications, functions, containers or images with Knative
webhook Deployments exist in the
riff-system namespace to validate and reconcile the riff CRDs.
Two ClusterRoles are defined to grant access to the riff CRDs.
projectriff- read/write access to all riff CRDs
projectriff-readonly- read access to all riff CRDs
These roles are aggregated to the
view ClusterRoles respectively.
See the Kuberneties Using RBAC Authorization for more information.
riff System is not installed directly for typical use. See the Getting Started docs to learn how to install riff.
After making any changes to source files in
./pkgs/apis it is necessary to regenerate the API client by running:
Dependencies are managed with dep. After importing a new package or modifying Gopkg.toml, run:
To run the unit tests locally:
go test ./...
To deploy to a development cluster with ko:
ko apply -f config/
Additional dependencies must be installed independently into the cluster including:
- riff build templates
- Knative Build
- Knative Serving
A common practice is to start with a standard riff install and then incrementally update riff System from source.
Releases are generated by the CI server by running
./hack/release.sh, and published to:
Code of Conduct
Please refer to the Contributor Code of Conduct.