-
-
Notifications
You must be signed in to change notification settings - Fork 23
Change Requests #70
Comments
(i had already started on some work on this, so will continue that) |
Might be worth rethinking the complexity of source with this.. The way its designed is good to be able to just abstracting view any 'source' and all associated data, but really the questions we want to ask are:
If we keep source, it likely needs to look like: Build -> Source -> {Revision, ChangeRequest, ...} That likely means source should change to use a 'source object type' and 'source object id' construct. The tricky bit is revision's dont have a GUID associated with them, but we could fix that. Alternatively we'd have to make 'source object id' be an abstract string field, which isn't great. |
Ok going Source -> ChangeRequest, as a PR/CR can have many sources over time and we'd want to track them uniformly. |
Still working on this. Plan right now is:
The open questions are:
|
Branch is |
Decided on adding a 'head_revision' field (in addition to 'parent_revision') to ChangeRequest. |
gonna rm -rf the Source relation for now as we dont need it and I dont want to add the complexity until it has a good reason for now you can just upsert the change request with head/parent commit, and when we support patch builds we'll implement it everywhere |
Let's rethink patches, and create a native concept for "Change Requests". These will power a few things:
They'll become a top level concern, where effectively builds become either associated with a Change Request or a Commit (unrelated to "why" its being built).
The text was updated successfully, but these errors were encountered: