Dev/70/alex get feature info

[alexcouper]

Look at this one after #82

[alexcouper]

For now I'm using this to stop going back to the beginning of time for every branch that matches the feature id.

Sooner rather than later we're going to need a chat about switching the architecture to being pre-fetched. Are you free at all this week?

[txels]

I think the best local caching for repos is going to be local clones as in storyboard, which will make all these more efficient.

Give this a read and see possible solutions, I am thinking deploy keys but there are other options: https://help.github.com/articles/managing-deploy-keys

One can create deploy keys via the API: http://developer.github.com/v3/repos/keys/

[alexcouper]

We'll revisit this in the next round of changes following the hangout I guess.

I'm going to set up some planning tool - I think we could do with some stories & tasks to get this going.

[txels]

Github is not figuring out the isolated changes after your other PR was merged, which makes the intent of this PR harder to follow.

[alexcouper]

@txels that's better.

[txels]

There is something still nagging me with this approach.

When getting feature info from a provider this way, it will make it more difficult to correlate and aggregate data from various sources (e.g. planning info in sprintly, open PRs in github, branches in github/git, jobs in Jenkins...). An alternative approach is passing a Feature object (or a dict if you prefer) around to the various providers in sequence (starting with the planning provider) so that each decorates the feature with additional data it knows about.

For example, I would like to get initial feature info from sprintly, then pass this to the github provider so that it adds information about open PRs and relevant branches (and even mergeability status and build success from the PR), then to Jenkins so that it can add information about known builds to the feature's branches...

Up for hangout discussion.