Skip to main content

v2.87.0

Binaries and the merged-pull-request list are on the GitHub releases page.

A bootstrap's first pull request spent most of its time before the pull request even opened: registering the epic, its milestones and its tasks, and minting the product's secrets. Each of those steps is a handful of round trips to Orunbase, made one after another from the build box. This release makes fewer of them, runs the ones that can overlap side by side, and merges a landing sooner once its checks are green.

Several secrets in one hook, minted side by side​

orun.integrations/reconcile@v1 takes a new form, secrets, a list of {key, template}:

- id: secrets
  uses: orun.integrations/reconcile@v1
  with:
    provider: cloudflare
    secrets:
      - { key: CLOUDFLARE_API_TOKEN, template: workers-deploy }
      - { key: CLOUDFLARE_D1_TOKEN, template: d1-edit }
      - { key: CLOUDFLARE_ACCOUNT_ID, template: account-id }

keys + template take one template per hook, so a product that needs a deploy token, a database token and its account id wrote three hooks, and each read the connections and the existing secrets again before its create. With secrets, the connections and the existing secrets are read once and the missing keys are created at the same time. Keys that exist are kept, as before. When one create is refused, the others still land, the hook fails naming the key, and a re-run keeps what was made.

A hook takes secrets or keys with template, never both. keys + template work exactly as before, and several keys are now created side by side too.

The run remembers what it already asked​

One build is one orun process, and its hooks asked the platform the same questions again and again. A bootstrap's preInstantiate list — the epic, one milestone per phase, one task per landing — read the epic once per milestone and per task, listed the epic's tasks once per task, and each phase's own pre hook listed them again and re-attached a contract the run had just attached. A secrets hook read the connections and the secrets that the hook before it had just read.

orun.task/ensure@v1 and orun.integrations/reconcile@v1 now keep those answers for the run: a repeated read is answered from what the run already knows, each write still goes to Orunbase and updates the remembered answer, and a contract this run attached to a task is not sent again. Answers are kept for five minutes, so a long-lived process never serves an old one, and a remembered "not connected" is read again before a hook waits on it. The memo changes how often a hook asks, never what it decides. A two-phase bootstrap's task bookkeeping goes from 15 round trips to 9, with no change to the blueprint.

A landing merges within seconds of its checks​

orun.pr/land@v1 read its pull request's checks every 15 s, so the merge came up to 15 s after the last check went green. It now reads every 5 s for the first three minutes of a wait (and again after a re-run of failed jobs), then every 15 s, so a long CI wait costs no more GitHub requests than it did.