| Commit message (Collapse) | Author | Lines |
|
Changes the default value of the advent_of_code_commands constant to be
the same channel ID as sir-lancebot-commands. If no AoC commands channel
is set in the .env file, it'll re-direct people to sir-lancebot-commands
instead.
|
|
Please -= 1
|
|
Per Mark's comment, re-raising the error isn't necessary.
|
|
I'm a bit ahead of the game and changing the error handler to match
the new style that Iceman will PR shortly.
|
|
If any of the "spammier" commands (stats, leaderboard) are used within
the primary advent of code channel, rather than a non-specific embed
we instead reply with the channel they should be using.
This also adds a "AOC_WHITELIST_PLUS" constant that makes it easier to
adjust what channels the non-spammier aoc commands can be used in.
|
|
Commands like `.aoc leaderboard` and `.aoc stats` proved to be spammy
in the main advent of code channel.
An aoc_commands channel has been added for aoc commands
and this update prohibits aoc commands from being used in the primary
aoc channel and adds the comands channel to the whitelist.
This also specifically allows the less spammier commands: join,
subscribe, unsubscribe, and countdown in the primary channel to foster
discussion though.
|
|
We need to upload PR artifacts regardless of our lint job failing. As GitHub Actions uses an implicit "success" status function if you don't specify one of your own, we need to include the "always" function in our condition.
|
|
Also, remove error handler for get_command and video_command.
|
|
With the new `workflow_run` setup, we need to make sure that we don't try to send an embed for a skipped workflow. This would be noisy and does not add a lot of useful information.
|
|
A workflow run with a `workflow_run` payload does not contain the
necessary information to build a PR embed. As the old method of using
the API to fetch the relevant information turned out to be fragile (read
note 1 below) and the original Lint workflow already contains the
`pull_request` payload, we now store it as a build artifact.
The embed workflow then fetches the artifact and parses it to get the
relevant information out of it.
---
Note 1: Unfortunately, filtering Pull Requests using the "head"
parameter of the ``/repos/{owner}/{repo}/pulls` endpoint does not work
if the PR belongs to a fork with a different name than the base
repository: the API request will just return an empty array.
I've contacted GH to ask if this was intended or if it's a glitch, but,
for now, it's not a route that's easily available.
|
|
I've changed the way we send status embeds to make it work for PRs made
from forks without potentially exposing secrets. Instead of using the
initial workflows to send the embed, I've created a `workflow_run`
workflow that always runs in the context of the base repository.
And added benefit is that we don't have to add the status embed step to
two separate workflows.
|
|
local error handler no longer checks for BadArgument error and the
attribute handled will be set to True on the error if an OSError occurs.
|