bytey

The smallest seanfarm-piped C program. It prints nom.

bytey is an instrument, not a product. Its payload is the smallest a real project can have. As a result, the wall-clock time of a full push → CI → merge → release → deploy pass is almost entirely pipeline overhead. A release is a commit tag only. It has no packages and no images. Each release goes to a marker target. The adapter writes the exact released revision to one ConfigMap slot. It then reads the revision back on its own. Binjovi keeps the Build, Release, Deployment, and release request in PostgreSQL. This makes bytey the smallest real observable target change in the system.

• CI: ci.Dockerfile compiles bytey.c and checks that the output is nom.
• Merge: open a normal Forgejo pull request. Rebase-update it if trunk moves. Then do a fast-forward-only merge of the exact green head.
• Release: an authenticated Binjovi release request creates the next vX.Y.Z commit tag and Forgejo release for the exact green Build.
• Deploy: Binjovi writes the released SHA to bytey-floorplan and reads it back before it records a successful Deployment.

Every pipeline pass through this repo is a measurement. It records separate Build, Release, and no-op Deploy times, plus the full time from Build acceptance to deployment verification. This time is the delivery system's floor. The record grows with each run.

Run 3 measures the transaction release path. The path has no rebuild and no settle window. Only one publish pod runs between the approval decision and the signed no-op deploy.

Run 3b: the corrected transaction path. The build watch wakes the gate. The push is a fast-forward push with connected history.

Run 3c.

Run 4.

Run 5.

Run 6.

Run 7.

Run 8: fast-forward.

Run 9.

Run 10.

Run 11.

Run 12.

Run 13: provider-native pull request, exact fast-forward merge, transaction release, and marker write and read-back. This is the first end-to-end measurement of the replacement control plane. It does not use the legacy merge workflow.

Run 14: repeated provider-native speed-floor sample.

Run 15: repeated provider-native speed-floor sample.

Run 16: repeated provider-native speed-floor sample.

Run 17: repeated provider-native speed-floor sample.

Run 18: repeated provider-native speed-floor sample.

Run 19: repeated provider-native speed-floor sample.

Run 20: speed-floor sample after removal of the dry run.

Run 21: control-plane floor sample after the move to batched Argo.

Run 22: first car through the release merge train. The Release act merges this change, not the provider: pipectl release bytey --change N.

Run 23: repeated end-to-end release-train floor sample.

Run 24: release-train floor sample observed by the PostgreSQL-backed Binjovi dashboard. Binjovi records the commit, immutable release, and verified no-op deployment without using Kubernetes CRDs as its durable state model.

Run 25: sample the separate Binjovi Build, Release, and Deploy phase times.

Run 26: prove event-driven Binjovi pull-request CI, exact-head supersession, and the complete delivery-path measurement.

Run 27: prove the authoritative Binjovi release path. One authenticated release command selects this exact green pull-request Build, fast-forwards trunk and main, publishes the next semver patch release, and verifies the Bytey marker read-back. The dashboard records separate Build, Release, Deploy, and full-delivery times for the same immutable revision.

Run 28: measure the clean Binjovi-only path after Pipelines retirement. binjovi/ci is the sole required pull-request check. Binjovi performs the release and marker read-back without a PipelineProject, PipelineRelease, or PipelineDeploy.