A helpful operation bot for GitHub. This helps to assign a reviewer, to merge a pull request, and to notify an unmergeable pull request with a comment as a command interactively.
A development on GitHub with many developers requires many operations for users. You need looking for who can review your pull request for the repository, assigning your pull request to some reviewers, checking why your pull request is not able to merge into the upstream branch, checking that it will not cause any failures before merging your pull request, merging your pull request actually, and etc. However, basically, we have to operate these actions by hand. It's stressful.
As a developer, we must automate them by creating some bots for GitHub. We should achieve hassle-free development.
In the area of automating GitHub operation, homu is the super great operation bot and it supports a lot of valuable features: merge pull request into the latest upstream, try to testing on TravisCI, and more. It realizes the principle: The Not Rocket Science Rule Of Software Engineering: automatically maintain a repository of code that always passes all the tests by Graydon Hoare. Homu is used in Rust language and Servo. It works well in there. But its development is not in active now. And also Mozilla's servo team maintains their forked version of homu. But it is developed for their specific usecase. Not for other projects.
And, to use without host homu by yourself, you can use homu.io
or other similar service (e.g. bors.tech).
But it's shared by other third repositories. It would not suite to use it for your internal repository.
Some features (e.g. assigning reviewers to the pull request) are provided by highfive, not by homu. Thus you also have to setup it to use their features which are used in code review frequently.
And furthermore, homu's reviewer configuration need to configure the central configuration file. But we'd like to place the configuration for each repositries as decentralization. This decentraization is important if you manage many repositories and each of them has contibutors and reviewers individually.
By these things, this project intent to re-implement homu and highfive with minimum features which can support a review process, and the primary targets are an internal repository on GitHub for work or a public repository which want to host some merge bots by themselves. And also this aims to simpify deploying this bot. We challenge to make it easier than the original's one.
These are why we have developed this project.
These features are inspired by homu and highfive.
You can use these command as the comment for pull request.
r? @<reviewer>
S-awaiting-review
.r? @<reviewer1> @<reviewer2>
to assign multiple reviewers.@<reviewer> r?
(But this is deprecated syntax).@<botname> r+
or @<botname> r=<reviewer>
S-awaiting-merge
by labeling.@<botname> r-
@<botname> r+
.
S-awaiting-review
This bot provides a powerful feature we called as Auto-Merging. Auto-Merging behaves like this:
@<bot> r+
)OWNERS.json
places to the root of your repository.make build
or make build_linux_x64
.make help
to see more details.$XDG_CONFIG_HOME/popuko/
as the config dir.
(If you don't set $XDG_CONFIG_HOME
environment variable, this use ~/.config/popuko/
.)--config-base-dir
config.toml
to the config directory.
./example.config.toml
--tls
, --cert
, and --key
options.OWNERS.json
file to the root of your repository.
OwnersFile
about the detail.http://<your_server_with_port>/github
for the webhook to your repository with these events:
Issue comment
Push
Status
(required to use Auto-Merging feature (non GitHub App CI services)).Check Suite
(required to use Auto-Merging feature (GitHub App CI Services)).Pull Request
(required to remove all status (S-
prefixed) labels after a pull request is closed).S-awaiting-review
S-awaiting-merge
S-needs-rebase
S-fails-tests-with-upstream
auto
for your CI service (e.g. TravisCI).
OWNERS.json
.master
branch is equal to our released version.homu.io
or bors.tech.Yes. This bot is designed heavily for the development style which has "trunk" branch in a repository.
Of course, you can create a some branch on your upstream repository and you can open your pull request which would be merged into their non-trunk branch. However, we don't support the feature to conflict detection for them at this time (#197), and its priority is very low for us.
It was notion.
When we had started this project, we could not find it. And then we thought it's more better as an internal toolchain to implement a merging operation bot which is fully customized for our purpose.