RBCommons 3.0 is Live!

Over the weekend, we deployed a new major version of RBCommons, offering many new features and laying the groundwork for additional ones we’ll be bringing you soon.

 

New code review capabilities, including revokable Ship-Its, general comments not tied to code or file attachments, and the ability to require verification before issues are resolved.

Discussions are now easier to follow. New updates, reviews, and replies are highlighted in blue, helping them stand out. Desktop notifications let your browser notify you when there’s new updates to the page. Images can be dropped into text fields to provide some visuals with your comment. Emoji shortcodes can be used.

New repository support for Bitbucket Server, AWS CodeCommit, and Gerrit. Host your code there, review it here.

Feature improvements are everywhere. Custom avatar images can be set on your account. There are handy buttons for quickly navigating between file attachments. High-DPI image attachments are scale to fit on your screen. Review requests can be re-assigned to other team members.

RBCommons is faster. Along with optimizations in the new version, we’ve also begun moving parts of our architecture onto new servers, with more coming this week. You should start seeing those benefits soon.

See all the new features available today!

 

Coming soon, we’ll be bringing integrations with Slack and Mattermost chat, continuous integration with Travis CI and CircleCI, support for searching review requests, and new billing improvements (separate billing contact and administrative roles, and CC’ing invoices to an address of your choosing). We’re still testing these internally, and plan to start rolling these out in stages over the next couple months.

We hope you like the new RBCommons! As always, if you have any questions or hit any problems, we’re only a chat message away 🙂

Read More

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

ChangeLog: Catching Up

It’s been too long since we last ran the ChangeLog series, and felt it was the right time to start it back up again. ChangeLog is a look into the latest behind-the-scenes work going into Review Board, RBCommons, and other Beanbag projects. While intended to be a weekly series, we’d like to start off with some of the bigger tasks and feature development from the past month.

Moving to Django 1.11 and Python 3

Today, all current versions of Review Board depend on Django 1.6, an old release that’s no longer supported by the Django project but is by us, and doesn’t support modern Python 3 releases.

We’ve been stuck on 1.6 because 1.7 introduced (and later mandated) a new way of handling database migrations, which is incompatible with the method we’ve always used. Reconciling the differences has been a challenge.

In the past month, we’ve made significant progress toward both the Django and Python updates:

  • Djblets 2.0 (our development release) is now compatible with Django 1.6 through 1.11 and Python 2.7, 3.4, 3.5, and 3.6.
  • Django Evolution (used for database migrations) now works with Django 1.6 through 1.11 and Python 2.7, 3.4, 3.5, and 3.6. Work’s being done to let it co-exist with Django migrations now.
  • Review Board has started receiving patches for Django 1.11 and Python 3.5+ now. This is still in development, and likely won’t make the Review Board 4.0 release, but will be there for 5.0.
  • RBTools 1.0 (shipping in a few months) now has full Python 3 support.

New Release Schedules


We’ve began moving to a train model for releases, and have all of our main and upcoming products now on the calendar.

Here’s what this currently looks like:


  • Review Board 4.0 (with DVCS support!) is expected to ship in August, 2018
  • Review Board 3.0.x releases will ship (generally) every other Tuesday
  • RBTools 1.0 is expected to ship April 12th
  • RB-Gateway is expected to ship March 28th

We’re planning to release a new major Review Board release every ~6 months, meaning smaller but more frequent releases. We’re still experimenting with the schedule and timeframe for these releases.

RB-Gateway

We’ve releasing RB-Gateway 1.0 this month. This is a microservice designed to sit in front of a Git or Mercurial repository, providing an API and set of integrations that can be used by Review Board or any other tool or service for more deeply working with your repository.

RB-Gateway doesn’t change your workflow, and can be dropped in with minimal effort. It completely replaces the cgit/gitweb workaround for standalone Git repositories, and means you don’t need to set up something more complicated like GitLab just to work with Review Board.

You’ll see more information on RB-Gateway’s capabilities when we release later this month, and we’ll cover improvements being made to it here.

Wrapping Up…

Those are really just the major highlights, to get everyone up to speed. It doesn’t include the new features we’ve recently built, like being able to filter files in the diff viewer based on filename patterns, a new command for creating Review Board extension source trees, the work done on kgb, or the crazy investigation into deadlocks that’s delayed Review Board 3.0.4.

