Skip to main content
T4 epic · devops / release engineering: time is a first-class citizen. The train holds with nika:wait until: (an absolute timestamp, not a sleep), the gates’ duration is computed with nika:date op: diff, a human signs the departure, and the record lands in the journal whether the ship success or not.

The job

Release day choreography: tests, lint and audit run as one parallel wave; an assert refuses departure on any red; the conductor signs with full information (« gates GREEN in 12 min · ship 1.4.0 in the 09:00Z window? »); the train holds until the window; ships; re-polls prod until it reports the new version; and on_finally files the departure record either way.

The shape

The file

release-train.nika.yaml

How it works

1

until: is a hold, not a sleep

nika:wait with until: 2026-07-28T09:00:00Z parks the train at an ABSOLUTE time (capped by timeout: 48h). A relative duration: would drift with however long the gates took.
2

The human signs with full information

nika:date op: diff computes the gates’ wall time, and the nika:prompt message carries it: the conductor decides knowing how fresh the green is. The assert after makes « no » terminal.
3

The record always lands

verify re-polls prod (retry × 5, exponential) until it reports the shipped version · the final assert refuses to claim success otherwise · on_finally emits the journal event + team ping with the REAL status, even on failure.

Constructs you just used

Make it yours

  • Generate the notes on the same train: insert Release notes between approved and hold.
  • Canary first: duplicate ship/verify against staging, gate prod behind a second assert.
  • The config.window dial makes this a scheduled artifact: your cron passes next Tuesday 09:00Z, the train handles the rest.

Back to all examples

The full gallery: four tiers, every construct taught by a real job.