> I'd like you to take a look at the list of review bot tools in the review
> bot extensions database admin panel (This is where you ran the refresh
> installed tools). You should have an entry for 'PEP8 Style Checker', and
> you need to ensure it is set to 'Run automatically'.

> If you have an empty list of tools, there was a problem with refreshing
> the tool list. To ensure the worker is connecting to RabbitMQ correctly run
> 'sudo rabbitmqctl list_consumers'. If your worker isn't connected, you
> should get output like this:

> Listing consumers ...
> ...done.

> But hopefully you should see something similar to:

> Listing consumers ...
> pep8.0.1 <rab...@SSMobile03.3.17872.0> 3 true
> celery <rab...@SSMobile03.3.17872.0> 2 true
> SSMobile03.celery.pidbox <rab...@SSMobile03.3.17876.0> 1 false
> ...done.

> If you are getting the empty consumer list, could you please post the
> output from 'reviewbot worker -b amqp://<user>:<pass>@<host>:5672// -lINFO'

> If you have the worker connected properly, and the PEP8 Tool set to run
> automatically, but still aren't seeing reviews, run the worker with
> '-lINFO' and see if you get any extra output when a request is posted.
> Also, check the Review Board log for any errors.

> Let me know how it goes,

> Steve

> On Tue, Oct 2, 2012 at 9:16 AM, Daniel Laird <
> daniel.j.la...@googlemail.com> wrote:

>> Hi Steve,

>> Thanks for that feedback - however I am still having issues.  I suspect
>> that it is a problem with Celery/RabbitMq but I have tried to follow
>> various steps and am still having no luck.
>>  I Have now installed the worker on the same machine (to try and use a
>> broker URL of localhost).
>> However when I follow the steps now described in the Readme I do not get
>> any updates.

>> Would it be possible to add some more detail on how you setup RabbitMQ in
>> the readme?
>> Maybe also adding what sudo rabbitmqctl status produces before and after
>> you have started the worker task (if there is any difference)

>> Once I can confirm I have got Celery (and/or RabbitMQ) setup then perhaps
>> there is some further debug you can recomend in the extension itself?

>> I really appreciate the help.

>> Cheers
>> Dan

>> On Mon, Oct 1, 2012 at 4:05 PM, Steven MacLeod <ste...@smacleod.ca>wrote:

>>> Hi Daniel,

