[EPIC] Zally Integration With GitHub Enterprise

Acceptance criteria

As an API Developer I want to get feedback on my API changes when I open Pull Request on GHE So that I have an additional quality gate for the PR process

Tickets

• #477
• #478
• #479
• #480
• #481
• #482
• #483
• #484

Target architecture

       On open PR                     Send validation request
                                       and store the result
GHE  <-------------> GHE Integration <-----------------------> ZALLY Server
          REST       (this project)            REST

Workflow

1. Developer opens a PR on the GitHub Enterprise (GHE)
2. GHE via a Web-hook triggers GHE Integration Layer (IL)
3. IL reads configuration of the repository
4. IL find Swagger file and send request to ZALLY
5. IL stores the validation result and notifies GHE back with the status and result link
6. By following the result link, Developer can always retrieve the validation result from IL

[vadeg]

Thank you @maxim-tschumak and @roxspring! Just couple of comments.

Are you OK with throwing the unused code away and giving GitLab integration a try as a part of the Zally server?

I am totally fine with throwing away unused code, of course 😃 I am not OK with having GL/GH integration directly in Zally instead of having a separate component, but I agree with you both - let’s try with GitLab first (at least @roxspring will use it) then will see do we need to separate it or not.

And having an extra service with a persistence is an effort we can avoid now, from code-maintaining and operations perspective.

Probably I do not have a full picture with GH/GL integration, but what for do we need a persistence there? I thought it might work as a proxy between Zally and GL/GH without persistence at all because the only thing needed is a permalink to API review which will be managed by Zally.

Supporting Zally in both persistent and non-persistent configurations sounds nice in theory but, to me, not worth much time and energy.

We had this option already in place. For example, if someone wants to use Zally as a service which does only validation without keeping reports and permalinks Zally can be deployed with in-memory database. In can be deployed even with an embedded database which will store everything on disk for use cases where user do not want to setup a separate database. Nothing to invest here, actually 😃

[maxim-tschumak]

In my opinion we can drop the GitHub (Enterprise) integration aka “bark”. We don’t see much benefit for us (for now). I propose to adjust @roxspring 's plan to the following:

1. Implement permalinks directly in Zally #593
2. Implement GitLab integration directly in Zally, heavily inspired by existing GitHub integration code (and with the idea in mind of how we can reuse parts of the code to implement GitHub integration)
3. Create an issue for GitHub integration (with a short description of how to implement)

In this case, @roxspring, you would be able to go faster with the implementation of the desired feature and we can get rid of the unused code.