GitHub webhook to Reviewboard not working

44 views
Skip to first unread message

Ron A

unread,
Sep 19, 2019, 6:26:09 PM9/19/19
to Review Board Community
Hi, I have repository setup at github and it's linked to reviewboard 3.0 and I receive a 200 OK response.
The reviewboard server is on premise.

which seem to indicate once the webhook is inserted in the github repostiory everything will work. The instructions don't seem to be complete.
"Then click Add webhook. You're done!"

I would like to have reviewboard send out a review request with a link to a diff when a person has made a commit to the github repository.
I would also like to have reviewboard send out a notice when someone has reviewed a commit on reviewboard.
Is there a directory where a github webhook is located on the reviewboard server?
Does the mydomain.com url below need to reference the webhook by name?

The payload url is this according to the instructions.
https://mydomain.com/reviewboard/repos/3/github/hooks/close-submitted/

Instructions say to include the information below when closing a commit.
Review Request #123

I make a commit and push it to github but don't receive any notification.
Thanks, Ron



Christian Hammond

unread,
Sep 24, 2019, 5:51:03 AM9/24/19
to revie...@googlegroups.com
Hi Ron,

The built-in WebHook support for GitHub is used to automatically close review requests when a commit referencing the review request ID is pushed to the repository. It's an incoming WebHook that GitHub can send to (providing GitHub has the ability to reach your server), but it's not designed for custom uses.

It sounds like what you're looking to do is to have people post code for review by committing to the repository first? If so, that's what's generally referred to as a post-commit model, where the code is already in the codebase and is then going through review. A pre-commit model, where you post to Review Board first and only push to the repository after going through a successful review cycle, is recommended to ensure nothing slips through the cracks or ends up in the repository without approval.

If you're needing some sort of custom e-mails to be sent out when activity happens on your GitHub repository, then that's going to require custom work. You'd need something (whether an independent script of your own creation written in your language of choice, or an extension to Review Board written in Python) that GitHub can HTTP POST to, and then you'd need to configure a new WebHook entry in GitHub to point to that. Your script could take that commit and post it for review, or e-mail people, or whatever you'd prefer.

Review Board already does send out e-mails to any reviewers (individual people or configured review groups) whenever there's a new review or reply on a review request. Is there a different type of notice you're looking for, like making a comment on the commit on GitHub? If so, your custom script/extension would do that.

Christian



--
Supercharge your Review Board with Power Pack: https://www.reviewboard.org/powerpack/
Want us to host Review Board for you? Check out RBCommons: https://rbcommons.com/
Happy user? Let us know! https://www.reviewboard.org/users/
---
You received this message because you are subscribed to the Google Groups "Review Board Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/8c138fc3-9245-4867-8018-71862cef088e%40googlegroups.com.


--
Christian Hammond
President/CEO of Beanbag
Makers of Review Board

Ron T

unread,
Sep 26, 2019, 3:09:20 PM9/26/19
to Review Board Community
Hi Christian,
Yes the post-commit model is what I'd like to use. When I push to GitHub from local workstation how do I have a notification sent out with a diff from the on premise reviewboard server requesting a review of the code? 

The only hooks directory is on the local working directory on the users workstation at .gitHub/hooks

The reviewboard server is accessible from GitHub.

Thanks.

You received this message because you are subscribed to a topic in the Google Groups "Review Board Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard/HNAm-l2vxLQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to reviewboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/CAE7Vndmftas22Y4hVm8-B-y9SP0G6pvxDwC0eYuu1YBkeL27Wg%40mail.gmail.com.

Ron T

unread,
Oct 1, 2019, 2:10:54 PM10/1/19
to Review Board Community
Christian,
When a user commits or pushes from a GUI editor to their local repository which is a clone of their github repository, how do I get reviewboard to send out a notification? In this case they are not running the rbt post command because they are using a GUI.

I see that each local repository has a ./git/hooks directory.  Does a hook have to be written in that directory to be triggered on commit and/or push?
If so can the .git/hooks directory be accessed on github so a post-commit hook could be added for this purpose?  This way it would be accessible for anyone that clones the repository. Or is there a better way of doing this such as using a .reviewboardrc file?

Thanks.

