@npendery Same as with #805 , let me know how you feel about continuing this.

@npendery Hey Nick.

It's been a while, sadly, but building the basic infrastructure was complicated and required us to rethink how we approach a lot of things.

Still, it's done and it seems we've gotten to a point where we can get this working.

If you want to continue your work here, let me know. Otherwise, someone else will take over. What you did is very appreciated, though.

That being said, there are still a couple of things we need to figure out here

Apparently, the only documented way to access a github issue is through the owner/repo/number approach.

There's this whole alternative github API which allows accessing issues, repos and users through their unique ids instead, which would be amazing, but it's undocumented, so we probably should not be using it.

With that in mind, it looks like github_id is not the field we should use to associate a task to a github issue.

That means it's more complicated than we hoped.

In case you do want to continue, some pointers

The only way that I could think of to do it in an officially supported manner would be to have the task

• store a github_issue_number field
• have a belongs_to :github_repo, CodeCorps.GithubRepo

Both of these should be added and the github_id field should be removed

When a task is created

• you should have a github_repo_id immediately, because, presumably, the user selected a github repo as they were creating the task on our site. We may do it differently at a later time, but this is the simplest approach I can think off

• use that id to retrieve a GithubRepo record from our database

• use the information in that record (:github_account_login, :name) to create an issue

• the creation request will return a payload containing a number, assign that to the github_issue_number field

• this all should be done in a transaction, if any part fails, no task should be created.

When a task is updated

• the task you're updating might have a github_repo association and a github_issue_number field
• use those to also update the associated github issue through the github API
• this should be done in a transaction. if the local update fails, the github issue should not be updated and vice versa

@begedin is this PR still relevant after having #805 merged?

No, not at all. The update case has been covered by #805

@npendery Thank you for your work here, as well as #805. Unfortunately, the specs for the two issues you covered have changed so much from our initial idea, we had to take over, but your effort is still appreciated.