Skip to content
This repository has been archived by the owner on May 6, 2024. It is now read-only.
This repository has been archived by the owner on May 6, 2024. It is now read-only.

Change Requests #70

Open
dcramer opened this issue Dec 7, 2017 · 7 comments
Open

Change Requests #70

dcramer opened this issue Dec 7, 2017 · 7 comments

Comments

@dcramer
Copy link
Member

dcramer commented Dec 7, 2017

Let's rethink patches, and create a native concept for "Change Requests". These will power a few things:

  • Pull Requests (GitHub) and status checks
  • Diffs (Phabricator)

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).

@dcramer
Copy link
Member Author

dcramer commented Dec 7, 2017

(i had already started on some work on this, so will continue that)

@dcramer
Copy link
Member Author

dcramer commented Dec 7, 2017

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:

  • give me details for this commit
  • give me details for this pull request
  • give me details for this specific build

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.

@dcramer
Copy link
Member Author

dcramer commented Dec 11, 2017

Ok going Source -> ChangeRequest, as a PR/CR can have many sources over time and we'd want to track them uniformly.

@dcramer
Copy link
Member Author

dcramer commented Jan 15, 2018

Still working on this.

Plan right now is:

  • You upsert a ChangeRequest
  • You upsert a source on a ChangeRequest (though we need to figure out how we approach this yet, for now we'll likely just use the 'latest source' to handle force push situations)
  • CR's are automatically associated given sources

The open questions are:

  • Should a change request have a full commit range? It does on GitHub, and to support GitHub and full diffs we'd want that
  • How do we handle the case when a CR is just a patch with a parent revision?

@dcramer
Copy link
Member Author

dcramer commented Jan 15, 2018

Branch is feat/change-requests

@dcramer
Copy link
Member Author

dcramer commented Jan 15, 2018

Decided on adding a 'head_revision' field (in addition to 'parent_revision') to ChangeRequest.

@dcramer
Copy link
Member Author

dcramer commented Jan 15, 2018

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant