servo / homu Goto Github PK

View Code? Open in Web Editor NEW

This project forked from barosl/homu

326.0 26.0 51.0 576 KB

A bot that integrates with GitHub and your favorite continuous integration service

License: MIT License

HTML 9.64% Python 90.36%

homu's Introduction

Homu

_{Who's this?}

Homu is a bot that integrates with GitHub and your favorite continuous integration service such as Travis CI, Appveyor or Buildbot.

Why is it needed?

Let's take Travis CI as an example. If you send a pull request to a repository, Travis CI instantly shows you the test result, which is great. However, after several other pull requests are merged into the master branch, your pull request can still break things after being merged into master. The traditional continuous integration solutions don't protect you from this.

In fact, that's why they provide the build status badges. If anything pushed to master is completely free from any breakage, those badges will not be necessary, as they will always be green. The badges themselves prove that there can still be some breakages, even when continuous integration services are used.

To solve this problem, the test procedure should be executed just before the merge, not just after the pull request is received. You can manually click the "restart build" button each time before you merge a pull request, but Homu can automate this process. It listens to the pull request comments, waiting for an approval comment from one of the configured reviewers. When the pull request is approved, Homu tests it using your favorite continuous integration service, and only when it passes all the tests, it is merged into master.

Note that Homu is not a replacement of Travis CI, Buildbot or Appveyor. It works on top of them. Homu itself doesn't have the ability to test pull requests.

Influences of bors

Homu is largely inspired by bors. The concept of "tests should be done just before the merge" came from bors. However, there are also some differences:

Stateful: Unlike bors, which intends to be stateless, Homu is stateful. It means that Homu does not need to retrieve all the information again and again from GitHub at every run. This is essential because of the GitHub's rate limiting. Once it downloads the initial state, the following changes are delivered with the Webhooks API.
Pushing over polling: Homu prefers pushing wherever possible. The pull requests from GitHub are retrieved using Webhooks, as stated above. The test results from Buildbot are pushed back to Homu with the HttpStatusPush feature. This approach improves the overall performance and the response time, because the bot is informed about the status changes immediately.

And also, Homu has more features, such as rollup, try, and the Travis CI & Appveyor support.

Usage

How to install

$ sudo apt-get install python3-venv 
$ pyvenv .venv
$ . .venv/bin/activate
$ git clone https://github.com/servo/homu.git
$ pip install -e homu

How to configure

In the following instructions, HOST refers to the hostname (or IP address) where you are running your custom homu instance. PORT is the port the service is listening to and is configured in web.port in cfg.toml. NAME refers to the name of the repository you are configuring homu for.

Copy cfg.sample.toml to cfg.toml. You'll need to edit this file to set up your configuration. The following steps explain where you can find important config values.
Create a GitHub account that will be used by Homu. You can also use an existing account. In the account settings, go to "OAuth applications" and create a new application:
- Make note of the "Client ID" and "Client Secret"; you will need to put them in your cfg.toml.
- The OAuth Callback URL should be http://HOST:PORT/callback.
- The homepage URL isn't necessary; you could set http://HOST:PORT/.
Go to the user settings of the GitHub account you created/used in the previous step. Go to "Personal access tokens". Click "Generate new token" and choose the "repo" and "user" scopes. Put the token value in your cfg.toml.
Add your new GitHub account as a Collaborator to the GitHub repo you are setting up homu for. This can be done in repo (NOT user) "Settings", then "Collaborators".

4.1. Make sure you login as the new GitHub account and that you accept the collaborator invitation you just sent!
Add a Webhook to your repository. This is done under repo (NOT user) "Settings", then "Webhooks". Click "Add webhook", the set:
- Payload URL: http://HOST:PORT/github
- Content type: application/json
- Secret: The same as repo.NAME.github.secret in cfg.toml
- Events: Issue Comment, Pull Request, Pull Request Review Comments, Push, Status, Check runs

Add a Webhook to your continuous integration service, if necessary. You don't need this if using Travis/Appveyor.

Buildbot

Insert the following code to the master.cfg file:

from buildbot.status.status_push import HttpStatusPush

c['status'].append(HttpStatusPush(
   serverUrl='http://HOST:PORT/buildbot',
   extra_post_params={'secret': 'repo.NAME.buildbot.secret in cfg.toml'},
))

Go through the rest of your cfg.toml and uncomment (and change, if needed) parts of the config you'll need.

How to run

$ . .venv/bin/activate
$ homu

Deploying Servo's Homu

After merging a change to this repo, updated the pinned hash in Salt.

homu's People

Stargazers

Watchers

homu's Issues

Homu stuck in 'try' state

When a try build fails (due to intermittents) and someone r+ it after the try failure, Homu seems to still be stuck in the 'try' state, i.e. it would display "trying commit ..." instead of "testing commit ..." when building the PR, and it would not merge the branch into master. servo/servo#10670 is an example of this behaviour.

EDIT: Using r+ clean does not seem to solve the problem.

Don’t cancel try builds when the PR is pushed

Steps to reproduce:

I work on servo/servo#12943, make a few commits. There is more to do before reviewing/merging, but at that point I want to make sure my refactoring actually works.
Open the PR and start a try build
Since it’s gonna take a while, I keep working and make some more commits and push them

Actual result:

Homu sees that the branch has changed, and decides it’s not interested in that try build anymore even though the builders have been running for almost an hour. (I’m not sure the jobs are even canceled to make progress in the queue, the results might just be dropped at the end.)
The PR is then reviewed and r+’ed
It turns out my initial refactor did have one bit missing, and a test fails.
I need to do an other round of babysitting CI bots.

Expected results:

Homu comments on the PR with the result of the try build even if the PR’s HEAD has changed. I’m still interested in those results, that’s why I started the try build!

CC @larsbergstrom

[rfe] rebase & push to make status "Merged"

If PR is sent from same upstream repository and is not fast-forwardable, but approved we can do rebase and force-push before merging. This will tell github that this PR not closed, but merged.

Intermittent "Test was successful, but fast-forwarding failed: 422 Update is not a fast forward"

eg. servo/servo#9911 (comment)

Homu can't handle statuses without URLs set

The build_res table shouldn't have a NOT NULL restriction on the url field, since it is possible for commit statuses to not have the URL set.

Add tests

We currently only test Homu with flake8.

It would be nice to at least mock the failures that the GitHub API might return, in order to test that we handle them properly.

Homu sometimes has an UnboundLocalError

This error occurs semi-frequently in the Servo homu logs.

INFO:homu:Starting build of servo/ipc-channel#77 on auto: 79cd0c1d4377c06e175f7f8230fa8a62d68bbe69
Traceback (most recent call last):
  File "/home/servo/homu/_venv/bin/bottle.py", line 862, in _handle
    return route.call(**args)
  File "/home/servo/homu/_venv/bin/bottle.py", line 1732, in wrapper
    rv = callback(*a, **ka)
  File "/home/servo/homu/homu/server.py", line 387, in github
    realtime=True,
  File "/home/servo/homu/homu/main.py", line 404, in parse_commands
    if 'authzfail' in res.text:
UnboundLocalError: local variable 'res' referenced before assignment

Make Homu check review summaries for commands

servo/rust-mozjs#305 (review)

homu does not merge after successful test

Starting build of rpm-software-management/dnf#525 on auto: 75cddcb9db87af68d1034af80b88e9f4250f9f62
INFO:homu:Starting build of rpm-software-management/dnf#525 on auto: 75cddcb9db87af68d1034af80b88e9f4250f9f62
info: {'organization': {'id': 8504469, 'description': '', 'login': 'rpm-software-management'}, 'action': 'created', 'repository': {'has_downloads': True, 'size': 41611, 'has_pages': True, 'open_issues': 12, 'has_wiki': True, 'stargazers_count': 325, 'default_branch': 'master', 'watchers': 325, 'forks': 122, 'fork': False, 'watchers_count': 325, 'created_at': '2012-03-09T15:31:09Z', 'name': 'dnf', 'language': 'Python', 'full_name': 'rpm-software-management/dnf', 'owner': {'id': 8504469, 'type': 'Organization', 'site_admin': False, 'gravatar_id': '', 'login': 'rpm-software-management'}, 'open_issues_count': 12, 'id': 3671909, 'description': 'dnf is a package manager based on yum and libsolv', 'forks_count': 122, 'homepage': '', 'private': False, 'has_issues': False, 'updated_at': '2016-06-26T19:42:06Z', 'pushed_at': '2016-06-30T12:39:14Z'}, 'comment': {'id': 229646055, 'body': ':hourglass: Testing commit 893ca20 with merge 75cddcb...', 'updated_at': '2016-06-30T12:39:14Z', 'created_at': '2016-06-30T12:39:14Z', 'user': {'id': 10563235, 'type': 'User', 'site_admin': False, 'gravatar_id': '', 'login': 'dnf-bot'}}, 'sender': {'id': 10563235, 'type': 'User', 'site_admin': False, 'gravatar_id': '', 'login': 'dnf-bot'}, 'issue': {'assignee': None, 'comments': 4, 'body': 'If dnf in EPEL (0.6.4.2) is upgraded into higher version, the python2-dnf\r\nincorrectly obsolete not only python-dnf but also dnf. The patch should solve\r\nit.', 'number': 525, 'created_at': '2016-06-30T11:47:49Z', 'id': 163146085, 'state': 'open', 'user': {'id': 12737303, 'type': 'User', 'site_admin': False, 'gravatar_id': '', 'login': 'j-mracek'}, 'title': 'Fix problem with obsolete dnf in epel version 0.6.4.2', 'labels': [], 'milestone': None, 'assignees': [], 'locked': False, 'pull_request': {}, 'updated_at': '2016-06-30T12:39:14Z', 'closed_at': None}}
DEBUG:homu.server.github:info: {'organization': {'id': 8504469, 'description': '', 'login': 'rpm-software-management'}, 'action': 'created', 'repository': {'has_downloads': True, 'size': 41611, 'has_pages': True, 'open_issues': 12, 'has_wiki': True, 'stargazers_count': 325, 'default_branch': 'master', 'watchers': 325, 'forks': 122, 'fork': False, 'watchers_count': 325, 'created_at': '2012-03-09T15:31:09Z', 'name': 'dnf', 'language': 'Python', 'full_name': 'rpm-software-management/dnf', 'owner': {'id': 8504469, 'type': 'Organization', 'site_admin': False, 'gravatar_id': '', 'login': 'rpm-software-management'}, 'open_issues_count': 12, 'id': 3671909, 'description': 'dnf is a package manager based on yum and libsolv', 'forks_count': 122, 'homepage': '', 'private': False, 'has_issues': False, 'updated_at': '2016-06-26T19:42:06Z', 'pushed_at': '2016-06-30T12:39:14Z'}, 'comment': {'id': 229646055, 'body': ':hourglass: Testing commit 893ca20 with merge 75cddcb...', 'updated_at': '2016-06-30T12:39:14Z', 'created_at': '2016-06-30T12:39:14Z', 'user': {'id': 10563235, 'type': 'User', 'site_admin': False, 'gravatar_id': '', 'login': 'dnf-bot'}}, 'sender': {'id': 10563235, 'type': 'User', 'site_admin': False, 'gravatar_id': '', 'login': 'dnf-bot'}, 'issue': {'assignee': None, 'comments': 4, 'body': 'If dnf in EPEL (0.6.4.2) is upgraded into higher version, the python2-dnf\r\nincorrectly obsolete not only python-dnf but also dnf. The patch should solve\r\nit.', 'number': 525, 'created_at': '2016-06-30T11:47:49Z', 'id': 163146085, 'state': 'open', 'user': {'id': 12737303, 'type': 'User', 'site_admin': False, 'gravatar_id': '', 'login': 'j-mracek'}, 'title': 'Fix problem with obsolete dnf in epel version 0.6.4.2', 'labels': [], 'milestone': None, 'assignees': [], 'locked': False, 'pull_request': {}, 'updated_at': '2016-06-30T12:39:14Z', 'closed_at': None}}
info: {'before': '0000000000000000000000000000000000000000', 'deleted': False, 'repository': {'has_downloads': True, 'size': 41611, 'has_pages': True, 'open_issues': 12, 'has_wiki': True, 'stargazers_count': 325, 'default_branch': 'master', 'stargazers': 325, 'master_branch': 'master', 'watchers': 325, 'forks': 122, 'fork': False, 'watchers_count': 325, 'created_at': 1331307069, 'name': 'dnf', 'language': 'Python', 'full_name': 'rpm-software-management/dnf', 'owner': {'name': 'rpm-software-management', 'email': ''}, 'open_issues_count': 12, 'id': 3671909, 'description': 'dnf is a package manager based on yum and libsolv', 'forks_count': 122, 'updated_at': '2016-06-26T19:42:06Z', 'homepage': '', 'private': False, 'has_issues': False, 'organization': 'rpm-software-management', 'pushed_at': 1467290354}, 'head_commit': {'distinct': True, 'removed': [], 'tree_id': 'd0bc9bf6c6f2c678a3635dba841696d27dba9e31', 'timestamp': '2016-06-30T12:39:12Z', 'id': '75cddcb9db87af68d1034af80b88e9f4250f9f62', 'committer': {'name': 'dnf-bot', 'email': '[email protected]'}, 'modified': ['dnf.spec'], 'message': 'Fix problem with obsolete dnf in epel version 0.6.4.2\n\nIf dnf in EPEL (0.6.4.2) is upgraded into higher version, the python2-dnf\nincorrectly obsolete not only python-dnf but also dnf. The patch should solve\nit.\n\nCloses: #525\nApproved by: ignatenkobrain', 'author': {'name': 'Jaroslav Mracek', 'email': '[email protected]', 'username': 'j-mracek'}, 'added': []}, 'compare': 'https://github.com/rpm-software-management/dnf/commit/75cddcb9db87', 'commits': [{'distinct': True, 'removed': [], 'tree_id': 'd0bc9bf6c6f2c678a3635dba841696d27dba9e31', 'timestamp': '2016-06-30T12:39:12Z', 'id': '75cddcb9db87af68d1034af80b88e9f4250f9f62', 'committer': {'name': 'dnf-bot', 'email': '[email protected]'}, 'modified': ['dnf.spec'], 'message': 'Fix problem with obsolete dnf in epel version 0.6.4.2\n\nIf dnf in EPEL (0.6.4.2) is upgraded into higher version, the python2-dnf\nincorrectly obsolete not only python-dnf but also dnf. The patch should solve\nit.\n\nCloses: #525\nApproved by: ignatenkobrain', 'author': {'name': 'Jaroslav Mracek', 'email': '[email protected]', 'username': 'j-mracek'}, 'added': []}], 'ref': 'refs/heads/auto', 'forced': True, 'after': '75cddcb9db87af68d1034af80b88e9f4250f9f62', 'pusher': {'name': 'dnf-bot', 'email': '[email protected]'}, 'base_ref': None, 'sender': {'id': 10563235, 'type': 'User', 'site_admin': False, 'gravatar_id': '', 'login': 'dnf-bot'}, 'organization': {'id': 8504469, 'description': '', 'login': 'rpm-software-management'}, 'created': True}
DEBUG:homu.server.github:info: {'before': '0000000000000000000000000000000000000000', 'deleted': False, 'repository': {'has_downloads': True, 'size': 41611, 'has_pages': True, 'open_issues': 12, 'has_wiki': True, 'stargazers_count': 325, 'default_branch': 'master', 'stargazers': 325, 'master_branch': 'master', 'watchers': 325, 'forks': 122, 'fork': False, 'watchers_count': 325, 'created_at': 1331307069, 'name': 'dnf', 'language': 'Python', 'full_name': 'rpm-software-management/dnf', 'owner': {'name': 'rpm-software-management', 'email': ''}, 'open_issues_count': 12, 'id': 3671909, 'description': 'dnf is a package manager based on yum and libsolv', 'forks_count': 122, 'updated_at': '2016-06-26T19:42:06Z', 'homepage': '', 'private': False, 'has_issues': False, 'organization': 'rpm-software-management', 'pushed_at': 1467290354}, 'head_commit': {'distinct': True, 'removed': [], 'tree_id': 'd0bc9bf6c6f2c678a3635dba841696d27dba9e31', 'timestamp': '2016-06-30T12:39:12Z', 'id': '75cddcb9db87af68d1034af80b88e9f4250f9f62', 'committer': {'name': 'dnf-bot', 'email': '[email protected]'}, 'modified': ['dnf.spec'], 'message': 'Fix problem with obsolete dnf in epel version 0.6.4.2\n\nIf dnf in EPEL (0.6.4.2) is upgraded into higher version, the python2-dnf\nincorrectly obsolete not only python-dnf but also dnf. The patch should solve\nit.\n\nCloses: #525\nApproved by: ignatenkobrain', 'author': {'name': 'Jaroslav Mracek', 'email': '[email protected]', 'username': 'j-mracek'}, 'added': []}, 'compare': 'https://github.com/rpm-software-management/dnf/commit/75cddcb9db87', 'commits': [{'distinct': True, 'removed': [], 'tree_id': 'd0bc9bf6c6f2c678a3635dba841696d27dba9e31', 'timestamp': '2016-06-30T12:39:12Z', 'id': '75cddcb9db87af68d1034af80b88e9f4250f9f62', 'committer': {'name': 'dnf-bot', 'email': '[email protected]'}, 'modified': ['dnf.spec'], 'message': 'Fix problem with obsolete dnf in epel version 0.6.4.2\n\nIf dnf in EPEL (0.6.4.2) is upgraded into higher version, the python2-dnf\nincorrectly obsolete not only python-dnf but also dnf. The patch should solve\nit.\n\nCloses: #525\nApproved by: ignatenkobrain', 'author': {'name': 'Jaroslav Mracek', 'email': '[email protected]', 'username': 'j-mracek'}, 'added': []}], 'ref': 'refs/heads/auto', 'forced': True, 'after': '75cddcb9db87af68d1034af80b88e9f4250f9f62', 'pusher': {'name': 'dnf-bot', 'email': '[email protected]'}, 'base_ref': None, 'sender': {'id': 10563235, 'type': 'User', 'site_admin': False, 'gravatar_id': '', 'login': 'dnf-bot'}, 'organization': {'id': 8504469, 'description': '', 'login': 'rpm-software-management'}, 'created': True}

I see that test was successful, but nothing is pushed to master. Let me know which information is needed.

Latest homu not accepting r+ shorthands

I was testing it locally and it seems like homu no longer accepts @bors-servo r+. This is because r+ is a two-step process -- homu will leave a comment saying "commit <sha> approved", which contains a fully-qualified @bors-servo r=username SHA in an HTML comment. It then parses that, and approves the PR.

This was broken in https://github.com/servo/homu/pull/77/files#diff-9f3f3e773e33ae0ef2bc051f79e89e46R283 cc @cgwalters

Explain delegation more clearly

See #53 for a first attempt at improving the explanation and the conversation about why it was incomplete.

Homu commenting "Test successful" twice

I have "Allowed Failures" and "Fast Finish" in my travis build, which means homu is notified twice.

PR comment

Cleaned-up logs.tar.gz (separated the logs into an index and xxNN.json files and the json files are linked from the log lines)

Submodule updates wreak havoc on a queue

In rust-lang/rust we're in the process of making a few changes to the repository's submodules. We're moving submodules around and also extracting out components to submodules. Unfortunately this seems to cause homu to think there's merge conflicts when there doesn't appear to be any on GitHub at least.

Rebasing does fix the issue though.

[rfc] command to squash and merge

It is common in the rust repo for at least small changes that reviewers ask the contributor to squash the changes before they're merged. (For example rust-lang/rust#38158 (comment).)

To avoid another round-trip to the contributor, perhaps Bors/Homu could be given a command to squash and merge, ie to do git commit --merge?

Looking at the code there seems to be a per-repo option for autosquash but Rust might want it to be per-PR.

support per-PR configurable statuses?

Homu was started with the idea that the master branch should pass "all" of the tests. However, for some projects, one really wants different definitions of "all".

The "rollup" model admits that some PRs (e.g. to docs) aren't going to break anything, so should just be aggregated with others and you only have one potentially expensive test run.

Many people configure their build system (e.g. Jenkins) to listen for optional text like "bot, run extended tests" - basically one status, but the test sometimes does more expensive things.

It might be interesting however to have Homu know about multiple statuses, and optionally tell Homu to watch for them.

Something like:

@homu test=extended
@homu r+ a12bc3d

The advantage of this is that one can clearly see in the PR which test suites were run.

single global queue?

I may be wrong about this, but I was investigating some slowness and am just now realizing that there's apparently a single global queue for builds across multiple repos.

def process_queue(...)
    for repo_label, repo in repos.items():
        for state in repo_states:
            if state.status == 'pending' and not state.try_:
                break
            ...
            elif state.status == '' and state.approved_by:
                if start_build_or_rebuild(state, repo_cfgs, buildbot_slots, logger, db, git_cfg):
                    return
           ...

Why do the start_build() cases use return in contrast to the first one which is just break? This means if any build was started, we skip processing of any other ones.

Add a closed tree state

It should be possible to prevent any further PRs from merging unless they are explicitly marked as being allowed to merge when the tree is closed.

HTTP_X_HUB_SIGNATURE errors

411 eventually built, but these are the last saltfs-related entries in Homu's log before servo/saltfs#416 is reporting the events as successfully delivered but Homu isn't building it. Looks like the github API changed something on us.

Starting build of servo/saltfs#411 on auto: accdddc5d14a4511e95ee4caee5c2ebb4d3eac10
INFO:homu:Starting build of servo/saltfs#411 on auto: accdddc5d14a4511e95ee4caee5c2ebb4d3eac10
Traceback (most recent call last):
  File "/home/servo/homu/_venv/bin/bottle.py", line 862, in _handle
    return route.call(**args)
  File "/home/servo/homu/_venv/bin/bottle.py", line 1732, in wrapper
    rv = callback(*a, **ka)
  File "/home/servo/homu/homu/server.py", line 230, in github
    hmac_method, hmac_sig = request.headers['X-Hub-Signature'].split('=')
  File "/home/servo/homu/_venv/bin/bottle.py", line 1978, in __getitem__
    return tonat(self.environ[self._ekey(key)], 'latin1')
KeyError: 'HTTP_X_HUB_SIGNATURE'
Traceback (most recent call last):
  File "/home/servo/homu/_venv/bin/bottle.py", line 862, in _handle
    return route.call(**args)
  File "/home/servo/homu/_venv/bin/bottle.py", line 1732, in wrapper
    rv = callback(*a, **ka)
  File "/home/servo/homu/homu/server.py", line 230, in github
    hmac_method, hmac_sig = request.headers['X-Hub-Signature'].split('=')
  File "/home/servo/homu/_venv/bin/bottle.py", line 1978, in __getitem__
    return tonat(self.environ[self._ekey(key)], 'latin1')
KeyError: 'HTTP_X_HUB_SIGNATURE'
Traceback (most recent call last):
  File "/home/servo/homu/_venv/bin/bottle.py", line 862, in _handle
    return route.call(**args)
  File "/home/servo/homu/_venv/bin/bottle.py", line 1732, in wrapper
    rv = callback(*a, **ka)
  File "/home/servo/homu/homu/server.py", line 230, in github
    hmac_method, hmac_sig = request.headers['X-Hub-Signature'].split('=')
  File "/home/servo/homu/_venv/bin/bottle.py", line 1978, in __getitem__
    return tonat(self.environ[self._ekey(key)], 'latin1')
KeyError: 'HTTP_X_HUB_SIGNATURE'
Traceback (most recent call last):
  File "/home/servo/homu/_venv/bin/bottle.py", line 862, in _handle
    return route.call(**args)
  File "/home/servo/homu/_venv/bin/bottle.py", line 1732, in wrapper
    rv = callback(*a, **ka)
  File "/home/servo/homu/homu/server.py", line 230, in github
    hmac_method, hmac_sig = request.headers['X-Hub-Signature'].split('=')
  File "/home/servo/homu/_venv/bin/bottle.py", line 1978, in __getitem__
    return tonat(self.environ[self._ekey(key)], 'latin1')
KeyError: 'HTTP_X_HUB_SIGNATURE'

Handle mergeability errors more gracefully

I'm seeing a mergeability error of the following form quite frequently in the log:

INFO:homu:Starting build of servo/servo#15142 on try: 4675448367063a6e2043c0cc4559f79695348f76
* Error while fetching mergeability
Traceback (most recent call last):
  File "/home/servo/homu/_venv/lib/python3.4/site-packages/homu/main.py", line 754, in fetch_mergeability
    mergeable = state.get_repo().pull_request(state.num).mergeable
AttributeError: 'NoneType' object has no attribute 'mergeable'

We should either retry when state.get_repo().pull_request(state.num) returns none, or just set mergeable to false upon failure to retrieve the mergeability state. (see https://developer.github.com/v3/pulls/)

This is pretty low-hanging fruit for a Pythonista and you're welcome to ping me on IRC if you'd like any guidance on it.

[rfe] support multiple github assignees

at some point github started supporting multiple assignees for issues/PRs, but /queue shows only first.

https://developer.github.com/v3/issues/assignees/

Probably this should be fixed at first in github3py, not sure.

Make r+ by a delegatee infer the delegator

This will prevent a common source of incorrect historical metadata in the commit log.

Homu should comment on pull request if Travis CI fails

Or at least an option to turn that on

Make homu ignore quotes for commands.

See, for example, servo/saltfs#512 (comment), where I replied by mail to a comment, and homu thought that I had approved the PR.

r- force has a weird outcome

See rust-lang/rust#33441 (comment).

Namely, it should behave as if plain r- (i.e. cancel the build) without printing any messages. Currently it takes another PR on top of the queue and “forces” that.

Add a link to the GitHub repository for queue

See #8 for a rough solution and comments on why it wouldn't quite work.

UnboundLocalError

We're getting the following error on some WebRender PRs:

Traceback (most recent call last):
  File "/home/servo/homu/_venv/bin/bottle.py", line 862, in _handle
    return route.call(**args)
  File "/home/servo/homu/_venv/bin/bottle.py", line 1732, in wrapper
    rv = callback(*a, **ka)
  File "/home/servo/homu/_venv/lib/python3.4/site-packages/homu/server.py", line 392, in github
    realtime=True,
  File "/home/servo/homu/_venv/lib/python3.4/site-packages/homu/main.py", line 392, in parse_commands
    if 'authzfail' in res.text:
UnboundLocalError: local variable 'res' referenced before assignment
^C

cc @Manishearth @edunham

Consider showing the Travis status in the homu queue

Try not using a try branch?

On the Servo builds, we seem to only be pushing to auto. The default should have been to push to try for try builds and auto for auto builds, but I suspect that our move to multi-mode (buildbot+status from appveyor) is causing us to only use auto. The relevant code is here:
https://github.com/servo/homu/blob/master/homu/main.py#L563-L572

This is manifesting as a LOT of failed appveyor builds, as the repeated pushes over the auto branch are causing enqueued builds to later fail, as auto has something else pushed over it by the time the appveyor queue gets to it.

@Manishearth Does this sound right?

CC: @edunham

Add command to confirm that Homu is listening

There are 2 cases in which users spam retry on a PR: When it really needs to be retried, and also when they're testing whether Homu is listening at all.

To reduce ambiguity, it would be nice to add a "@bors-servo: hello?" command, to which Homu would simply answer "@username: Hi there!" or equivalent. This way it would be clear which messages are simply debugging whether the bot is listening, vs which actually want a build to be kicked off.

Travis/AppVeyor may miss a webhook

Occasionally (likely due to the nature of webhooks) either Travis or AppVeyor may not actually start a build once a merge commit is created on the auto branch. For example with rust-lang/rust#39518 when homu started a build it scheduled a build on Travis but not AppVeyor (configured for the repo at this time).

It'd be awesome if homu would automatically detect this and retry the build if AppVeyor/Travis don't come back with a "build started" in a grace window of something like 5 minutes.

Make queue show number of approved PRs

The count labeled "approved" on http://servo-master.servo.org:54856/queue/servo is something like (try success + pending + approved) (although maybe with an off by one error?); when you just want to see how backed up the queue is, counting the number of PRs marked approved is annoying.

Report failures for all platforms

This has always been a frustration for me, since the first platform that fails gets a comment with a link and you have to hunt for other ones if there are per-platform failures. With the addition of appveyor, when the service has a network hiccough then we don't get any status report for the non-windows platforms at all.

set up homu for this repo?

Transition Travis CI webhook token to webhook signatures

See https://blog.travis-ci.com/2016-08-31-webhook-delivery-changes

Using the GitHub Token field for authorizing webhook requests is being replaced with a public/private signing infrastructure, with the old method being removed November 1st. Presumably that would mean that homu instances using the token method with Travis CI would cease to function on that date.

The new authorizing webhook actually simplifies things as a special token will no longer be required for repos connecting with a homu server.

Don't abbreviate commit hashes in Homu's comments

Abbreviating them can be ambiguous, cf. servo/servo#14959 (comment)

a way to answer "what is this PR waiting for"

`retry` doesn't work with GitHub status (and local git)

After I issue @$BOT retry, homu resets the status of the PR on the queue but doesn't re-trigger a new CI build, AFAICT it doesn't touch the auto branch again.

I think homu should git push -f to the auto branch (same commit contents but generates a different commit hash) after a retry command is issued.

Make `main.db` location configuration in cfg.toml

We (Servo) recently deleted our main main.db database by accident while debugging a Homu problem; the /home/servo/homu directory was blown away and the database with it.

To make it harder to blow away the database inadvertently, the Homu database location should be configurable from the cfg.toml configuration file.

Files:

homu/main.py

Choking on Unicode in PR descriptions/titles

Whenever we've seen a PR with a non-ascii character description and/or title we get backtraces like:

Feb 12 17:16:38 4ad3f3e4b78a homu: Traceback (most recent call last):
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/usr/local/bin/bottle.py", line 862, in _handle
Feb 12 17:16:38 4ad3f3e4b78a homu:     return route.call(**args)
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/usr/local/bin/bottle.py", line 1740, in wrapper
Feb 12 17:16:38 4ad3f3e4b78a homu:     rv = callback(*a, **ka)
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/homu/homu/server.py", line 400, in github
Feb 12 17:16:38 4ad3f3e4b78a homu:     g.queue_handler()
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/homu/homu/main.py", line 1239, in queue_handler
Feb 12 17:16:38 4ad3f3e4b78a homu:     return process_queue(states, repos, repo_cfgs, logger, buildbot_slots, db, git_cfg)
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/homu/homu/main.py", line 905, in process_queue
Feb 12 17:16:38 4ad3f3e4b78a homu:     if start_build_or_rebuild(state, repo_cfgs, buildbot_slots, logger, db, git_cfg):
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/homu/homu/main.py", line 890, in start_build_or_rebuild
Feb 12 17:16:38 4ad3f3e4b78a homu:     return start_build(state, repo_cfgs, *args)
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/homu/homu/main.py", line 794, in start_build
Feb 12 17:16:38 4ad3f3e4b78a homu:     merge_sha = create_merge(state, repo_cfg, branch, git_cfg)
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/homu/homu/main.py", line 549, in create_merge
Feb 12 17:16:38 4ad3f3e4b78a homu:     '--no-ff', '-m', merge_msg))
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/homu/homu/utils.py", line 68, in logged_call
Feb 12 17:16:38 4ad3f3e4b78a homu:     subprocess.check_call(args, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/usr/lib/python3.5/subprocess.py", line 576, in check_call
Feb 12 17:16:38 4ad3f3e4b78a homu:     retcode = call(*popenargs, **kwargs)
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/usr/lib/python3.5/subprocess.py", line 557, in call
Feb 12 17:16:38 4ad3f3e4b78a homu:     with Popen(*popenargs, **kwargs) as p:
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
Feb 12 17:16:38 4ad3f3e4b78a homu:     restore_signals, start_new_session)
Feb 12 17:16:38 4ad3f3e4b78a homu:   File "/usr/lib/python3.5/subprocess.py", line 1490, in _execute_child
Feb 12 17:16:38 4ad3f3e4b78a homu:     restore_signals, start_new_session, preexec_fn)
Feb 12 17:16:38 4ad3f3e4b78a homu: UnicodeEncodeError: 'ascii' codec can't encode character '\u2019' in position 111: ordinal not in range(128)

