README
¶
changeset
changeset resolves batch identity into the changes a batch contains. Current consumers include build-runner and scorer implementations and the path-overlap conflict analyzer. The merge controller loads member requests directly because its Runway payload preserves one ordered merge step per request.
Why it exists
A Batch is a thin reference entity: it carries the IDs of the requests it contains, not their changes. Decision and action extensions such as scorers, build runners, and conflict analyzers are handed that identity and resolve the granular content themselves through an injected Resolver, rather than depending on a controller to pre-resolve and pass the data in. The resolver uses the queue-scoped storage aggregate to reach the request store (to walk a batch's contained requests) and the change store (to attach provider details).
Two fidelities
Both methods operate on one batch per call:
- The raw view returns a batch's contained changes as URIs only, in request order. It performs no change-store read. Build-runner implementations use it to construct base and head inputs.
- The detailed view returns a single batch's normalized, batch-level changes: one entry per claimed URI, each carrying the provider details recorded in the change store, aggregated across every request in the batch. Because the change store returns rows for every request that ever claimed a URI, the resolver selects the row owned by the requesting request. Scorers and detail-aware conflict analyzers use this view.
Testing
A programmable in-memory fake lives in fake/: seed per-batch results and inject errors without a real store. A generated mock lives in mock/ for tests that assert on exact call expectations. Extensions that take a Resolver can be exercised against either.
Documentation
¶
Overview ¶
Package changeset resolves batch identity into the changes a batch contains. It is the single place the orchestrator walks batch -> requests -> changes, consolidating what the build and merge controllers each did privately. Decision/action extensions (scorer, buildrunner, and future detail-aware conflict analyzers) take thin identity entities and resolve their granular content through an injected Resolver instead of being handed pre-resolved data by a controller.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Resolver ¶
type Resolver interface {
// ChangesForBatch resolves a batch's contained requests into their raw
// changes (URIs only; no change-store read), in batch.Contains order. A batch
// with no requests yields an empty slice. Used by the build (base/head) and
// merge stages.
ChangesForBatch(ctx context.Context, batch entity.Batch) ([]change.Change, error)
// DetailedForBatch resolves a batch into its normalized, batch-level view:
// one entity.ChangeInfo per claimed URI (URI plus the provider details read
// from the change store), aggregated across every request in the batch. For
// each URI it selects the record owned by the request, since the change store
// returns rows for all requests that ever claimed the URI. Used by the scorer
// and detail-aware analyzers.
DetailedForBatch(ctx context.Context, batch entity.Batch) (entity.BatchChanges, error)
}
Resolver turns batch identity into the changes the batch contains. Both methods operate on a single batch — callers with several batches (a build's base, a merge train) loop and keep the per-batch boundary by holding a slice per batch. The two methods differ only in fidelity: ChangesForBatch is the cheap URI-only view; DetailedForBatch reads the change store for provider details.
Source Files
Directories