Going forward, these will be smaller, covering only what’s been done over the past week. If you like these posts, and want to see this continue, please let us know! You can find us on reddit or on the community support list.

Read More

Announcing kgb 2.0 for Python – Function spies for unit tests

We’ve just released a new major version of kgb, a Python library for creating function spies in unit tests. This is a very handy tool for helping craft unit tests in Python applications.

kgb 2.0 introduces support for Python 3.6, improves argument checking, and removes the need for a special .spy attribute on standard functions.

What are function spies?

Function spies allow you to listen for when functions are called, what parameters they were passed, what value they returned or exception they raised, and allow you to disable the function’s normal behavior and optionally replace it with your own. This is a popular feature of Jasmine, a testing framework for JavaScript.

They’re particularly useful when working with third-party libraries whose behavior you cannot normally change. For example, your project might call a function in a library that in turn calls out to a HTTP server, which might be problematic for your unit test. With kgb, you can simply spy on urllib2.urlopen and return a custom result.

For example:

import logging
from unittest import TestCase
from urllib2 import urlopen

from kgb import SpyAgency


class MyTests(SpyAgency, TestCase):
    def test_http_request(self):
        def _fake_urlopen(opener, *args, **kwargs):
            self.assertEqual(url.get_full_url(),
                             'https://example.com/123/')

            class FakeResult(object):
                def read(self):
                    return 'Your fake payload goes here!'

            return _FakeResult()

        self.spy_on(urlopen, call_fake=_fake_urlopen)

        # Imagine that this function makes an HTTP request to
        # https://example.com/123/ and logs a message.
        some_function_that_does_urlopen()

        self.assertTrue(urlopen.called)
        self.assertTrue(logging.info.called_with(
            'Fetching something from an API'))

What’s new in kgb 2.0?

Better, more consistent spies

We removed the distinction between spying on standard functions and methods on classes. This used to be treated differently. Previously, you could call spy functions like .called_with() and access attributes like .last_call directly on the method, but for functions, you had to use .spy.called_with() and .spy.last_call. We also kept plain functions mostly intact, but replaced methods on a class with a method-like object designed to intercept calls and mimic the method’s signature. That meant things were different depending on what you were spying on.

We now keep the methods where they are, bringing the spy functions and attributes onto the spied functions directly. We also use a special bytecode injection process for all spying operations (it’s very complicated, but awesome).

What does this ultimately mean? Well, it means if you had code from older versions that looked like this:

self.assertTrue(my_func.spy.called)

You can trim off the .spy part:

self.assertTrue(my_func.called)

It also means that we’re spying at a lower level than before for methods on classes, helping to prevent problems with code that’s sensitive to methods being replaced.

And it gives us Python 3.6 support.

Python 3.6 and PyPy support

See, there it is!

kgb 2.0 now fully works with Python 3.6. And as a bonus, PyPy as well.

More flexible and descriptive argument checks

called_with() now lets you check positional arguments by specifying their names as keyword arguments, and doesn’t require that you check for all arguments passed to the function. For example, if you have this method:

def my_func(a, b, c=123):
    pass

you can inspect the calls with:

self.assertTrue(my_func.called_with(b=True))

Hand-holding when things go wrong

If something goes wrong in your test suite and your spy fails to unregister at the end of the test, you could get some pretty confusing assertion errors in older versions of kgb. Same if you accidentally try spying on the same function twice in your tests.

In kgb 2.0, we check for this and present a very helpful error showing you exactly where the spy was originally set so you don’t have to hunt it down yourself.

Learn more about kgb

We’re biased, but this is a really nifty library, and has made our lives so much easier. We have full documentation up on GitHub showing all the ways you can work with spies, along with a FAQ.

Installation is easy. Just run:

$ pip install kgb

kgb supports Python 2.6 through 2.7 and 3.4 through 3.6, along with new, experimental support for PyPy.

If you find kgb useful, please tell others about it, and give it a star on GitHub.

Read More

RBCommons updates have moved to the Beanbag Blog

