Skip to content

v0.7.0

Choose a tag to compare

@github-actions github-actions released this 28 Sep 00:18
· 93 commits to main since this release
6ce064e

Rio v0.7.0

One rio invocation runs the pipeline in rio.yaml and produces one compact receipt.

rio

Actual generated example, using synthetic SBOMs, a local HTTPS receiver and synthetic tokens. This is a readable excerpt; digests are shortened here only:

Consumed → enriched → delivered → acknowledged

api.cdx.json     1d2b04c0df45… → 55e46a63a8b3…  (2307 output bytes)
worker.cdx.json  721bd8311e64… → 085265392b20…  (2316 output bytes)

Added to both: build.url = https://ci.example.org/runs/42
               build.id  = 42
Destination:   https://127.0.0.1:53946
Projects:      api / 1.0.0, worker / 1.0.0
TLS:           observed; certificate verification enforced

api:     HTTP 200, accepted; token 11111111-1111-4111-8111-111111111111
worker:  HTTP 200, accepted; token 22222222-2222-4222-8222-222222222222

Complete generated JSON (5,791 bytes) · Offline HTML · Complete runnable download · Quick start

The URL is the destination server, not a product website. Your receipt records your configured instance and projects. HTTP acceptance is not proof of ingestion.

Pipeline and receipt

  • Bare rio consumes selected SBOMs, normalizes/enriches them, checks schema/quality, and delivers to configured targets without another command or confirmation.
  • Each invocation owns a fresh run directory and one indented rio-run-receipt, schema version 1. Exact meaningful metadata changes and summarized bulk counts replace the old duplicated source bundle. The two-SBOM example is below the 8 KiB regression budget without compression or shortened stored digests.
  • Receipts identify actual input/output bytes, intended versus observed complete body writes, destination projects, TLS policy/observations, HTTP responses and allowlisted receiver references. OCI config and manifest representations have their own identities; already-present content is not called a new upload.
  • rio plan previews effective flags/manifest settings and routing offline, preserving the transform-description seam used by supporting tools.

Failure and recovery

The root gate defaults to fail. An explicit warn policy is recorded and does not conceal failed checks. Current intake failures block delivery of stale outputs. Partial runs distinguish acceptance, rejection, unknown responses and unattempted work; missing journal evidence is not proof of no request.

Receipt paths are reserved before uploads and never overwritten. Durable checkpoints and internal journals support rio record recover --run DIR --output NEW.json without replaying uploads or breaking crash-held locks. An interrupted run stays incomplete. Explicit retries and reconciliations have new receipts and prior-attempt references; earlier public receipts remain unchanged.

rio normalize and rio deliver still support deliberate separate stages, each honestly scoped to its own invocation. Normalization remains offline. Standalone normalization retains its warn default when neither the manifest nor flags select a gate mode; root execution defaults to fail.

Client contract change

The v0.6 client bundle formats, rio record collection flags and rio deliver --evidence are removed. Use each invocation's automatic receipt. Old bundle formats fail clearly; there is no compatibility or diagnostic-bundle export mode.

record inspect validates structure, references and internal consistency. record report produces standalone escaped HTML with the original JSON digest. Both work without source files or network access. These are unsigned assertions/observations, not authenticated provenance or proof of receiver retention.

Command reference · Receipt contract and bounds · Installed-binary demos