Project

kipp

A job-first CI and scheduler in a single binary: jobs as YAML files, stages as a DAG, builds from GitHub pushes and pull requests, about 50 MB resident.

Active Go MIT Source v1.0.0
brew install ndthuan/tap/kipp

kipp runs scheduled jobs and CI builds from one Go binary with its web UI embedded and SQLite for state. It sits between cron, which runs things but keeps no history, and Jenkins, which keeps everything and costs gigabytes of memory to do it.

What it does

  • Jobs as files. One YAML file per job in a directory, checked offline with kipp check and loaded again on kipp reload. A directory with one bad file is refused whole, so the server keeps the jobs it had.
  • Triggers. Cron with Jenkins' H and a time zone per job, GitHub webhooks on a push or a tag, a run after another job, and runs by hand with typed parameters.
  • Stages. A DAG with needs, when conditions, retries, locks and timeouts.
  • Repos. Multibranch jobs and organization folders that build every branch and pull request from a .kipp.yml in the repo, with commit statuses.
  • Where builds run. On the server, on agents that dial in, or in containers on Docker engines, chosen by label.
  • Results. Live logs, JUnit results, artifacts, a keyed cache, and secrets sealed in the database and masked as *** in every log.

A job

1
2
3
4
5
6
7
8

name: nightly-backup
triggers:
  cron: "H 3 * * *"
timeout: 1h
secrets: [BACKUP_KEY]
stages:
  dump:   {run: ./backup/dump.sh}
  upload: {needs: [dump], run: ./backup/upload.sh, retries: 2}

When it fits

kipp is built for your own machines and your own repos. It has no plugin system and no matrix syntax, and a pull request build runs with the job's secrets on the machine that runs it, which is a fine trade for private repos and the wrong one for a public project that takes outside contributions.

The README has the quick start, and the releases page has archives for Linux and macOS with checksums and build provenance.

Writing about kipp