For years, we’ve been maintaining three separate blogs for our products: the RBCommons Blog, Review Board News, and the Beanbag Blog. It made sense at the time to keep these separate, but these days it’s usually more confusing than it needs to be, with release announcements and helpful guides scattered across the blogs.

We began the process of consolidating these last night, and started with merging the RBCommons Blog into the Beanbag Blog. Unfortunately, due to a glitch with our mailing list provider, an e-mail went out today covering last February’s CloudFlare-related security issue. If you received this, we’re very sorry — that shouldn’t have happened, and you don’t need to worry about some new problem affecting RBCommons.

We’ll be posting more articles here going forward, along with RBCommons updates and RBTools release announcements. We recently started a series of articles on new Review Board features that will soon make its way to RBCommons as part of a major update we’re gearing up for.

We’re also planning to move the Review Board release announcements here, so there’s exactly one place to look for everything we’re working on.

And with that, we’d like to thank you all for being such wonderful customers. Have a Happy New Year, everyone! Here’s to a great 2018 🙂

Read More

Introducing Issue Verification and Ship-It! Revocation

We’ve all been there…

It’s a week before the deadline. Your team is working through the night, eager to land their changes as quickly as possible. Your teammate, Jake, was feeling frazzled as he was trying to fix all the issues that had been filed on his review request. He’d just finished the issue you had filed and marked it “fixed.” Shortly after, another teammate files a new review with a “Ship It!” Breathing a sigh of relief, and eager to go home, Jake immediately lands the change.

It wasn’t until after the release of the product that you realized Jake had missed something important in your feedback. While his change had fixed the bug, it had broken another feature. You hadn’t had the chance to look over his change after he’d fixed it, since you were busy and it had fallen off your dashboard once it landed. If only Jake knew you wanted to take a second look, the release would have gone a lot more smoothly.

With Review Board 3.0, you can prevent this from ever happening again. We’ve added a new feature, Issue Verification, which keeps issues open until the reviewer has a chance to verify the fix.

You can activate this feature by checking the “Require Verification” box when opening a new issue.

 

 

Once the owner of the change resolves the issue as “Fixed” or “Dropped,” the status will change to “Pending Verification.” At this point, the issue is still considered open. It will be up to the reviewer to look over the fix and click “Verify Fixed” before it can be closed.

 

Filed a Ship It! prematurely and wish you could take it back?

Now you can with Review Board 3.0’s new Revocable Ship It! feature. The “Ship It!” label on any reviews you file will now have a little “x” button. Just click and confirm that you want to revoke it, and the review’s “Ship It!” tag will be removed, with the “Ship It!” text crossed out in the review.

 

 

These new features will help ensure that important reviewer feedback is addressed and that an unintentional or outdated “Ship It!” review no longer lets changes into the codebase prematurely. These features have been requested by many of you, and we would love to hear if they improve the review process for your team!

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

RBTools 0.7.10 is now out

Today’s release of RBTools 0.7.10 some important compatibility fixes for macOS, Git, Subversion, Team Foundation Server, ClearCase.

macOS and Browser Windows

macOS users who have upgraded to recent releases of Sierra lost the ability to run rbt post --open (to open the posted review request in a browser window) due to a Python/AppleScript bug. This is Python bug #30392, for those who are interested.

We’ve worked around this. Your default browser will work once again. Thanks to those who pointed this out!

There’s also a whole new macOS installer coming that should actually work on all setups. We’ll have this on the Downloads page once it gets a little more testing.

Git and Git-SVN

Git-SVN users should no longer encounter crashes when trying to post changes for review. That was pretty disruptive.

Git repositories with submodules containing pending changes no longer cause warnings about dirty repositories when posting changes. They’re not included anyway, and just added to the confusion.

Crazy Subversion Diffs

If you had a line of code being deleted that happened to look like a diff header (say, --- XX (YY)), it could cause some code we have for fixing up diffs to get very confused. That, unfortunately, could lead to lines being excluded from the diff, breaking when you try viewing it in the diff viewer.

We’ve rewritten this code to be very careful about these lines. It won’t get confused again.

Team Foundation Server and Visual Studio 2017

Team Foundation Server users who have upgraded to Visual Studio 2017 can once again post changes. TFS has had a nasty habit of changing their file formats, APIs, and command line options, but after much tearing out of the hair, we’ve restored compatibility.