You received this message because you are subscribed to a topic in the Google Groups "Review Board Community" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/reviewboard/HNAm-l2vxLQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to reviewboard...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/reviewboard/CAE7Vndmftas22Y4hVm8-B-y9SP0G6pvxDwC0eYuu1YBkeL27Wg%40mail.gmail.com.

Christian Hammond

unread,
Oct 1, 2019, 2:31:22 PM10/1/19
to revie...@googlegroups.com
Hi Ron,

I don't believe Git offers a way to force post-commit hooks to be installed in clones of a repository (likely for security reasons). They have a concept called "templates" which can auto-populate content in a cloned Git repository, but I don't think the repository you clone can control the templates. I think each person cloning would have to set it up individually. You may have to control all this in-house by making it part of the development and checkout process run by your engineers. Perhaps some sort of custom clone script, or a script that's run when people first set up a build from their cloned repository. It's outside the scope of Review Board, and not something we can help too much with.

If you wanted to run something when pushing to a repository, you'd have to write a small web service/script that GitHub can HTTP POST to. They have documentation on how to do that, but Review Board has nothing that's going to be able to help you here, as it's a bit outside the scope and would be a custom in-house workflow.

Christian

Ron T

unread,
Oct 1, 2019, 5:06:42 PM10/1/19
to Review Board Community
Hi Christian,
Is the approach I'm using more difficult than the norm?  I just want a review request generated during the process of writing code, people able to review it, etc.
What are others users doing to get a review request generated by an in-house reviewboard server using a github repository?
Do they have to use the command line or can they use a GUI?
I followed the Review Board instructions to setup a webhook to github but I think that is just for closing a review?

I don't understand this paragraph entirely.
If you wanted to run something when pushing to a repository, you'd have to write a small web service/script that GitHub can HTTP POST to. They have documentation on how to do that, but Review Board has nothing that's going to be able to help you here, as it's a bit outside the scope and would be a custom in-house workflow.
To clarify, are you saying, on the Review Board server I need to write a script that will listen for an HTTP POST coming from GitHub?
Would the script still need to use the rbt post commands?
Thanks!


Christian Hammond

unread,
Oct 1, 2019, 5:17:39 PM10/1/19
to revie...@googlegroups.com
Hi Ron,

The typical approach is for people to use the `rbt post` command to post a change for review. The workflow generally looks like this:

1) Create a branch, work on code, commit.
2) When ready for review, run: `rbt post`
3) Go to URL provided, fill out any fields you want to fill out, then publish the review request.
4) After receiving feedback, make changes on your branch. Then update your review request with: rbt post -u
5) Repeat until you get approval to land.
6) When ready to land, go to your destination branch (say, master) and use: rbt land <feature-branch-name>

RBTools (rbt post, and other related tools) give a lot of control for interfacing with review requests. rbt post and land, in particular, are very useful tools that we highly recommend when working with Review Board.

rbt post is responsible not only for creating/updating review requests based on local changes, but also making sure that diffs are generated correctly. There are a lot of ways to generate diffs, most of them useless to us (even by default), so RBTools takes care of generating them correctly (and even working around issues in the way that some types of repository tools generate diffs).

rbt land verifies that your review request has been approved (by default this means 1 or more Ship Its and no open issues -- this logic can be customized through Review Board extensions), and then lands it, formatting the commit message to include the review request description, testing that was done, bug numbers, and a link to the review request itself.

The GitHub webhook that Review Board provides looks for the link to the review request in any pushed commits. If it sees any, it closes that review request, keeping the dashboard nice and tidy.

So that's the standard approach, and it's what we recommend and design for. It gives developers complete control over their review requests and means you don't need to maintain any scripts that duplicate any of that work. If you did decide to write something to listen for commits and to post them automatically on behalf of users, you're still going to want to use RBTools to do the actual work. At that point, you might as well let the developers run it themselves, so they're in control.

We do not have a GUI wrapper for this, though I know some people have added shortcuts to their IDEs to invoke these commands (I do not have anything I can point you to there -- I think it's all been internal at companies).

Here's a guide we wrote up several years ago that goes into more detail on how we use RBTools ourselves: https://blog.beanbaginc.com/2015/01/26/an-effective-rbtools-workflow-for-git/

Christian

Reply all
Reply to author
Forward
0 new messages