When a product CI workflow dispatches a dev image build, bakery discovers the current dev version from the upstream CDN at matrix-generation time. The CDN upload is asynchronous, so during the propagation window bakery can resolve the previous build while the dispatch targets a newer one. The result is a silently wrong image: the download uses the stale artifact but the image is tagged with the dispatched version.
This issue tracks adding a typed JSON dispatch payload (--dev-spec / BAKERY_DEV_SPEC) that lets a dispatch pin the version exactly, bypassing CDN discovery:
bakery build --dev-spec '{"version": "2026.05.0-dev+185-gSHA", "channel": "daily"}'Design decisions
- Applied at
BakeryConfig.load() before resolution, scoped to the dispatched channel, with an ambiguity guard (raises if multiple stream dev versions match and no channel disambiguates)
- PPM (template streams): URL rendered offline from the pinned version — no network fetch
- Connect / Workbench (manifest streams): fetch the manifest, assert version matches, raise loudly on mismatch (
DispatchVersionMismatchError) instead of silently building stale
- Inert on non-dispatch runs (scheduled, PR, production, local) when
BAKERY_DEV_SPEC is unset
- Payload is extensible: future fields (
sha, build_number, branch) are additive-only, with zero workflow or bakery.yaml churn per addition
Sequencing
- Phase 0: Remove dormant
env dev-version source type (prerequisite cleanup)
- Phase 0.5a: Rename
stream → channel in bakery internals and CLI (--dev-stream → --dev-channel), with backward-compat shim in shared workflows so product repos need no changes during implementation
- Phase 1: Implement
--dev-spec / DevBuildSpec / shared workflow wiring
- Per-repo follow-up: Each product repo makes one PR switching to
channel naming and wiring dev-spec on dispatch
Closes #527
Follow-up PRs
When a product CI workflow dispatches a dev image build, bakery discovers the current dev version from the upstream CDN at matrix-generation time. The CDN upload is asynchronous, so during the propagation window bakery can resolve the previous build while the dispatch targets a newer one. The result is a silently wrong image: the download uses the stale artifact but the image is tagged with the dispatched version.
This issue tracks adding a typed JSON dispatch payload (
--dev-spec/BAKERY_DEV_SPEC) that lets a dispatch pin the version exactly, bypassing CDN discovery:bakery build --dev-spec '{"version": "2026.05.0-dev+185-gSHA", "channel": "daily"}'Design decisions
BakeryConfig.load()before resolution, scoped to the dispatched channel, with an ambiguity guard (raises if multiple stream dev versions match and no channel disambiguates)DispatchVersionMismatchError) instead of silently building staleBAKERY_DEV_SPECis unsetsha,build_number,branch) are additive-only, with zero workflow orbakery.yamlchurn per additionSequencing
envdev-version source type (prerequisite cleanup)stream→channelin bakery internals and CLI (--dev-stream→--dev-channel), with backward-compat shim in shared workflows so product repos need no changes during implementation--dev-spec/DevBuildSpec/ shared workflow wiringchannelnaming and wiringdev-specon dispatchCloses #527
Follow-up PRs