In order to keep all three packages (zulip, zulip_bots,
zulip_botserver) in the same repo, all package files must now
be nested one level deeper.
For instance, python-zulip-api/zulip_bots/zulip_bots/bots/, instead
of python-zulip-api/zulip_bots/bots/.
tools/server_lib contains files copied as-is, or with minor
modifications, from the zulip/zulip repository when the api
code was split into this separate repository.
Adds the file api/bots_api/provision.py that installs dependencies
for bots using pip. This file is also used by run.py when running
a bot. However, for testing, you need to separately provision the bots.
For a large perforce server with many users, this allows projects
to opt-in to zulip notifications by creating the stream for the
branch to be monitored.
Commits to paths for which a stream mapping yields a result,
but no stream exists in Zulip, are simply dropped silently.
This behaviour is opt-in, by setting the configuration key
ZULIP_IGNORE_MISSING_STREAM = True
in the zulip_perforce_config.py file.
The general regex-based linkify in zulip does not allow '@' as the
prefix. In any case we know here that it is definitely a changelist
number, which is better.
Adding P4_WEB="https://p4web.example.com" to the config will enable
this behaviour. If P4_WEB is absent from the config, or has the
value None, no link is inserted.
This fixes multiple paragraphs in a commit message escaping
from the block quote by using triple-backquote quoting instead
of '>' which only applies to one paragraph.
Add another class for bot type as embedded bot, for bots that run directly
on Zulip server. This class uses internal 'internal_send_messages' from
actions.py instead of using the 'send_message' function from Zulip Client
class.
We haven't gone ahead with creating an abstract superclass right away.
We just have two versions for now, it would be easier to iterate a little
more on the interfaces, and then only add the superclass when we're ready
to lock down the interface.
This change is done for better understanding of the class functionality
from its class name. Now there will be 3 different classes for bots,
namely 'ExternalBotHandler', 'FlaskBotHandler' and 'EmbeddedBotHandler'.
This involves both using the new `initialize`
method for calling `get_config_info`, and
refactoring the testing framework by adding a
way for mocking this method.
This commit decouples the http mock conversation
feature from assert_bot_response(), and moves it
to the context manager mock_http_conversation().
This allows a modular design with context managers
that could be added for assert_bot_response().
