Usage

Reviewer can be added to your workflow in several ways depending on how your development and release process work. Frequently, you might use it in different ways for each context.

Ultimately, it all boils down to the command line, and the other contexts are simply examples of how the command-line could be used in each context.

One of the major benefits of using Reviewer is that you can be confident that it will run your commands with the same settings across different contexts. So if you've got a highly-customized Rubocop setup, you won't have to keep track of the configuration options everywhere you run it.

• Command Line
• Guard
• Git Hooks
• Pull Requests
• Continuous Integration
• Releases/Deploys

Command Line

The Commands

The base command will run all all analysis tools but won't run anything that makes changes to yor code:

rvw

You can use the fmt command to have it only run the formatters:

fmt

Options & Keywords

Reviewer supports using standard command-line flags as well as keywords. So if you're running a simple command, Reviewer will do its best to guess your intention.

For example, rvw --tags ruby and rvw ruby will behave the same in most cases. Reviewer has a specific order of operations when trying to guess the purpose of keywords.

1. Reviewer Keywords for Files (ex. staged, untracked) are built-in shortcuts for common subsets of files that would be reviewed on their own but otherwise tedious to generate a list of files for.
2. Individual Command Names (ex. rubocop, brakeman) are extrapolated from your .reviewer.yml configuration.
3. Tags (ex. ruby, css, frontend) are defined for each

If Reviewer notices a conflict and can't determine your intention, it will let you know, and you can adjust your configuration or use flags to clarify your intentions.

Using Tags

If you've configured tags for the various tools in .reviewer.yml, you can use tags to run a subset of tools:

rvw --tags ruby or fmt --tags ruby

Or you can use tags directly as long as they don't conflict with a tool name or Reviewer keyword (ex. staged, untracked)

rvw ruby or fmt ruby

Targeting Specific Files or Directories

Or you can focus on a specific set of files:

rvw ./app or rvw ./app/models/user.rb ./test/models/user_spec.rb

And there's a few magic keywords for only running against special groups of files:

rvw staged or fmt staged will run the tools against the staged files for a quicker run before committing files.

Or if you just want to run a single tool, you can use the key for the command from your YAML configuration file:

Running a Specific Tool

Sometimes you just want to run a single tool without having to think about your configuration. In that case, rvw rubocop would run Rubocop using your specified configuration automatically.

Running with Guard

Just like with testing, you may want to run some subset of your reviewers via Guard to help you stay on top of tiny details so you're not overwhelmed when you run a full review.

Or, you may want to run your dependency audits before Guard starts up so that you don't end up sifting through test failures only to find out they're all caused by a single dependency.

Git Hooks

Git Hooks are a great way to automate running some tests prior to committing.

You could tag a set of commands as 'pre-commit' and run rvw --tags pre-commit --files staged

Pull Requests

Since commits are more frequent, they may be focused on the lighter and faster tools, but for a pull request, you may be more comfortable running some of the longer-running checks.

You could tag a set of commands as 'pr' and run rvw --tags pr

Continuous Integration

For continuous integration, you may only want to run the absolutely critical checks that should stop a release.

So you might tag commands with ci and run rvw --tags ci

Releases/Deploys

Depending on how you deploy, you may want some final smoke tests just to be sure. You may not want to slow down deploys, but if you have quick smoke tests or the like that you want to run on deploy, a tag like deploy could be used on everything that will cause the app to break if it's released without addressing the issues, and then rvw --tags deploy could be a part of your workflow.

Similarly, if there's a critical bug where every second counts, and you're working on a hot fix, you could have a tag like critical that will only run the tools that should genuinely block a deploy. Or event rvw --tags critical staged to only run the critical commands against your new changes. That way, you can temporarily ignore issues with linting or other details that might unnecessarily prevent you from fixing a more significant issue.