Closed begedin closed 6 years ago
I'm a little unclear as to how to proceed with this PR, so perhaps we should do that identification step first to make the next actions more direct.
Some quick documenting here:
GitHub syncing functions for:
- events received from the GitHub API
- entire GitHub repositories
comment_deleted_outcome/0
installation_event_outcome/0
installation_repositories_event_outcome/0
issue_comment_outcome/0
issue_event_outcome/0
pull_request_comment_outcome/0
pull_request_event_outcome/0
installation_event/1
installation_repositories_event/1
issue_comment_event/1
issue_event/1
pull_request_event/1
sync_repo/1
Missing moduledoc.
delete/1
sync/2
In charge of syncing CodeCorps.Comment records with a GitHub comment payload.
A single GitHub comment always matches a single CodeCorps.GithubComment, but it can match multiple CodeCorps.Comment records. This module handles creating or updating all those records.
commit_result/0
commit_result_aggregate/0
delete/1
sync/3
sync_github_repo/1
In charge of building a Changeset to update a Comment with, when handling a GitHub Comment payload.
create_changeset/3
update_changeset/2
In charge of finding a CodeCorps.GithubComment to link with a CodeCorps.Comment when processing a GitHub Comment payload.
The only entry point is create_or_update_comment/2.
result/0
create_or_update_comment/2
delete/1
In charge of managing changesets when creating or updating a GithubAppInstallation in the process of handling an Installation event.
create_changeset/2
update_changeset/2
sync/2
sync/3
In charge of finding or creating a CodeCorps.GithubIssue to link with a CodeCorps.Task when processing a GitHub Issue payload.
The only entry point is create_or_update_issue/2.
result/0
create_or_update_issue/3
Missing moduledoc.
commit_result/0
commit_result_aggregate/0
sync_github_issue/2
sync_github_repo/1
In charge of building a Changeset to update a Task with, when handling an Issues webhook.
create_changeset/3
update_changeset/3
In charge of finding a pull request to link with a GithubPullRequest record when processing a GitHub Pull Request payload.
The only entry point is create_or_update_pull_request/2.
create_or_update_pull_request/2
In charge of extracting ids from markdown content, paired to a predefined list of keywords.
extract_closing_ids/1
In charge of finding a user to link with a given record given a GitHub API payload containing the user.
The only entry point is link_to/2.
result/0
find_or_create_disassociated_user/1
link_to/2
The above means there are types of:
commit_result/0
commit_result_aggregate/0
_outcome/0
outcome/0
result/0
All to represent certain outcomes. We should try to standardize those.
In the various syncing modules I see the following exposed as public functions:
create_or_update_comment/2
create_or_update_issue/3
create_or_update_pull_request/2
delete/1
find_or_create_disassociated_user/1
link_to/1
sync/2
sync/3
sync_github_issue/2
sync_github_repo/1
Again, there appears to be some inconsistencies here that could probably be cleaned up, condensed, and standardized somehow.
There are also inconsistencies in the moduledocs (and some missing moduledocs) that could use cleanup. Also not sure I like the wording of:
In charge of
Perhaps we should do some looking at how Elixir itself words its moduledocs for some stylistic convention seeking.
I'm probably missing something, but I'm having trouble identifying which intermediary functions are missing right now after the cleanup.
Just FYI, I'm working through these as part of your PR in #1370
We can considered this closed through #1370
Any remaining tests still required are covered by other issues
Problem
Through #1092, much of the code was unraveled and decoupled.
However, some of the intermediary functions in mid-level modules as well as their tests, were left in. We need to remove that code, unnest the modules and rewrite any tests that aren't redundant to call and test the higher level functions in the
Sync
module itself.Subtasks
Sync
module directly, remove those testsSync
moduleNotes
This PR might be large in scope, so as an alternative, It may be prudent to consider just the "identification" step part of this PR, and instead of doing the actual coding work here, create issues for each identified function/untested area.