Really? Yet another CI system?

Thing is, most existing CI systems do too much. You already have your build system, it's called yarn/go/bazel/maven/make/you-name-it. There is little need for putting another layer on top of it, certainly not one that's reasonably inscruitable outside of that particular CI system. That includes any kind of declarative business like YAML or DSLs, but also imperative ones like using Groovy or Lua.

As of late CI systems want to control your infrastructure, introducing yet another means of deploying your services, databases and containers. All this means that you end up duplicating your work, having to learn yet another custom resource definition, the kinks of yet another language.

Werft is built in the spirit of Unix and microservices where services do one thing, and they do it well. Werft executes jobs that run your build or deployment. It does not prescribe how that build ought to be structured, or make assumptions about your deployment. At its core it starts, monitors and controls Kubernetes pods, effectively turning Kubernetes into your CI system. Werft integrates well with GitHub, has a great CLI and UI, re-uses pods and Go templates (like Helm does). If you are coming from a cloud-native world, you will feel right at home.

We do not attempt to solve all the issues around building and deploying software. Instead, we let others do the great job they do - and enable you to use the software you have already in place.

Features

  • pod:
  containers:
  - name: build
    image: golang:1.13-alpine
    workingDir: /workspace
    command:
    - sh 
    - -c
    - |
      echo "[webui|PHASE] build webui"
      make webui-static
      echo "[build|PHASE] build release"
      make release

    Jobs are Pods

    A werft job is nothing but a Kubernetes pod. In that pod you can run any container, any command, any script. This means you don't have to learn yet another pipeline language and figure out how to do get your stuff done.
    Werft initializes and automatically adds a /workspace volume which contains your job context, e.g. your repo cloned from GitHub.

    One key benefit of the traditional pipeline apparoach of other CI systems is the structure it gives log output. In werft we use structured logging to recover process structure keep your job understandable.

  • Structured Logging

    Build systems produce a lot of log output which contains a lot of structure. In most CI system that structure is lost and your log degenerates to a flat text file.

    In Werft we parse the log output (log cutting) and maintain that structure on the UI. This way you can find errors quickly and get a good understanding of what's going on.

  • Results, results, results, ...

    If all things go well, your code builds, the tests pass, the deployment works, then you do not want to see your CI system. All you want then is to know about the results it produced, e.g. the npm package, the test installation or the Docker image that was just pushed.

    Werft jobs register their results through their log output. These results are shown on the job page, but can also be added to the commit status on GitHub, sent to Slack, or printed as smoke signs.

  • GitHub integration

    GitOps is a thing. When you push your code to GitHub you want things to happen, and werft is the tool that makes them happen. Much like any other CI system on this planet, werft can listen to events on your repository, trigger jobs and register the results of those jobs as commit status back to GitHub.

    Thanks to werft's results mechanism, you can tell GitHub not just that your build passed, but also the URL of that shiny new dev-environment you just deployed.

  • werft is a very simple GitHub triggered and Kubernetes powered CI system

Usage:
  werft [command]

Available Commands:
  help        Help about any command
  init        Initializes configuration for werft
  job         Interacts with currently running or previously run jobs
  run         Starts the execution of a job
  version     Prints the version of this binary

Flags:
  -h, --help          help for werft
      --host string   werft host to talk to (defaults to WERFT_HOST env var) (default "localhost:7777")
      --verbose       en/disable verbose logging

Use "werft [command] --help" for more information about a command.

    Excellent Command-Line Integration

    CI is not all Git. Sometimes you want to start a job for a branch without having to commit that job, for example while setting things up. Maybe you want to integrate your CI system into your terminal, e.g. see the log output of the job started by your latest commit.

    Werft sports a CLI that supports those use-cases. Everything you can do on the UI, you also do on the CLI (and then some).

  • plugins:
  - name: "example"
    type:
    - integration
    config:
      emoji: 🚀

    Extensible Plugin System

    There are a lot of things that werft cannot do out-of-the-box; and that's intentional. Werft is the counter proposal to feature-laden and complicated systems. However, that does not mean that werft cannot do those things.

    Werft sports a plugin system based on gRPC. Those plugins can provide integration with other code-hosting platforms, add additional notifications or add a different logging format.

Getting started

# Werft runs on Kubernetes and installs using Helm:
helm repo add ...
helm install werft

# Next, get ahold of the werft CLI and create a job in your repo using
curl https://werft.dev/get-cli.sh | sh
werft init job hello-world

# Run that job using the werft CLI
werft run local -j .werft/hello-world.yaml