-
Notifications
You must be signed in to change notification settings - Fork 86
Open
Description
Problem
Much of the GitHub syncing can be reorganized as follows:
CommentSyncer
andTaskSyncer
need to move out ofEvent
; structure could be like:sync/issue/issue.ex
Sync.Issue
(main entry point for handling the syncing of an issue)sync/issue/body_parser.ex
Sync.Issue.BodyParser
(parses issue body)sync/issue/task/task.ex
Sync.Issue.Task
(syncs the issue to aTask
)sync/issue/task/changeset.ex
Sync.Issue.Task.Changeset
(deals with changesets)sync/issue/github_issue/github_issue.ex
Sync.Issue.GithubIssue
(syncs the issue to aGithubIssue
)- etc.
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.ChangesetBuilder
s- need to move out event to wherever syncing goes
map
can be removed- naming needs to be rethought to reflect that these are changesets for Code Corps models (
Task
,Comment
, etc)
To pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.GithubRepo
installation events need to havecommon/repo_finder
(renamed torepo_linker
)CommentDeleter
needs to move out ofEvent
CommentDeleter
needs to deleteGithubComment
ChangesetBuilder
s needcreate_
andupdate_
functions made public,build_
fns removed, unit tests addedReplace instances offind_or_init
andcommit
with insert_or_update and findTo pick up a draggable item, press the space bar. While dragging, use the arrow keys to move the item. Press space again to drop the item in its new position, or press escape to cancel.
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
Select code repository
Activity
begedin commentedon Jan 9, 2018
Re:
Not sure if this is still applicable.
The main Sync module makes extensive use of the existing
Sync.Utils.RepoFinder
. The approach towards using it is that a sync step is expected to fail if none is found.The InstallationRepositories event has an internal method for finding a repo, which works differently due to a find or create approach which is necessary here.
The Installation event preloads all Repos as the final step and then processes each of them individually. There is no
find_or_create
in there. We explicitly now which repo is to be created, which updated, which deleted.The Matched/Unmatched user helper modules do not deal with processing repos.
If we try really hard, we could force the installation repos and installation repo loading into
RepoFinder
, but from my POV, unless I'm missing something, it will make the code less manageable.Re:
At some point, we probably had the idea of the module actually linking a provided record with a repo, but the current module actually does just try to find the repo, returning an ok or error tuple.
I feel
RepoFinder
is more suitable thanRepoLinker
, considering that.Re:
There is only one instance left in
CodeCorps.GitHub.Sync.Issue.GithubIssue
Looking at all of our other code, I'm seeing inconsistencies here
GithubIssue.changeset
, then add to itmaybe
In our other modules,
Changeset
helper modulenil
,Changeset.create_changeset
, if found,Changeset.update_changeset
create_changeset
associates everything,update_changeset
only the associations allowed to change post-creationI'm actually inclined to switch to this other approach instead of leaving this here.
joshsmith commentedon Jan 10, 2018
@begedin what's the ultimate actionable takeaway of the above comment? I see an inclination but not confident about execution.
begedin commentedon Jan 11, 2018
With the recent changes in the PR, I'd say
This is obsolete and has been dealt with differently
We now have a common "Finder" module, used for everything, though that might go obsolete to
Seems ok for now, but we may change it up a bit later. Not sure
joshsmith commentedon Jan 11, 2018
Is this issue actually relevant now after the merge of your PR?