v0.8.0

Three components ship in this release: rollout-controller v0.8.0, rollout-dashboard v0.8.0, and openkruise-controller v0.4.0.

rollout-dashboard v0.8.0

The dashboard has been substantially reworked since v0.7.7.

Multi-cluster support. A hub dashboard now fans out to spoke dashboards running in remote clusters. All rollouts across all registered clusters are visible from a single URL. Spoke dashboards handle their own cluster’s API calls; the hub aggregates.

OIDC authentication. The dashboard integrates with oauth2-proxy’s extAuth mode. Traffic goes through an authenticating proxy and the dashboard receives the verified identity.

Applications view. A new /apps page groups rollouts into logical applications and shows fleet-wide status at a glance. Drill into an application and you get a version lifecycle Gantt showing when each version was active across environments, with range presets (24h / 7d / 30d / all).

Environments view. /envs shows all environments as stacked sections, each listing every rollout and its current state. Drills down to a per-environment activity timeline.

Activity feed. /activity is a chronological deployment timeline across the whole fleet, filterable by environment, application, and status.

Command palette. ⌘K / Ctrl+K opens a command palette for jumping to any rollout, application, environment, or namespace. It is wired site-wide and visible from every page.

Rollout overview redesign. The main rollout view is the most-used page in the dashboard and it got a full overhaul. The deployment pipeline card shows each canary step with test results inline. Current version, bake status, and stuck detection sit at the top. Resources (pods, replicasets) and schedule status are surfaced without leaving the page. When the controller is holding a deployment after a failed health check, a warning banner appears with the option to retry or skip the failed step.

Datadog APM links. Tests that emit a trace ID get a direct link to the Datadog APM trace viewer next to the existing Logs and CI buttons.

rollout-controller v0.8.0

Retry modes. Setting the rollout.kuberik.com/retry annotation now accepts a mode value: retry re-runs the failed step, skip advances past it. Previously only retry was supported.

New conditions. Two new conditions are set on rollouts in blocked states:

• BakeFailureDisabled — set when bake failure detection has been explicitly disabled.
• DeploymentBlocked — set when a deployment cannot proceed due to a gate or schedule constraint.

Better failure detection. The controller now prefers Stalled=True as the primary failure witness when evaluating health check conditions, falling back to the newest condition only when Stalled is absent. This reduces false negatives when a check briefly reports healthy before settling into a failed state.

Health status messages. Status messages are enriched with more context. Bake time is now measured correctly in edge cases.

Kustomization health fix. Resources that no longer exist are skipped during kustomization health evaluation rather than returning an error that blocked the reconciliation loop.

Manual deployment requeue. Manual deployments where bakeStatus is Deploying are now requeued correctly instead of being left waiting for an external event.

openkruise-controller v0.4.0

Robust retries. The retry mechanism has been rewritten to handle edge cases that caused the controller to get stuck. Retry side-effects are now applied unconditionally at the start of a retry cycle, and step-ready-at timestamps are preserved so bake time is measured from the right point.

Additional fixes in this release:

• Bake time is now respected when a rollout step has no tests.
• Test creation is blocked and running jobs are cancelled when KuberikBakeHealthy=False is set.
• The same-second failure edge case in stalledBefore is treated correctly as a pre-retry state.
• The timeout machinery is skipped entirely when a rollout step is already Healthy or Completed, preventing spurious requeues.
• Jobs are deleted asynchronously to avoid blocking the reconciliation loop.
• A RolloutTest can no longer be cancelled after the rollout has already continued past its step.