>>> All of your configuration looks good. The problems you are having are
>>> due to missing documentation. The README file was missing a critical step
>>> which I have now added (view at
>>> https://github.com/smacleod/ReviewBot/blob/master/README.md).

>>> You will be interested in the final 'Installing and Registering Tasks'
>>> section. In a nutshell you need to trigger an 'installed tools refresh'
>>> which contacts the workers and discovers installed tools. This can be
>>> triggered in the review bot extension's 'DATABASE' admin panel.

>>> As for discovering a user id, you can do this in the Users section of
>>> the Review Board admin panel. When on the page to edit a user, the url will
>>> show 'http://.../admin/db/auth/user/<user_id>/'. Requiring a numeric
>>> user id is not a friendly UI, and I plan to change this soon.

>>> I think it's great that you've written a cpplint tool. I'd like to
>>> include a few tools with the base reviewbot installation, and would be
>>> happy to work with you to get cpplint included if you're interested.

>>> Let me know if you have any more issues, questions, or comments,

>>> Steve

>>> PS: It should also be noted that the previous password issue has been
>>> fixed. Review Bot no longer passes around user passwords.

>>> On Mon, Oct 1, 2012 at 7:56 AM, Daniel Laird <
>>> daniel.j.la...@googlemail.com> wrote:

>>>> Hi Steve,
>>>> I have finally got round to playing with this and I am having a few
>>>> issues - I suspect mainly with my setup but just wanted to see if you might
>>>> be able to help.

>>>> I have a slave machine running rabbitmq (called dmucs)
>>>> To this I have added a reviewbot user (and password)
>>>> I have then started the reviewbot instance as specified:

>>>> reviewbot worker -b amqp://reviewbot:review...@dmucs.domain.lan:5672//

>>>> The Broker URL format I have got from celery docs but this could be my
>>>> first mistake.

>>>> On my test server I have installed the REviewBot extension.
>>>> I then try to configure.
>>>> Broker URL: amqp://reviewbot:review...@dmucs.domain.lan:5672//
>>>> Review-Server: http://reviewboard-testing.domain.lan
>>>> User ID: I have chosen a number that I think = my user ID (based on the
>>>> ordered list of users).
>>>> But is there an easy way to find out user ID? I tried username at it
>>>> told me that was wrong. (this could be another mistake).

>>>> I then Save the extension settings.
>>>> I then submitted a python review to the test server and got silence.
>>>> What debug can be enabled and what would you like to see enabled?

>>>> Hope you can help as I think this will be rather good - and have
>>>> already got an extension to support use of cpplint waiting which once
>>>> polished would like to share.

>>>> Cheers
>>>> Dan Laird

>>>> On Thursday, September 13, 2012 4:57:00 PM UTC+1, Steven MacLeod wrote:

>>>>> Hi Daniel,

>>>>> There has been quite a bit of progress. Most of the
>>>>> features discussed here are completed, but I've hit a roadblock stopping me
>>>>> from getting some sort of beta out.

>>>>> Currently the review bot extension is passing a username and password
>>>>> out to the workers in plain text, so they can access the API. We're not
>>>>> happy with this approach, and are trying to figure out an alternative. It's
>>>>> looking like I might end up implementing OAuth2 support for Review Board's
>>>>> API.

>>>>> The Review Bot project currently lives at https://github.com/**
>>>>> smacleod/ReviewBot <https://github.com/smacleod/ReviewBot> if you'd
>>>>> like to take a look. I'm hoping to get some installation and use
>>>>> documentation up soon, but there's still some work to be done before I'd
>>>>> recommend any sort of production install.

>>>>> Steve

>>>>> On Thu, Sep 13, 2012 at 8:54 AM, Daniel Laird <
>>>>> daniel....@googlemail.com**> wrote:

>>>>>> Hi,

>>>>>> This feature really interested me - I know how busy people are but
>>>>>> has this progressed in any way?

>>>>>> Cheers
>>>>>> Dan

>>>>>> On Thursday, May 31, 2012 6:00:30 AM UTC+1, Christian Hammond wrote:

>>>>>>> --
>>>>>>> Christian Hammond - chi...@chipx86.com

>>>>>>> Review Board - http://www.reviewboard.org
>>>>>>> VMware, Inc. - http://www.vmware.com

>>>>>>> On Tue, Apr 17, 2012 at 12:19 PM, Steven MacLeod <ste...@smacleod.ca
>>>>>>> > wrote:

>>>>>>>>> I can see the pros of this, but what things specifically does it
>>>>>>>>> fail to address?

>>>>>>>> The main issue I'm having is figuring out how I can only hit the RB
>>>>>>>> server once for the patched files. I don't know if it's something I should
>>>>>>>> even be worrying about though.

>>>>>>> They should be cached, so it's not terrible. You'll need one per
>>>>>>> individual worker I'm sure.

>>>>>>>>> I've always regretted that we've used "comment" for diff comments.
>>>>>>>>> Seems fine at first until you start supporting other formats. I'd rename to
>>>>>>>>> "diff_comment." Who knows, maybe you'll operate on file attachments of
>>>>>>>>> certain types later.

>>>>>>>> Good point. I've had the idea of Review Bot reviewing parts of the
>>>>>>>> request other than the code in the back of my mind, and this is a
>>>>>>>> distinction I hadn't thought of.

>>>>>>>>> Is it worth having a flag for an issue? Maybe some things are
>>>>>>>>> issues and some are just suggestions?

>>>>>>>> To handle the raising of issues, I've imaged a global configuration
>>>>>>>> for each Review Board instance which looks like this:

>>>>>>>>    - Modified Code: [No Comment || Comment || Comment & Issue]
>>>>>>>>    - Unmodified Code: [No Comment || Comment || Comment & Issue]
>>>>>>>>    - Ship It?: [ No || Yes If no issues on modified code || Yes if
>>>>>>>>    no issues]

>>>>>>>> I think this will be treated as a suggestion though; I would like
>>>>>>>> to give the tool the option to ignore the settings and decide themselves,
>>>>>>>> since this scheme may not make sense for some tools (especially with a wide
>>>>>>>> range of severities). I thought this could be done by providing two
>>>>>>>> interfaces to the tool:

>>>>>>>>    - A lower-level commenting interface where they specify if the
>>>>>>>>    comment should be an Issue.
>>>>>>>>    - A higher-level interface where they just provide the
>>>>>>>>    comment/line and it decides the issue state according to the settings, and
>>>>>>>>    then calls the lower-level interface.

>>>>>>> Why not both in one interface? Specify a line range and comment, and
>>>>>>> optionally whether it's an issue. If not provided, it falls back to the
>>>>>>> default. Fewer code paths to maintain.

>>>>>>>> I know this can't handle every case out there, and per tool
>>>>>>>> configuration is really what is needed, but I think this is a good start.

>>>>>>>>> You can probably keep this side of it expansive though by not
>>>>>>>>> hard-coding methods, and instead mapping a name from the message to
>>>>>>>>> something like "handle_<name>" and dynamically invoking it.

>>>>>>>> I'm not sure I fully understand what you are getting at here. Are
>>>>>>>> you proposing a "handle_<name>" method for each piece of the request (file
>>>>>>>> attachment, code file, etc.)? Do you think you could elaborate a little
>>>>>>>> more for me?

>>>>>>> So, the endpoint on the RB side that will handle the request can be
>>>>>>> a bit dynamic and do:

>>>>>>>     def on_command(self, cmd, parameters):
>>>>>>>         func = getattr(self, 'handle_%s' % cmd, None)

>>>>>>>         if callable(func):
>>>>>>>             func(parameters)

>>>>>>> Basically.

>>>>>>> I think what I was getting at is that the base tool class would have
>>>>>>> something like the above for any incoming requests from the tool workers,
>>>>>>> and then the subclasses can easily just define methods that the workers
>>>>>>> could invoke by creating handle_* functions. Does that make sense? It's
>>>>>>> possible I was confused by what you were saying.

>>>>>>>>> Does the Review Board side of things know anything about the
>>>>>>>>> tools? If so, each tool could provide a Form class we can render as part of
>>>>>>>>> the settings page. Kind of like what we do for auth backends (though in
>>>>>>>>> that case, we only show one at a time, but they're all in the HTML).

>>>>>>>>  The Review Board extension knows nothing about the tools at the
>>>>>>>> moment. I've kept the python packages separate so the web server doesn't
>>>>>>>> get forced to install a bunch of analysis tools. Here are a few ideas I
>>>>>>>> have for dealing with the configuration of each tool:

>>>>>>>>    1. Let the plugin author deal with it. If they want special
>>>>>>>>    configuration, they need to allow something on the worker side.
>>>>>>>>    2. Allow plugin authors to write their own RB extension, which
>>>>>>>>    will plugin to the Review Bot extension and provide the configuration. This
>>>>>>>>    would give them a lot more control, but would require quite a bit of extra
>>>>>>>>    work. Also, if many tools take advantage of this, the RB extension admin
>>>>>>>>    panel will become bloated.
>>>>>>>>    3. Allow plugin authors to write plugin for the RB extension.
>>>>>>>>    This would be distinct from writing a RB extension in that they would just
>>>>>>>>    provide a special entry point my extension knows about.
>>>>>>>>    4. Return some sort of configuration schema with the "info"
>>>>>>>>    request I've mentioned before. This could be optionally defined in the
>>>>>>>>    tool's class, and returned with the other information about the tool.

>>>>>>>> I definitely like 4 the best for a number of reasons. All
>>>>>>>> information about the tool is kept in a single plugin for Review Bot and
>>>>>>>> everything is dynamic based on what tools are installed in the worker pool.
>>>>>>>> I have no idea what format this schema should take, or how powerful it
>>>>>>>> should be. Any ideas here?

>>>>>>> So just to make sure I'm on the same page, the tools would be able
>>>>>>> to say "Here, these are my configuration options" and then the Review Bot
>>>>>>> extension's UI could render that somehow?

>>>>>>> If so, you could represent it as a list of fields, each with a
>>>>>>> dictionary describing the name, type, help text, etc.

>>>>>>> I think 1-3 aren't ideal, as they're just too much work for
>>>>>>> developers and users, so something that integrates well into what you have
>>>>>>> now would be best.

>>>>>>> Christian