This can be useful on machines where libgit2 is installed due to other applications depending on it, but where the composition of this installation does not properly work with the controller. Reason the system version is still preferred, is because this lowers the barrier for drive-by contributors, as a working set of (Git) dependencies should only really be required if you are going to perform work in that domain. Signed-off-by: Hidde Beydals <hello@hidde.co> |
||
---|---|---|
.github | ||
api | ||
config | ||
controllers | ||
docs | ||
hack | ||
internal | ||
pkg | ||
.dockerignore | ||
.gitignore | ||
CHANGELOG.md | ||
CODE_OF_CONDUCT.md | ||
CONTRIBUTING.md | ||
DCO | ||
Dockerfile | ||
LICENSE | ||
MAINTAINERS | ||
Makefile | ||
PROJECT | ||
README.md | ||
go.mod | ||
go.sum | ||
main.go |
README.md
Source controller
The source-controller is a Kubernetes operator, specialised in artifacts acquisition from external sources such as Git, Helm repositories and S3 buckets. The source-controller implements the source.toolkit.fluxcd.io API and is a core component of the GitOps toolkit.
Features:
- authenticates to sources (SSH, user/password, API token)
- validates source authenticity (PGP)
- detects source changes based on update policies (semver)
- fetches resources on-demand and on-a-schedule
- packages the fetched resources into a well-known format (tar.gz, yaml)
- makes the artifacts addressable by their source identifier (sha, version, ts)
- makes the artifacts available in-cluster to interested 3rd parties
- notifies interested 3rd parties of source changes and availability (status conditions, events, hooks)
- reacts to Git push and Helm chart upload events (via notification-controller)