Skip to content

Share benchmark execution and preserve reviewed evidence - #25

Merged
gauravtiwari merged 18 commits into
mainfrom
benchmark-workload-selection
Oct 4, 2026
Merged

gauravtiwari merged 18 commits into
mainfrom
benchmark-workload-selection

Conversation

@gauravtiwari

@gauravtiwari gauravtiwari commented Oct 3, 2026 •

Copy link
Copy Markdown
Contributor

Benchmark cases now select reviewed workloads through shared execution, provider setup, timing, output verification, and reporting. The common Docker action controls cache publication for both providers: cold publishes, ordinary warm replay restores, and explicitly declared warm publication applies to both arms. Case actions retain upstream preparation, recipe inputs, and correctness checks. Roughly 600 lines of repeated Docker lifecycle code are removed.

PostHog's missing native warm scope and inspection inside the build timer are fixed. The common scope helper preserves series continuity and legacy cold-scope handoff. Hugo's loaded-image projection disables incompatible attestations in both providers. Regressions execute scope selection and the phase-policy CLI, verify every image inspection is outside timing, and check that the product contract sees the correct adapters and literal trust policies.

The sole One release pin remains in the provider wrapper. A small JavaScript GitHub post hook uploads the original product evidence after One's cleanup, using the official artifact SDK; Ruby owns the harness and reports. Missing evidence fails retention. Dependencies install outside timing and are excluded from case digests and prepared-source copies; their lockfile is included. The existing product pin-sync path still finds the wrapper pin.

bin/bench collect imports original phase artifacts from a verified export matched to its dispatch receipt, rejects conflicting observations, checks workflow/job/post-step completion, and generates the report. It can resume an identical import. Reports and the catalog retain failed, incomplete, unfavorable, and methodologically invalid observations. Documentation describes the complete case, series, collection, and review process.

Six previously completed Docker requests are imported and independently archived: PostHog layers/combined, Hugo, Mastodon streaming, and n8n runners/distroless. Plan-bound methodology reviews now mark all affected earlier Docker series invalid for comparative claims because Actions Cache exported warm state while BoringCache restored without publishing. Their original measurements remain unchanged. The six published bundles were downloaded again, checked against SHA-256, extracted, and verified against 78 listed files with no scoped gaps. Older output failures, cancelled requests, Deno native errors, and unmeasured storage remain visible.

Canary monitoring follows each active historical schedule until its explicit cutover. A read-only collection verified 16 dispatch receipts and 17 child runs on October 4. Missing, stale, or failed canaries still fail monitoring. Imported case definitions do not imply an active central schedule.

Validation: Ruby tests, Node evidence-retention regression, 68 case definitions, 22 publication entries, 62 report workflow contracts, 70 execution views, product cache-interface checks, and Actionlint pass. Hugo Go and corrected Hugo Docker completed cold/warm execution and retained final product evidence after cleanup. Five completed requests, including three failures before build, were independently archived and verified against 53 listed files. Their interpretations retain slower BoringCache warm results and unmeasured Actions Cache storage. Initial Docker lifecycle requests exposed an output-name mismatch before build; those failures are preserved. Separate signed correction plans rerun Hugo and both PostHog variants. Both corrected PostHog variants now pass cold/warm output and completion checks. Their added archives were independently downloaded and verified against 30 listed files, bringing the shared-lifecycle release to seven exports and 83 verified files. The selected Docker-tag storage in the combined profile is not presented as total tool-cache storage; identical-source replay does not isolate tool-cache benefit.

Remaining consolidation gates are explicit: qualify the other active variants and rolling seed lineage, switch schedules/source-sync/release callers, resolve shared GitHub cache capacity, verify the central reporting feed and reviewed website claims, and audit selected fork evidence before retirement. Original repositories remain active. This PR does not establish complete migration, publication approval, or permission to delete repositories.

@gauravtiwari gauravtiwari changed the title Select workloads through the shared benchmark workflow Share benchmark execution and preserve reviewed evidence Oct 4, 2026
@gauravtiwari
gauravtiwari marked this pull request as ready for review October 4, 2026 16:38
@gauravtiwari
gauravtiwari merged commit 16d130b into main Oct 4, 2026
10 checks passed
@gauravtiwari
gauravtiwari deleted the benchmark-workload-selection branch October 4, 2026 16:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant