Homu: The Not Rocket Science
Preface
In software engineering, engineers always work on each own features and send PRs for those features.
However, one PR may have impacts to another PR and the inconsistency can’t be caught when running test before merge.
For example,
PR A: Rename bifurcate function to bifurcateCrab
PR B: Call bifurcate function on landing event
After both PR merged, master is broken.
https://bors.tech/images/pitch/slide2.svg
Introduction
So, to solve the problem, here comes Homu. Homu is a reimplementation / extension of bors. Bors was implemented by Graydon Hoare (the original creator of Rust) around 2013. It mainly applied Ben Elliston’s "not rocket science" rule into Rust: The Not Rocket Science Rule Of Software Engineering:
automatically maintain a repository of code that always passes all the tests
As Graydon mentioned in the blogpost for introducing bors, he said Bors implements the Not Rocket Science Rule against a combination of a buildbot test farm and a github repository: it monitors pull requests, waits for reviewers to approve them, then for each approved revision, makes a temporary integration revision which extends your integration branch by the proposed changes. It tests that temporary revision and advances your integration branch to point to the integration revision if and only if the tests pass. If the tests fail, the integration revision is discarded and a comment in the pull request is left showing the failures.
The main spirit of homu is that every engineer should land code by submitting a pull request to the repo. Once reviewers think it's good to merge the changes in the PR, the reviewer just need to comment bors r+.
Homu will do following steps:
take the PR if the queue is empty or add the PR into homu's queue
merge it with master into a new branch
submit that branch to the setuped CI. If the tests pass, Homu will fast-forward to the merge commit and start on the next patch in its queue.
With running tests with latest master in a queue, homu users won't have the chance to merge implicitly conflicted PRs into target branch.
Example
Let's take Servo as an example so that we can understand the workflow of bors much easier!
(In this section, the *we* represents *the Servo project*)
In Servo, we use a forked homu which added more features and fixed bugs in homu. Also, we use saltfs to manage reviewers and try-ers in a toml file so that not everyone can ask homu to run commands. The Workflow
After sending the PR, I waited core members' review and jdm helped me to ask homu to try so that we can try to run tests and not make it as an approval PR in homu's queue.
After trying several times, it failed with intermittent failures and finally succeeded.
BUT, that PR was meant to fix the algorithm of node filter which means the previous implementation in Servo must be wrong and we must have FAIL test results for the filter algorithm. While whatwg updates the standard specs (excluding editorial updates), they must send a WPT test PR. So, as @jdm mentioned in this comment, there must be upstream tests for the algorithm but Servo didn't sync the tests yet. What we need to do was waiting tests synced into the Servo repo. So, I just needed to remove those FAIL test expectations. After that, the PR was ready to be merged so jdm approved the PR with commenting @bors-servo r+ (at this comment). Then, the PR would be homu's approval queue. After @bors-servo running with all tests passed, then it will merge the PR. Takeaway
So, let's list all the steps in the PR.
me sent the PR and wait for review
members asked homu to try
found we needed to update upstream tests in Servo so that we could test them with that PR
after upstream tests updated, no need to rebase and members could ask homu to try again
me fixed those test expectations
members approved the PR with r+
after CI passed, homu will merge the PR
Appendix
If you'd like to reject previous r+, you can ask homu with r-; then it will be removed from the approval queue.
If you'd like to remove branch after PR merged, I think you can now turn on this feature in GitHub. References