Initial work on github provider configuration

[txels]

Starting integration of Github provider configuration.

This is a partial implementation that:

• Integrates the github oauth workflow into the UI
• Creates a github API client that uses the logged-in user's Oauth token
• Retrieves a list of the user's organisations
• Retrieves a list of repos for the selected organisation
• Shows placeholder menu options to organisations and repos

Pending implementation:

• Show which repos are already being "followed" by ployst within one of the user's projects
• Show which organisation has already been imported as a "team"

For further discussion:

• Decide which options we'll give to import organisations as teams and repos as repos within new or existing projects (I'd like to think of bulk import operations so that you can get set up very quickly).
• Do we care about github teams as well?
• Possible changes in the core data structures to be able to attach provider-specific info at any level: user, team, project, repo, feature.

[txels]

I've finally managed to have a first proof-of-concept fully working "integrate github account" workflow.

The way to see this working:

• Remove any github oauth tokens you might have (e.g. via admin)
• Login to ployst, and go to providers/github - you should see a button to "Assimilate your github account" - this will start the oauth dance
• Once oauth'ed, you should see a list of your organisations and personal repos.

This is far from production code, no tests etc. as it was exploratory coding to figure out the actual way to integrate provider and core via angular. I think I've found the right approach. Let me know what you think.

[txels]

@alexcouper this is ready for another review. I don't think I'll add any functionality in this prototype until we've discussed the items in the PR description.

[alexcouper]

I'll try to have a look at this in the next couple of days.

As an update - I've scheduled this in mentally for Thursday evening this week. I will aim to deliver!

[alexcouper]

I've tried this, but I get an error when I click on "assimilate github"

nternal Server Error: /providers/github/oauth-confirmed/
Traceback (most recent call last):
  File "/Users/alex/.virtualenvs/ployst/lib/python2.7/site-packages/django/core/handlers/base.py", line 114, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/Users/alex/.virtualenvs/ployst/lib/python2.7/site-packages/django/views/decorators/http.py", line 41, in inner
    return func(request, *args, **kwargs)
  File "/Users/alex/Work/pretenders/ployst/ployst/github/views/oauth.py", line 44, in receive
    exchange_for_access_token(request.user.id, request.GET['code'])
  File "/Users/alex/Work/pretenders/ployst/ployst/github/views/oauth.py", line 79, in exchange_for_access_token
    client.set_access_token(user_id, 'github', token)
  File "/Users/alex/Work/pretenders/ployst/ployst/core/client.py", line 151, in set_access_token
    'token': access_token,
  File "/Users/alex/Work/pretenders/ployst/ployst/core/client.py", line 41, in post
    return self._http('post', path, data)
  File "/Users/alex/Work/pretenders/ployst/ployst/core/client.py", line 33, in _http
    response.content)
UnexpectedResponse: 401: {"detail": "Authentication credentials were not provided."}
[06/Jun/2014 22:17:12] "GET /providers/github/oauth-confirmed/?code=ce3131709e654c364bf8&state=ChAnGeThIsOnPrOdUcTiOn HTTP/1.1" 500 95207

[txels]

Hmmm. That is part of the existing Oauth workflow that I haven't really modified in this PR. Does that workflow still work for you in develop?

I guess this may be due to missing credentials, maybe your ployst core API token has been lost due to DB cleanup (check http://localhost:8000/admin/apibase/token/)... According to your settings, in order to run this you need to ensure the env var GITHUB_CLIENT_SECRET is set [1] (this doesn't seem to be your problem, as it's failing for you after returning from Oauth).

---

[1] I made myself a run script as I always forgot that bit. E.g.:

GITHUB_CLIENT_SECRET=230d9e65... ./manage.py runserver $* --settings=ployst.settings.dev_cba

[alexcouper]

Hmm, OK I'll double check, but thought I had confirmed that I only deleted the user key. I too have such a script, I'll play with it a bit and see what is wrong.

I'm at the summer house at the moment in 20° C - hopefully the weather is like this next month!

[txels]

BTW this is what it should look like, once you manage to get through oauth:

[txels]

I reproduced your error by removing my API token (http://localhost:8000/admin/apibase/token/). I've added a more informative error log message for now.

[alexcouper]

looks good and works well.

Do we care about github teams as well?

For now let's say "no".

I think as a user I'd expect "import as team" to somehow give access at least to the users who are in the team - but I think we need to be very careful at this point because a user who has been removed as a collaborator of a repo in github should also be removed from accessing data in ployst. An option would be for user to have to add in a process that makes it clear he is responsible to maintain the relationships?

Decide which options we'll give to import organisations as teams and repos as repos within new or existing projects

I'm not certain this answers your question, but I think that we should allow users to select n repos from an org and import into a team - be it new or existing.

[txels]

This is a collection of the import options I was thinking of, trying to go from "a default setup with minimum clicks" (that you can later edit) to a cherry-picking approach. Some combinations of these could be possible:

1. One-click import: makes one team for your organisation, one project per repo, imports all repos
2. One-click import, single project: one team and project for an organisation, all repos in same project
3. Import organisation only: as new team, or link to existing team
4. Import one repo at a time only: as new project, or choose existing project
5. Import multiple repos into one project: select with checkboxes, and then import into one project - create new or choose existing

So I'd like to pick which make most sense, as priorities. Limit ourselves to the minimal preferred set.

With only approaches 1 and 2 we should later at least allow joining projects or moving repos across projects?

[alexcouper]

Are you happy for me to merge this?

[txels]

sure :)