[yetibot/core "20200219.184121.8aef96d"]
This upgrade gets us ready for moving to Java 11 as the minimum version for Yetibot.
Use cp/system-classpath for java > 8 since we are switching to 11+ #118
[yetibot/core "20191029.192841.d316d17"]
Allow sub expressions in xargs - #114
[yetibot/core "20191029.181729.026a04c"]
Handle "Nick in use" notice in IRC adapter - #113 by @sarg
[yetibot/core "20191017.211644.6ee48e9"]
[yetibot/core "20191015.195424.5066036"]
[yetibot/core "20191011.182438.972beb3"]
Reply in-thread for observers and in-thread message edits #109
Remove lein-npm
and vendor yetibot-dashboard
resources instead
#110
[yetibot/core "20191009.221933.8c538c8"]
[yetibot/core "20190913.182757.1838a79"]
Support data propagation into sub expressions from a previous command in a pipeline #104.
This PR significantly increases the expressiveness of command pipelines in Yetibot two ways:
Allow sub expressions to access data propagated by the previous command in a pipeline, e.g.:
category names | echo async: `render {{async}}` ci: `render {{ci}}`
Previously, the sub expressions on the right side would not be able to
access the data from category names
. This is because the AST interpreter
we were using (provided by Instaparse) would evaluate ASTs depth first,
which means render {{async}}
and render {{ci}}
would be evaluated
before category names
.
The new interpreter evaluates commands left to right, and resulting data is bound to a dynamic var, letting sub expresesions access that data.
Add the ability to execute Yetibot commands from Selmer expressions in
render
. This allos you to render custom data as normal, but now you can
pipe those into a Yetibot command from Selmer. As an example, consider a
command scores
that outputs data in the shape:
[{:score 123 :zip 90001}
{:score 198 :zip 95125}]
What if we wanted to render the score next to the current weather description for the zip code?
Now we can, like:
scores | render Score {{score}} - {{zip|yetibot-data:weather|get:weather|get:description}}
And with data propagation to sub expressions, the same could be expressed as:
scores | echo Score `render {{score}` - `render {{zip}} | weather | render {{weather.description}}
This PR also enabled Code Coverage reporting via codecov.io. As an example, check out this codecov report.
[yetibot/core "20190905.175835.fe16ae2"]
[yetibot/core "20190524.135839.3929dda"]
[yetibot/core "20190523.215707.386a562"]
Overhaul the history
command, adding a bunch of options to specify which
history to fetch:
[["-h" "--include-history-commands"]
["-y" "--exclude-yetibot"]
["-e" "--exclude-commands"]
["-n" "--exclude-non-commands"]
["-a" "--include-all-channels"]
["-c" "--channels CHANNEL1,CHANNEL2"]
["-u" "--user USER1,USER2"]
["-s" "--since DATE"]
["-v" "--until DATE"]]
See help history
for the full docs!
Add ability to merge query maps in yetibot.core.db.util/merge-queries
Ensure piped values are always converted to strings via `(pseudo-format cmd-with-args (str previous-value))
Add date
and duckling
commands. date
is essentially a specialization of
duckling
- it errors if it can't parse a date out of the expression you give
it. Both of the commands use Duckling to parse a
natural language expression. Some things to try:
date 2 hours ago
date next thanksgiving
date saturday
date summer solstice
date first day of fall
date july
Allow globally disabling embedded expressions like
`echo foo`
via configuration:
:yetibot-command-embedded-enabled "false"
or equivalent EDN:
:command {;; Whether or not embedded commands should be globally available
;; (enabled by default)
:embedded {:enabled "false"}}
Allow globally disabling fallback commands via configuration:
;; Whether to enable having a fallback command. Default is true.
:yetibot-command-fallback-enabled "false"
:command {;; Whether to enable having a fallback command. Default is true.
:fallback {:enabled "false"}}
channel unset
commandyetibot.core.test
with Midje checkers to help unwrap return maps from
commands #81Allow non-map results in xargs #79
Added karma high-score and high-giver reports in GraphQL #77 by @jcorrado.
Now accepting limits on count of returned karma records for aggregate reports, in stead of hard coding to 10. Our model defends the DB, forcing a range of 1
%s
expansion in alias - this was being overriden by alias' special $s
expansion since we moved to the standard pseudo-format
function
#76karma
via GraphQL API
#69emoji
where a space on the end would cause an NPE and add better
error reporting if the user doesn't provide a valid emojirepeat
and add test coverageusers
to blow uproom
method from Adapter
head
and tail
always return a string for individual values.
Related to #829.yetibot-dashboard 0.7.2
yetibot-dashboard
to serve new assets by parsing the index.html
output by yetibot-dashboard
's create-react-app
scripts.false
for connected?
!!
Fix bug in render
when collections were passed across a pipe, e.g.:
list 1 2 3 | render foo
"_"
with " "
on reactions from react observers, e.g.
thinking_face
becomes thinking face
flatten
command (it was removed at some point)category list <category>
command:collection
metadata to all the collection commands so they properly
show up in the !category list collection
command:result/data
/ :result/value
data structures
were returned instead of being extractedReact event support for observers! #756
This enables fun Slack-specific behavior where a reaction can trigger a Yetibot command.
For example, to generate a rage meme whenever someone reacts with 😡 on a message:
!obs -e react rage = meme rage: {{body}}
See the docs on !help observe
for more info!
on-message-changed
events in Slack if user is Yetibot to avoid double
recording history. When Slack unfurls things it fires a message changed event.!that
commandorg.clojure/java.classpath "0.3.0"
record-and-run-raw
function to handle recording history and
evaluating expressions via the main pipeline (via handle-raw
) and also for
alias, observers, and cron. This fixes a major bug in aliases that was
introduced in 0.4.47.pmap
or map
depending on whether the
command it's executing has :async
in its :yb/cat
set. #49
by @jcorradoraw all
command to show all command argscommand-execution-info
function to help testing command parsing and
regex matching - #43users
in Slack - #555:adapters
resolveryetibot-dashboard 0.6.6
user
resolver and added user
field on history
typechannels
resolver to list all channels for all adaptersirresponsible/tentacles
#41
by @cvic65432
#44yetibot-dashboard 0.6.5
yetibot-dashboard 0.6.0
yetibot_only
in GraphQL History resolverto_tsquery
instead of to_tsquery
in history resolver search to support
queries with spaces/healthz
endpoint #691yetibot-dashboard 0.5.4
search_query
param on history resolvercommands_only
in history resolveris_private
column to history table and consider a message in Slack
adapter private if it's either a direct message or from within a group.is_private
entities from history in GraphQL APIyetibot-dashbaord
and use its JavaScript output to render
the dashboard and sub-routesconfig-prefix
requires now that it moved to yetibot.core.util.command
yetibot.core.test.loader
to load all observers and commands at test time
to find bad requires earlier onAdd yetibot.core.parser/unparse
to take an expression tree and unparse it
back to the original string that produced it when parsed.
Record Yetibot's output in the history table for all adapters (Slack, IRC).
History is now recorded directly in the yetibot.core/handler/handle-raw
function instead of the old history-observer
, which was removed. This is
because handle-raw
has all the context to create history for both users and
Yetibot, including the Yetibot user and a new computed correlation-id
,
computed as:
(let [timestamp (System/currentTimeMillis)
correlation-id (str timestamp "-"
(hash [chat-source user event-type body]))]
;; ...
)
The correlation-id
is stored in both the user's command (request) history
entry and Yetibot's evaluation (response) history entry so the two can be
easily correlated.
This supports History of Yetibot output for a given command #728.
Added new command
text column to the history table to be used to record the
request command that correlates with Yetibot's response. As such, this column
is only set on :is-yetibot true
columns
bot_mesage
-> bot_message
typo that was preventing bot messages from
being observed in Slack(list String)
to support expressions
that return listsAdd initial GraphQL with eval
query support. Example:
{eval(expr: "echo foo | echo bar")}
Enable Access-Control-Allow-Origin *
header so we can hit GraphQL endpoint
from the docs to support interactive docs
cron
command! -
yetibot/yetibot#150users
now lists all users in a room, regardless of whether they are active
or not. This is due to Slack's Changes to
presence
that makes it much harder to listen for presence_change
events.YETIBOT_CONFIG_DISABLED
to YETIBOT_ENV_CONFIG_DISABLED
and log when
it's disabledYETIBOT_CONFIG_DISABLED
is set
to a valuebot_message
event subtypes in Slacknil
to suppress output -
#618!
and that
into yetibot.coreThis release focuses on observer power ups 💪
Examples:
Welcome users to the #general
channel when they join:
!obs -eenter -cgeneral = echo welcome to #general, {{username}}!
Send a user a private message when they join the #dev
channel:
!obs -eenter -cdev = "echo hi {{username}} welcome to #dev! | replyto {{username}}"
It also works for leave
events:
!obs -eleave -cdev = "echo hi {{username}} welcome to #dev! | replyto {{username}}"
PORT
defaulting
to 3000 if not specifiedconfig
dir doesn't exist by using make-parents
to ensure the dir exists.nil
command (moved from Yetibot)react
command for Slack reactions<Google|http://google.com>
. Now it also unencodes
<https://www.google.com/>
.0.4.0 decomplects mutable and immutable configuration in a non-backward-compatible way. Please see config docs docs and port your existing config to the new structure.
yetibot.core.config-mutable
for mutable partsget-config
url
command to post Yetibot's configured web addresssupport serving web routes in plugins. Namespaces should match:
#"^.*plugins\.routes.*"
And each namespace must have a symbol routes
that contains the routes.
fun
from default room settings since it's now controlled by
category
help category
.:settings
key to all command handlersDeprecated Campfire adapter but left code in place in case anyone wants to port it to the new protocol-based adapter system. If you use Campfire and want it to be supported but don't want to PR let me know and I'll re-add it. It was removed because I wasn't sure anyone uses Campfire.
Huge refactoring of adapters. Each adapter is now an instance of an Adapter protocol, and there can be any number of the various types of adapters (currently Slack & IRC).
Rooms are now configured independent of adapter configuration. Configuration is non-backward compatible. See config-sample.edn for details.
Refactored room settings. Arbitrary config can now be set on a room, e.g.
!room set jira-project YETI
Defaults for known settings are:
Name | Default |
---|---|
broadcast | false |
jira-project | "" |
jenkins-default | "" |
But you can also set any key/val you like.
To view settings use !room settings
.
Full room
docs:
room settings <key> # show the value for a single setting
room join <room> # join <room>
room leave <room> # leave <room>
room list # list rooms that yetibot is in
room settings # show all chat settings forall rooms
room set <key> <value> # configure a setting for the current room
Disalbed AOT
:irc {:rooms {"#yetibot" {:broadcast? true}
"#workstuff" {:broadcast? false}
The above :irc
settings would allow yetibot to post Tweets in the #yetibot
channel, but not in the #workstuff channel. Not backwards compatible with old
config
Can you improve this documentation?Edit on GitHub
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close