Dispatch makes sure pull requests within a GitHub
organization get reviewed by the right people.
| Section | Description |
|---|---|
| 👋 Introduction | What is this project? |
| 🚧 Dependencies | The technical dependencies for the project |
| 🏎 Setup | Setup instructions to quickly kickstart the project development |
| 🏗 Code & architecture | Details on the project modules and components |
| 🔭 Possible improvements | Possible refactors and ideas |
| 🚑 Troubleshooting | Troubleshooting information for potential problems |
| 🚀 Deploy | Instructions on how to deploy the application |
Dispatch gets notified about pull requests opened in GitHub projects. It then selects random users (based on existing contributors and stack-skilled developers) and requests their review.
Everything is done via a simple GitHub webhook:
| Field | Value |
|---|---|
| Payload URL | https://my-dispatch-app.com/webhooks |
| Content type | application/json |
| Events | Send me everything. |
| Parameter | Default value | Description |
|---|---|---|
stacks |
"" |
Comma-separated values of project’s stacks (e.g. elixir,graphql) |
disable_learners |
false |
Disable learners for this repository |
minimum_contributor_count |
1 | Number of contributors to select |
When a pull request is opened, Dispatch selects a list of users that will be requested for a review:
- One or many recent repository contributor
- One reviewer per stack
- One or many learners per stack (who will only be mentionned in the request comment)
Draft pull requests or pull requests with a title that begins with WIP , WIP: or [WIP] will be ignored. Pull requests that do not belong to repositories inside the configured organization (GITHUB_ORGANIZATION_LOGIN environment variable) will also be ignored.
From time to time, it can be useful to pass some specific stacks for a single pull request that differ from the ones used in the Webhook URL. #dispatch/<stack> tags can be added to the pull request body and Dispatch will use them as stacks instead of the default ones (configured in the webhook URL).
GitHub users listed in blocklist will never be requested for a review nor mentionned.
GitHub users listed in learners will not be requested for a review. Instead, they will only be mentionned in the request comment. The exposure variable is used to mention the corresponding user to a percentage of the pull requests of that stack. For example, a user with an exposure factor of 0.75 would have a 75% chance of getting a mention for each pull request of that stack.
If an Absence.io iCal URL is provided, users that are out-of-office when a pull request is opened will never be requested for a review.
- Elixir (
1.8.1) - Erlang (
21.2.5)
All required environment variables are documented in the .env.dev file.
When running mix or make commands, all of these variables must be present in the environement. To achieve this, we can use source, nv or another custom tool.
- Create an
.env.dev.localfile from.env.dev - Install Mix dependencies with
make dependencies - Compile the application
mix compile - Start a Phoenix development server with
iex -S mix phx.serverafter loading.env.devand.env.dev.localfiles into the environment
A Makefile file is present and expose several common tasks. The list of available tasks can be viewed with make help.
Tests can be ran with make test and test coverage can be calculated with make test-coverage.
Several linting and formatting tools can also be ran to ensure coding style consistency:
make lint-formatmakes sure all Elixir code is properly formattedmake lint-credomakes sure all Elixir code conforms to our best practices and guidelinesmake lint-compilemakes sure all Elixir compiles without warnings
All these commands can be executed at once with the handy make lint command.
The priv/scripts/ci-check.sh script runs a few commands (tests, lint, etc.) to make sure the project and its code are in a good state.
The configuration file stored at CONFIGURATION_FILE_URL should contain a JSON object with three keys:
blocklistreviewerslearners
{
"blocklist": [
{
"username": "github_username"
}
],
"reviewers": {
"stack_name": [
{
"username": "github_username"
}
]
},
"learners": {
"stack_name": [
{
"username": "github_username",
"exposure": 0.25
}
]
}
}| Description | Priority | Complexity | Ideas |
|---|---|---|---|
| Improve the link between Absence.io users and GitHub users | Moderate | Moderate | For now, we simply match both full names — this is error-prone |
The most common reasons as to why reviews were not requested after a pull request was opened:
- The user associated with the GitHub access token does not have “write” access to the repository
- The pull request title started with
WIP,WIP:or[WIP]when it was first opened
The most common reasons as to why there was fewer requested reviews that usual (for the same repository) on a pull request:
- There are no other active contributors to the repository other than the pull request creator
- There are no other reviewers for the repository stacks other than the pull request creator
The application can be deployed to Heroku following the Container Registry & Runtime guide.
-
Create a docker image for the OTP release (
DOCKER_IMAGE_TAG=latestis the default value).> make build DOCKER_IMAGE_TAG=latest -
Tag the image for Heroky’s registry
> docker tag dispatch:latest registry.heroku.com/dispatch/web -
Login to the Heroku registry
> heroku container:login -
Push the image to the registry
> docker push registry.heroku.com/dispatch/web -
Release the image
> heroku container:release web
Dispatch is © 2018-2019 Mirego and may be freely distributed under the New BSD license. See the LICENSE.md file.
Mirego is a team of passionate people who believe that work is a place where you can innovate and have fun. We’re a team of talented people who imagine and build beautiful Web and mobile applications. We come together to share ideas and change the world.
We also love open-source software and we try to give back to the community as much as we can.