Everything Vennir does, written down.
The docs live with the code, in the repository, and every one of them is a Markdown file on GitHub. Start from what you're here to do.
Three reads to get going, whoever you are.
I want to run things
I publish products
I install and run Vennir
I want to contribute
One picture of the whole thing.
The diagram from the architecture doc. Its sources are in docs/architecture/, written by generate.py, with five more pages: the system on GKE, every kernel type, every console module, one run call by call, and the state machines.
- Catalog repositoryTeams' products: product.yaml, Dockerfile, tests. CI builds, scans, signs and releases.
- RegistryProduct images and the signed catalog-release every console pulls.
- consoleSigns people and bots in and authorizes every request. Its own Postgres.
- kernel-apiValidates and stores DAGs. Answers only the console.
- kernel-schedulerClaims ready steps, starts and watches one Job per attempt.
- Team namespacesWhere steps run, labelled vennir/team=true. Admission policies check every Job.
Grouped by who's reading.
The console guides (console/docs/) are the ones an install serves on its Docs page; the rest are in docs/ and alongside the code they describe.
No guide matches that. Try fewer words, or browse the docs on GitHub.
For someone running things
Order what other teams publish, follow a run, and wire Vennir into your pipelines.
For a catalog team publishing products
Package your automation as a product, test it, and publish it to every install that reads your catalog.
For an operator installing and running Vennir
Install it, upgrade it, back it up, and know what it enforces before you put a team on it.
For a contributor
How the pieces fit, where everything lives, and why it's built the way it is.
Found a gap, or something wrong?
The docs are kept honest by tests where they can be, and by people where they can't. Open an issue, or send a pull request with the fix.