v0.9: is it in prod yet?

Kuberik v0.9 is out. The big change is where the dashboard starts: from the pull requests you merged, not from the rollouts that carry them.

Your changes, on the home page

Merged PRs are right on the home page, showing how far each one got through the environments. When one is stuck, clicking it tells you why and what it’s waiting on. No more tab-hopping to answer “is it in prod yet?”

Getting here meant a redesign, and the home page was rebuilt around it. It leads with what’s deploying right now, then what a rule is holding and what each hold waits for, then everything already on its newest build. Beside that, your changes, how the week is going, and the recent activity. Every other page was rebuilt on the same components.

One page per change

Open a change and the first thing on the page is the hold, in one sentence, with the exact version it needs and the version that’s running, and the action that unblocks it. Below that, every rollout that would receive the change, and for each service the same stage rows the rollout page draws.

A change page works for a bare commit too, and it doesn’t guess. If CI didn’t release a service for that commit, the page says so instead of inventing a status.

/changes is the same view for the whole fleet: every merged change across the repositories the cluster deploys, newest first, with a card per repository so you can see how far a week’s work got without opening a single rollout.

Waiting on another service

One of the things a change can now wait on is another service. Declare that your frontend needs a certain API version and rollout-controller v0.9 holds it in every environment until that API is actually deployed there, with full SemVer ranges. The dashboard shows the dependency, the version it needs and the version that’s running, and points you at the service that has to ship. This one has been a long time coming.

Also in the controller: a rollout’s first ever deployment no longer waits on gates and health checks that can’t have an opinion yet, status is written in a stable order so idle rollouts stop churning, and automatic deployments are attributed to the system rather than to the last person who deployed by hand.

Connecting to GitHub properly

All of this comes from GitHub, and it meant connecting to it properly. You sign in with your own account through a GitHub App, so you see only the repos you already have access to, and nothing is stored on the server. Once connected, PR titles, authors and commits show up where there used to be shas: on the changes, in the Change Version dialog with the lines each commit touched, on a rollout’s history, and in links that land on the commit.

Search follows the same idea. Paste a PR link, owner/repo#4, #4 or a sha into ⌘K and you’re on the change. Type part of a title and your own merged changes come up.

Upgrade

kubectl get crd -o name | grep -E 'kuberik\.com$' | xargs -I{} kubectl label --overwrite {} app.kubernetes.io/managed-by=Helm
kubectl get crd -o name | grep -E 'kuberik\.com$' | xargs -I{} kubectl annotate --overwrite {} meta.helm.sh/release-name=kuberik meta.helm.sh/release-namespace=kuberik-system
helm upgrade kuberik kuberik/kuberik --version 0.7.0

Chart 0.7.0 pins rollout-controller v0.9.2 and rollout-dashboard v0.9.1, and it changes how the chart treats CRDs. They are chart resources now, so helm upgrade installs the new RolloutDependency CRD and keeps every CRD current from here on. Earlier charts left them to Helm’s crds/ convention, which never upgrades a CRD, so the first two lines hand the existing ones over to the release once; use your own release name and namespace. Skip 0.6.x, which shipped the controller without the CRD it needs. Declaring a dependency is one RolloutDependency object plus an annotation on the image; see Service dependencies. Connecting GitHub is a client id and a secret on the hub; see GitHub integration.