All versions from Visual Studio 2011 onward should work just fine, so no need to upgrade to 2017 just to use this release.

We’ve also fixed a regression when using the Team Explorer Everywhere adapter.

ClearCase and Cross-Platform VOB Lookups

ClearCase users can now name their repositories in Review Board based on a component of a VOB path, instead of naming it based on the entire VOB path. This helps with the differences in how ClearCase represents VOB paths on different platforms. For instance, a VOB path of /vobs/MyVOB or C:\vobs\MyVOB will now match a repository name of MyVOB.

There are also some performance improvements for looking up VOBs.

And Other Such Things

There are improvements to the Python API, such as not prematurely exiting the process, plus compatibility fixes for Review Board 3.0. We’ve also added a new config option to disable certain warnings in RBTools, which would be especially useful for repository hook scripts.

For the complete list of changes, see the release notes.

To upgrade RBTools, visit the downloads page.

Read More

RBCommons and Cloudflare: Don’t worry, be happy!

There was a major security breach announced this week by Cloudflare, a popular service used by millions of sites. This security breach affected customers around the world, causing passwords, API tokens, private conversations, and more to be leaked into search engines and people’s browser sessions.

You probably have a lot of passwords you’ll need to change this week, but don’t worry, RBCommons does not use Cloudflare, nor do the services RBCommons depends on. Your information is safe!

We recommend that you take the time to ensure you’re using strong, unique passwords (ideally stored in a password manager like 1Password or LastPass), and enable two-factor authentication on RBCommons to make your account even more secure.

To learn more about the Cloudflare security breach, and how it affects you, read their disclosure and see the list of sites using Cloudflare to see if you may be at risk.

Read More

RBTools 0.7.7 is released!

We’ve just put out an all-new release of RBTools. Version 0.7.7 features compatibility fixes for various types of repositories, better support for TFS, and some new features to help with common usage and automation.

You can see the release notes for the full list of changes. We’ll go over the highlights here.

Compatibility/bug fixes

In this release, we’ve aimed to fix a handful of compatibility problems that have been reported to us. Thanks to all the contributors who sent patches!

  • RBTools is once again compatible with Mercurial 2.x. This regressed in 0.7.6.
  • Some error displays are fixed when using the version of Python shipped with macOS 10.11.
  • Perforce gained the ability to post against null client roots, and fixed posting ranges of submitted changelists.
  • Repository lookups utilizing mirror paths or Subversion UUIDs now work once again. These regressed in 0.7.6.
  • rbt post for Git now supports --exclude-patterns when using git-svn or git-p4.
  • rbt land no longer crashes if it can’t determine the approval state on a review request.

Improved Team Foundation Server support

The old TFS support was a bit slow, due to the way we had to interact with the Team Foundation Server command line tools. It also presented compatibility problems, as different versions of Visual Studio shipped different, incompatible versions of these tools.

We’ve now introduced new support that doesn’t depend on their tools and is optimized for our use cases. This means better compatibility everywhere, faster posting, and new features.

To start with, we’re adding the ability to post shelved changesets! You can do this by simply running:

rbt post <shelveset-name>

To begin using RBTools 0.7.7 with TFS, you will need to install our new TFS adapter by typing:

rbt install tfs

New features

We’ve added the ability to specify a destination tracking branch for rbt land. To choose something other than the default (say, origin/master on Git), you can now specify:

rbt land --tracking-branch <branch-name>

If you find yourself needing to pass --svn-prompt-password all the time for your Subversion setup, you can set SVN_PROMPT_PASSWORD in your project’s or user’s .reviewboardrc instead. Just set this and you’ll never have to type it again:

SVN_PROMPT_PASSWORD = True

What’s coming next

We’re working toward a RBTools 1.0 release, which will feature enhanced support for Mercurial, new automation commands for use in the upcoming Review Board 3.0, easier setup and installation, and better display of progress when posting changes.

We’re also hard at work on a rewrite of our documentation, with the aim of providing more practical, detailed setup and usage guides for RBTools. These will begin to land over the next month.

If you have any bug reports or feature requests for either RBTools or the documentation, we’d love to hear them! You can file a bug or reach out to us on our reviewboard-dev discussion list.

Read More