🔬 Scope definition

[dennissivia]

Technical requirements

In order to get up and running we need:

• [x] An HTTP endpoint that serves for setup (currently /github/setup)
• [x] An HTTP endpoint that receives events (currently /github/events)
• [x] The ability to extract necessary data from event payloads (no JSON schema exists)

Feature/Product requirements

In scope

The following features are required for this PoC to achieve an MVP like state

• Create a check-run based on commit metadata
  • What data ? Message? Diff?

Out of scope

Technical decisions

Dependencies

In order to proceed fast and avoid duplication, we are trying to use existing open source solutions for the basic client library and the GitHub App framework. However, if the design goals of that dependency do not align with our design goals, we are going to implement that feature from scratch.

Libraries

GraphQL

• rust-graphql for integration with the v4 (GQL) API

  Web framwork

• Actix
  • Runs on stable rust
  • Adds unnecessary complexity through actors, supervision and many dependencies
  • is 1.0
• ~Rocket~
  • Requires nightly build
• Gotham
  • Runs on stable Rust
  • still pre 1.0 (0.4)

Abstractions

Probot exposes App (the express.js app) to the user. Which would mean the consumers of the framework are coupled to the framework decision we make. I don't really like that idea, except that it might be a nice fallback if a user needs features we are not exposing and this way they could reach through our abstractions to add their custom behavior.

[dennissivia]

Status update

Web framework

This test app now uses gotham.rs instead of actix. I have an alterantive implementation with actix, but they are almost identical, so I decided to give gotham a try and everything seems good so far. The only thing that can get be tough to figure out (for me) is the async nature and the future based implementation of handlers. That is similar in actix-web since they are both async web frameworks.

Dependencies

I decided to not pull in any of the dependencies quite yet. However, I noticed that creating all the Payload structures and json bodies for creating data will become a ton of work. We have to discuss what the best approach might be.

Abstractions

Github Apps with a lot of traffic often face the problem, that they want to respond to the webhook immediately and then leave the promises or futures running that perform the actual work. Some Apps are also using queues to mitigate that problem. Therefore I want to try doing almost nothing in webhook events and just pass the payload to a worker thread, persistence of queue.

Milestones :rocket:

We are now able to:

• Receive and handle InstallationEvents
• Receive and parse PushEvent webhooks
• Create JWTs based on RSA private keys
• Create InstallationTokens with that JWT
• Create CheckSuites and CheckRuns with the InstallationToken