Repository Management CRUD Service

[dealako]

Summary

This task is to create an API for Repository Management.

Background

A CLA Group is a logical organization under a single Foundation (also often called a Project) that groups a collection of related source code organizations (e.g. GitHub Organization or Gerrit Group) and/or repositories under a single CLA legal grouping/policy. This task will define, implement, validate and test the API services supporting creating, updating, viewing, searching and deleting of repositories under a CLA Group.

User Story

As a project manager, I want to add a set (one or more) of GitHub repositories to my project.
As a project manager, I want to delete a set (one or more) of GitHub repositories to my project.
As a project manager, I want to search the GitHub repositories by the repository name under my project.

Tasks

1. Define a swagger specification for creating one or more repositories under a given project.

   1. The swagger specification will accept the foundation/project id (SFID) and the CLA Group id, the repository type (GitHub, Gerrit, GitLab, etc.), and one or more repositories to add.

2. Define a swagger specification for deleting a set (one or more) repositories under a CLA Group

3. Define a swagger specification for searching or listing a list of repositories under a Project/CLA Group. Include pagination params as well: page_size/limit, offset, order_by as the list of parameters.

   1. Should be able to search all repositories under the Project/CLA Group
   2. Should be able to search/filter by repository type
   3. Should be able to search/filter by repository name
   4. Should be able to search/filter by repository organization

4. Define the repository database schema using dbmate. Fields might include:

   1. repository_id: pk GUID type v4 or something similar
   2. repository_type: a string representing the repository type (GitHub, Gerrit, GitLab, etc.)
   3. repository_name - the name of individual repository on GitHub/Gerrit/GitLab, etc.
   4. repository_organization_name - the name of the repository parent organization
   5. repository_url - the repository URL, such as github.com/communitybridge/easycla
   6. repository_enabled - a flag to indicate if this repository is enabled for this Project/CLA Group (may not need this) - default TRUE
   7. project_id - the SFDC project id
   8. cla_group_id - the CLA Group ID
   9. date_created - the date the repository was added

5. Create a repo implementation for the CRUD operations defined above

6. Create a service layer to support the REST operations defined above

7. Create an API handler to bin the Swagger specification to the implementation

8. Add the handler/service/repo to the setup to stitch it together

9. Create an audit event in the audit table when a repository is added, updated or deleted

10. test/validate CRUD operations

Acceptance Criteria

The "done" criteria when this feature or problem is resolved. Such as:

1. Unit Tests added and running in CI
2. Functional Tests updated to cover feature, if applicable
3. Demonstrate the set of capabilities to the product team while the code is
   running in the DEV environment.

References

1. EasyCLA v1 repository schema: https://confluence.linuxfoundation.org/display/PROD/EasyCLA+Version+1+Database+Schema+Walkthrough#EasyCLAVersion1DatabaseSchemaWalkthrough-Repositories
2. UX Mock Ups that leverage this service: https://wireframepro.mockflow.com/view/app-easycla#/page/D2f18f9c3dbacbc216821b379b96a0347