continuous-integration/drone/push Build is passingDetails
If the amount of commands in a single message is greater, the bot will
now return an error. Includes slight refactoring of command execution
code to make use of streams for async iter-like mapping of the command
list.
Fixes#24.
continuous-integration/drone/pr Build is passingDetails
continuous-integration/drone/push Build is passingDetails
Instead of relying on all parts of the application to construct both
HTML and plain-text responses, we now construct only HTML responses,
and convert the HTML to plain text right before sending the message to
Matrix.
This is a first iteration, because the plain text has a few extra
newlines than it should, created by use of nested <p> tags.
continuous-integration/drone/push Build is passingDetails
continuous-integration/drone/pr Build is passingDetails
The number of failing commands are now printed out when at least one
command in a multi-command execution fails. This commit does not
introduce printing out WHICH commands failed, nor their error
messages.
There was also some minor refactoring to move command response
handling into their own functions (one for single response, one for
multiple) so that the code is more readable.
continuous-integration/drone/push Build is passingDetails
This upgrade introduces a handful of breaking changes in the Rust
Matrix SDK.
- Some types have disappeared and changed name.
- Some functions are no longer async.
- Room display name now has a Result type instead of just returning
the value.
- Client state store has breaking changes (not really a big deal).
This required introduction of a new type to store room information
that we are interested in on the context struct. This new RoomContext
is required mostly due to unit tests, because it is no longer possible
to instantiate the Room type in the Matrix SDK.
continuous-integration/drone/push Build is passingDetails
Add get/insert functions for RoomInfo in the rooms db.
Move 'bot joins room' code to single method, so we can also record a
RoomInfo struct into the database.
Adds a new function `should_process` to rooms impl that determines if
calling could should proceed with processing an event ID. Event IDs
are recorded (along with room ID) as a key pointing to the
system-local timestamp of when the event was received. If the key was
not originally present, we instruct calling code to process the event.
Events are also asychronously recorded by timestamp using a sled event
watcher that listens to inserts in the main tree (described above).
This secondary tree will allow easy cleanup of old events in the
future.
By using rev instead of branch, we were somehow stuck on a very old
version of the SDK. The dependency has now been switched to branch
instead of rev, and the SDK updates properly to latest master when
carg update is called.
projectmoon