Right now my solution is to just edit out the characters and then retry, but would be great to support this natively!

add example systemd service to start homu

starting via terminal in screen/tmux is definitely cool, but to use in production it would be nice to see systemd unit.

Strip reviewable boilerplate from PR message when creating merge commit

We get

<!-- Reviewable:start -->

---
This change is [<img src="https://reviewable.io/review_button.svg" height="35" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/saltfs/356)
<!-- Reviewable:end -->

in merge commits, like servo/saltfs@39ef354, on repos where we use Reviewable. It would be nice to omit the Reviewable boilerplate when creating the merge commit message.

commit message rewriting breaks with signed commits

See projectatomic/container-storage-setup#179 ➡️ projectatomic/container-storage-setup@f7a3746

fast forward for status commits too

Right now we have code that special cases Travis to detect the case when a PR is green, and the item is first in the queue. This avoids re-testing.

There's no reason this can't generalize to generic status (I'm using Jenkins).

Support MAINTAINERS file

Migrated from barosl#125

In practice, changing this is what is causing me to restart homu a lot. (Which has its own problems - if we miss an event due to downtime one has to go and manually resync)

[rfe] have homu indicate when it did not understand or ignored a command

I find I often type a command to homu and either get it wrong or the issue is in the wrong state for the command to be acted upon. It would be nice if homu indicated somehow (a new comment, or a reaction, or editing the original comment that had the command) that it ignored the command.

Editing a r+ comment makes bors think the approval was done twice

If a comment with r+ has been edited then homu will emit

💡 This pull request was already approved, no need to approve it again.

There's another pull request that is currently being tested, blocking this pull request: #,,,

Instead, homu should check that the edit didn’t change the r-state and do nothing if so.

Odd "approved by" message

See servo/servo#10650 (comment):

:pushpin: Commit d09a497 has been approved by ``

Show Travis CI status (via GitHub status API) for each PR on the queue page

https://buildbot.rust-lang.org/homu/queue/rust

It'd be super helpful to see what approved PRs are failing so one can take them off the queue

internal server error when trying to synchronize all PRs

Error: 500 Internal Server Error

Sorry, the requested URL 'http://ci.dnf.baseurl.org:54856/callback?code=xxx&state=%7B%22cmd%22%3A%22synch%22%2C%22repo_label%22%3A%22all%22%7D' caused an error:

Internal Server Error

We have 2 repos in config: dnf and dnf-plugins-core, so I opened /queue/all and clicked syncronize PRs and it failed.

support github3.py 1.0.0+

upstream of github3.py already published 4th alpha version, so it would be great to get support for it, because currently it fails:

Traceback (most recent call last):
  File "/usr/bin/homu", line 9, in <module>
    load_entry_point('homu==0.2.0', 'console_scripts', 'homu')()
  File "/usr/lib/python3.5/site-packages/homu/main.py", line 908, in main
    user = gh.user()
TypeError: user() missing 1 required positional argument: 'username'