You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
refactor(extensions): per-queue Factory; drop queue from method signatures
## Summary
### Why?
Behavioral extensions were global singletons frozen at process start, and two
leaked the queue into vendor-agnostic method signatures (mergechecker.Check,
buildrunner.Trigger). Each extension should instead be produced by a Factory
the controller asks for using the queue, identified only by name, so an
implementation can be selected/configured per queue.
### What?
- Reduce entity.QueueConfig to {Name} (the registry of valid queues); all
behavioral/VCS config moves into the factory implementations.
- Each extension (changeprovider, pusher, scorer, conflict, mergechecker,
buildrunner) ships a narrow Config{QueueName} and a Factory interface
(For(cfg) (T, error)); concrete factories are written by integrators in the
example wiring and tests. Generated mocks updated.
- Drop the queue argument from mergechecker.Check(ctx, change) and
buildrunner.Trigger(ctx, base, head, metadata); delete mergechecker
MultiChecker. Status/Cancel stay buildID-keyed.
- Add storage.Factory (default mysql) and thread it into every controller; the
gateway land controller resolves For(req.Queue) — the one place per-queue
storage routing is actionable. Orchestrator controllers carry a
TODO(queue-aware) to derive the queue from the loaded entity for
logging/metrics/storage.
- Controllers resolve each extension from its Factory using the loaded entity's
queue; buildsignal fetches the batch before polling Status. Example servers
wire concrete static factory structs.
## Test Plan
✅ make build, make test (40 pass)
✅ make fmt / lint / check-gazelle / check-tidy / check-mocks
0 commit comments