Split responsibilities between ci-config repo operations and project's repo operations.

[minuscorp]

For now, we use a unified interface to operate over any repo using GitRepo. Which is not the best way to proceed, because we have two separate kind of scopes concerning repo operations, the ci-config and every project's repo. i.e., ci-config repo should handle conflicts and synchronization in the best manner possible, but project's repo does we should make shallow clones, for certain branches, never ever commit changes into it, etc. So I think we should have extended ProjectService to operate with project's repos and a ci-config repo service which handles their own operations separately.

[minuscorp]

I'll try to elaborate a little bit further what I'm trying to tackle in this idea. ATM, we have a single class GitRepo which is responsible of doing everything related to Git operations, concretely with Github for now. Also we've got GithubService that, through a set of credentials make possible to operate or obtain information given a repo name.

The main goal of the PR from this issue is to achieve the following:

1. Every User has a number of ProviderCredentials of a certain type, as mean to communicate with the APIs of different code hosting services (Github, Bitbucket, Gitlab, etc).

2. For a given User and a given ProviderCredential a XXXCodeHostingService must exist, normally under demand. None of this CodeHostingServices are meant to be persisted in any way.

3. A CodeHostingService provides a unified interface, independently of the ProviderCredential type.

4. Its responsibilities are:

   • Retrieve repositories accessible given the ProviderCredential.
   • Retrieve repositories branches.
   • Shallow clone repositories given a Project (the reachability of the Project's repo will depend of the ProviderCredential which created the CodeHostingService.
   • The clone of the Project's repo is done dependant of the JobTrigger's branch attached to the Project.
   • Peek repository's (temporary shallow clone them) structure, in order to find the all branches and their Fastfiles before the project being created (given the full repo name) or with the created Project, in order to retrieve information to change its settings (branch, lane, etc.).
   • Shallow clone a Project's repo with a certain branch every time a Build is being triggered.

5. A memoized CIConfigurationService, which responsibilities are:

   • Keep the ci-config repo up-to-date. Commit local changes, pushing them to remote, pulling possible remote changes, handle conflicts.
   • Keep the correct structure of all critical files.
   • DataSources may not be responsible of notifying changes to the CIConfigurationService, through Watchmen, the service should be automatically notified of any change made in the directory and consequently make the needed operations for keep a nice and clean historical record of all operations made to the ci-config repo.

I cc @KrauseFx and @taquitos to make a discussion on this architecture and if its the way to proceed. I'm totally able to tackle this task when approved for development.

[KrauseFx]

We're going to handle these on the case-by-case bases, in smaller/separate issues/PRs 🍕