Skip to content

refactor(entity): promote Change + ChangeID to shared entity/change#240

Merged
behinddwalls merged 1 commit into
mainfrom
entity-cross-domain-analysis
Jun 12, 2026
Merged

refactor(entity): promote Change + ChangeID to shared entity/change#240
behinddwalls merged 1 commit into
mainfrom
entity-cross-domain-analysis

Conversation

@behinddwalls

@behinddwalls behinddwalls commented Jun 12, 2026

Copy link
Copy Markdown
Collaborator

Summary

Why?

Change (a code change identified by provider URIs) and the GitHub/Phabricator ChangeID parsers are pure identity-and-parsing types with no domain semantics and no persisted-as-shared schema. They are the one cluster genuinely common to every code-change pipeline — SubmitQueue today, and Stovepipe / Runway / Tango alignment going forward — so they belong in the shared top-level entity/ tree rather than inside submitqueue/entity/.

This is deliberately the only promotion: facts a domain persists (the change-provider model embedded in ChangeRecord), state machines, and pipeline types stay domain-local, since sharing them would couple every domain's storage schema and bend their state machines toward SubmitQueue's.

What?

Moves the canonical Change struct out of submitqueue/entity/request.go into a new entity/change package, and relocates the parser packages to entity/change/github and entity/change/phabricator (preserving git history). No alias shim: every consumer now references change.Change and imports the new path directly. JSON tags are unchanged, so queue payloads (Request, LandRequest, PushResult) remain byte-identical across a deploy.

submitqueue/entity keeps its full pipeline and facts; Request, LandRequest, and ChangeOutcome now embed change.Change.

Test Plan

  • make build
  • make test (51/51 pass)
  • make fmt / make gazelle (converged, no further changes)
  • make check-tidy (go.mod / MODULE.bazel unchanged — internal move, no new deps)

## Summary

### Why?

`Change` (a code change identified by provider URIs) and the GitHub/Phabricator `ChangeID` parsers are pure identity-and-parsing types with no domain semantics and no persisted-as-shared schema. They are the one cluster genuinely common to every code-change pipeline — SubmitQueue today, and Stovepipe / Runway / Tango alignment going forward — so they belong in the shared top-level `entity/` tree rather than inside `submitqueue/entity/`.

This is deliberately the *only* promotion: facts a domain persists (the change-provider model embedded in `ChangeRecord`), state machines, and pipeline types stay domain-local, since sharing them would couple every domain's storage schema and bend their state machines toward SubmitQueue's.

### What?

Moves the canonical `Change` struct out of `submitqueue/entity/request.go` into a new `entity/change` package, and relocates the parser packages to `entity/change/github` and `entity/change/phabricator` (preserving git history). No alias shim: every consumer now references `change.Change` and imports the new path directly. JSON tags are unchanged, so queue payloads (`Request`, `LandRequest`, `PushResult`) remain byte-identical across a deploy.

`submitqueue/entity` keeps its full pipeline and facts; `Request`, `LandRequest`, and `ChangeOutcome` now embed `change.Change`.

## Test Plan

- ✅ `make build`
- ✅ `make test` (51/51 pass)
- ✅ `make fmt` / `make gazelle` (converged, no further changes)
- ✅ `make check-tidy` (go.mod / MODULE.bazel unchanged — internal move, no new deps)
@behinddwalls behinddwalls marked this pull request as ready for review June 12, 2026 17:08
@behinddwalls behinddwalls requested review from a team and sbalabanov as code owners June 12, 2026 17:08
Comment thread entity/change/change.go
@behinddwalls behinddwalls enabled auto-merge June 12, 2026 20:17
@behinddwalls behinddwalls added this pull request to the merge queue Jun 12, 2026
Merged via the queue into main with commit 3e75dd9 Jun 12, 2026
27 checks passed
@behinddwalls behinddwalls deleted the entity-cross-domain-analysis branch June 12, 2026 20:23
@behinddwalls behinddwalls deployed to stack-rebase June 12, 2026 20:23 — with GitHub Actions Active
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants