72e30a7f90
* add reactions to issue response payload * add reactions to commit comment payload * add reactions to review comment payload * create tests for issue client * tests for commitcomment client * tests for pull request review comment * change observable tests * simplify strings * remove unnecessary clients * change integration tests to retrieve all reaction types * create integration test for issue comment client * fix merge conflicts * fix merge conflicts * gets tests passing again * fix some reaction integration tests * Fixup unit tests wth preview accepts header Also applied preview header to a couple of repositoryId based calls that were added by another PR * Fixup unit tests wth preview accepts header Also applied preview header to a couple of repositoryId based calls that were added by another PR * Rework reaction payload tests for IssueComments to handle Get, GetAllForIssue and GetAllForRepository calls * [WIP] reaction payload tests * Rework reaction payload tests for IssueComments to handle Get, GetAllForIssue and GetAllForRepository calls * Rework reaction payload tests for Issues client * Rework reaction payload tests for PullRequestReviews client * Rework reaction payload tests for CommitComments client * Revert "[WIP] reaction payload tests" This reverts commit a6179b0f21a3ddfe36bfd3ae5eafae0e69b52252.
Octokit Models
These either represent the body of a GitHub API request or response.
Request objects should be placed in the, you guessed it, Request folder. Likewise Response objects should be placed in the Response folder.
Some models can be used for both requests and responses.
Request models
The general design principle for request models are:
- They represent the body of a request.
- Properties that are required by the API should be required by the model and passed in via the constructor.
- Required porperties should not have a setter since they will be set by the constructor.
- All other properties should have both a getter and setter.
Note that Octokit.net automatically converts property name to the Ruby casing required by the GitHub API. Thus a
property named BreakingBad would be passed as breaking_bad.
Response models
The general design principle for response models are:
- They should be immutable. As such, properties have a
publicgetter andprotectedsetter. - We want the properties to be read only, but also make it possible to mock the response from API methods.
- They must be easily serialized and deserialized.
- They need a default constructor as well as one that takes in every parameter.
We're in the process of reconsidering this design as it's created a few problems for us. Namely that creating these objects in a unit test is a royal pain.
Notes
There's a lot of confusion caused by the fact that the GitHub API returns GitHub resources as well as Git resources.
For example, you can use the Git Data API to directly manipulate Git objects
such as a commit. At the same time, GitHub also has its own commit (represented by GitHubCommit in Octokit.net)
that contains the GitHub information around the commit such as comments.