From d42bddac9007eb1ad27f9a6261dbeb675b624b3a Mon Sep 17 00:00:00 2001 From: Stuart Axelbrooke Date: Wed, 19 Nov 2025 17:39:02 -0800 Subject: [PATCH] add thoughts on getting to v2 e2e running --- databuild/databuild.proto | 4 ++-- docs/impl_notes/2025-11-19_running-jobs.md | 17 +++++++++++++++++ 2 files changed, 19 insertions(+), 2 deletions(-) create mode 100644 docs/impl_notes/2025-11-19_running-jobs.md diff --git a/databuild/databuild.proto b/databuild/databuild.proto index da63a8b..076b87b 100644 --- a/databuild/databuild.proto +++ b/databuild/databuild.proto @@ -16,7 +16,7 @@ message JobConfig { repeated string partition_patterns = 4; // TODO future fields to consider // - timeout - // - + // - } @@ -217,7 +217,7 @@ message PartitionStatus { string name = 2; } enum PartitionStatusCode { - // TODO how do we avoid copying job states here? + // TODO how do we avoid copying job states here? This is essentially a union of job states and taints? PartitionUnknown = 0; PartitionWanted = 1; PartitionBuilding = 2; diff --git a/docs/impl_notes/2025-11-19_running-jobs.md b/docs/impl_notes/2025-11-19_running-jobs.md new file mode 100644 index 0000000..22f32fc --- /dev/null +++ b/docs/impl_notes/2025-11-19_running-jobs.md @@ -0,0 +1,17 @@ + +We've gotten to a place where the orchestrator reacts to wants, runs jobs, and turns dep misses into other wants, which in theory is all we need from it to get to v2. So, what do we need around that? + +- Job configuration +- Want submission - more generally, the API + +How do those break down into work items? + +### Job Configuration +The databuild binary should accept a runtime config that points to a job config file, or just provides it directly, which populates the [`JobConfigurations`](databuild/orchestrator.rs:99). This should be fairly straightforward, and can probably just be deserialization of the read string via [the protobuf struct](databuild/databuild.proto:8). + +### API +We have the (beginnings of) API endpoints described in protobuf structs ([starting here](databuild/databuild.proto:174)). We just need to build an API server around it, and a CLI that can talk to the API. This would break down into the following layers: + +- Build state accessor functions - transact via the protobuf structs +- API - exposes build state accessor functions via HTTP +- CLI - Talks to API, formats requests/responses, is able to start API server for databuild workspace