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.

A Release can contain more than one pull-request Build. Each Build proves its change in isolation. The combined trunk Build proves that the selected changes work together before Binjovi publishes one Release and starts one Deploy.

• CI: ci.Dockerfile compiles bytey.c and checks that the output is nom.
• Merge: open a normal Forgejo pull request and wait for its exact-head Build to pass. The Release act serializes each selected change onto trunk.
• Release: an authenticated Binjovi release request can select one or more green Builds. Binjovi tests their combined trunk revision once, then creates the next vX.Y.Z commit tag and Forgejo release for that exact revision.
• 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.

Run 29: prove that Binjovi runs the Build as an archived Argo Workflow before the release train tests the combined trunk revision.

Native CI

Binjovi builds pull requests with the recipe in sean/binjovi-plans:recipes/bytey/. The active plan fixes the recipe revision for each build. Recipe changes use a plans pull request and release; they do not require a Binjovi runtime deployment.

Bytey has no Pipelines shadow path. The native Binjovi Build is the only admission authority for this repository.

Native pipeline timing

Native validation checks the control-floor source. Deployment verifies the released revision in configmap/workflows/bytey-floorplan.

Open the project dashboard and expand an execution attempt for the task timeline and available CPU, off-CPU, and syscall profiles. Cached BuildKit steps still appear as cached work; a missing sample does not prove that a task used no CPU.

Select an exact successful Build with binjovictl release bytey --build BUILD_ID --wait. Then use binjovictl status bytey to check its release and any configured deployment. Telemetry explains time spent; immutable artifact and revision evidence establish completion.

ARM canary

Bytey is the first project on the dedicated native ARM executor lane. The plan recipe checks aarch64, compiles the C program, and checks that its output is nom. Binjovi records BuildKit steps and available process profiles on the ARM worker. Release still creates a Git tag; Deploy writes and independently reads the revision in bytey-floorplan.