ChangeLog: New Integrations, Releases, and Prep for RBCommons 3.0

We’ve had a really busy couple of weeks since the last ChangeLog. There were two Review Board releases, a small setback with RB-Gateway, and lots of testing and infrastructure work for RBCommons 3.0.

Review Board 3.0.4 and 3.0.5

Last week, we put out Review Board 3.0.4, a feature-packed release introducing:

It was a pretty great release, fulfilling a lot of feature requests we’ve had for a while an providing the foundation for some new work we’re doing. Unfortunately, there was a last-minute error that, in production, broke part of the form for repository configuration.

Really embarrassing.

Now, we’ve found most people don’t upgrade the same day that a release goes out (downtime must be scheduled, people are busy, etc.) so we mostly started hearing about it two days later. As soon as we realized the mistake, we quickly got a new release out, Review Board 3.0.5, and put some changes in place to help prevent this sort of last-minute problem from happening again.

The good news is that, in the meantime, we went through and fixed a bunch of bugs that didn’t make the 3.0.4 release, but were ready for 3.0.5. So really, we’re just hoping we can all pretend 3.0.4 was just a pre-release for 3.0.5 now 🙂

Review Board 3.0.6 is currently scheduled for April 10th. I’m expecting it to go smoothly.

RB-Gateway Difficulties and Delays

RB-Gateway, our API wrapper around Git and Mercurial repositories, was supposed to release, well, today. Sadly, that’s not happening.

Let me back up. RB-Gateway is written in Go, unlike most of our projects which are Python-based. Go was chosen partly due to concurrency benefits for handling and serving up requests, and partly for its ease of cross-compilation and distribution (just drop it into a directory and run it on any supported platform).

It’s the cross-compilation that posed a problem. We use git2go, a Go wrapper around libgit2, a C library for talking to Git repositories. We don’t need a lot from it, but it made sense to “go” with that (sorry).

Problem is, including a C library makes cross-compilation much harder, and there’s threads full of discussions on issues with compiling and utilizing git2go in production, depending on how it’s compiled and used. So we’re planning to remove git2go usage.

Instead, we’re evaluating other Git libraries. We probably won’t roll our own, but as we don’t really need much from a Go library, we’ll “go” that route if we need to (sorry).

When that’s done, we should be ready to release.

Prep for RBCommons 3.0

This Friday, we’re beginning an upgrade of RBCommons, bringing many of the features of Review Board 3.0 to the service. We’ve spent much of this week getting this ready — rebuilding servers, testing database migrations, running through checklists of manual feature tests, etc.

There’s going to be a lot to love in this release, but those following Review Board development will surely notice that some features (such as Slack, Asana, etc. integrations) will not be there on launch. We have just a bit more work to do before those are ready. We want those as much as anybody, so they’re high up on the priority list.

The blocker right now is that the administration pages for some of these features are built to plug into the Django administration page, not the custom RBCommons team administration page. So there’s still some work to do before that’s complete. Soon, though!

The upgrade should be smooth, and we should be back up in only a few hours, but just in case, we’re leaving the maintenance window open through Sunday. We aimed for a holiday weekend (well, holiday for a lot of people, anyway) to reduce the impact on users.

Read More

Introducing Slack Support in Review Board 3.0

One of the highlights of the recently release Review Board 3.0 is our new integration with Slack. Projects and companies around the world use Slack for communication and collaboration within their teams. It also hooks into third-party products and services to provide live updates in chat. By enabling the Slack integration in Review Board 3.0, you will be able to keep your team informed of discussions and updates on review requests as they happen.

 

 

You can create as many Slack configurations as you need for your company. Each configuration can be customized based on your needs. For example, review requests for different groups can go to different channels. Those containing sensitive information such as security fixes can be filtered out entirely.

 

Getting Started

First, create an incoming Webhook integration on Slack. Once it has been created, Slack will generate a Webhook URL, which you’ll plug into Review Board in your new configuration. To create that configuration, open the Administration UI in Review Board and navigate to Integrations → Slack → Add A New Configuration. Paste your Webhook URL, like so:

 

 

Now you’re ready to customize your configuration by adding conditions. By default, a Slack configuration will post all discussions and updates to the channel. If you want to limit what’s posted, you can add one or more conditions to your configuration. These will operate off the data in the review requests being sent to Slack.

 

 

You have a lot of options when adding conditions. You can include or exclude messages depending on the review groups, repositories, summary and description content, branch field, and more. Custom extensions can even add new options, giving further control based on data and logic provided by the extension.

We hope this new integration will be a big help for your team members and your company as a whole. This has been a highly anticipated feature for some time now, requested by many of our users. We are excited to finally be able to bring it to you!

Read More