README
¶
changeset
changeset resolves batch identity into the changes a batch contains. It is the single place the orchestrator walks batch → requests → changes, consolidating the resolution the build and merge controllers each performed privately.
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 (the scorer, build runner, pusher, and future detail-aware 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 depends only on the two resolution-target stores — the request store (to walk a batch's contained requests) and the change store (to attach provider details) — and nothing else.
Two fidelities
The resolver offers the same walk at two levels of detail, and both preserve batch boundaries — neither flattens across batches, so a caller that wants a flat list flattens the result itself:
- The raw view returns each batch's contained changes as URIs only, one group per input batch, in input order. It performs no change-store read. The build stage uses it for base and head inputs; the merge stage uses it for the pusher.
- 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. The scorer uses it, as will any analyzer that needs changed-file or line-count facts.
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