| Commit message (Collapse) | Author | Age | Lines |
| | |
|
| | |
|
| |
|
|
|
| |
We're no longer going to use a two-channel setup for this event, as we
don't want to split the event community into two, staff and non-staff.
|
| |
|
|
|
|
| |
This helper function was only being used in one spot and did not factor
out any logic. I've removed the helper function to just create the embed
where it's needed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've rewritten the Advent of Code leaderboard logic. Unfortunately,
nearly all of the changes made are interrelated, meaning that they've
ended up in the same commit.
To add a bit of structure to the extension, I've chosen for a subpackage
structure instead of a single file structure.
The biggest changes:
- Whether or not you get a join code for the staff leaderboard will now
be determined by looking for the Helpers-role.
- The Python Discord Leaderboard now includes all boards, including the
staff leaderboard. This is one event.
- Redis is now used to set a cache expiry period. This means that our
code does not have to check for cache staleness; Redis will do that
for us.
- The period "fetching" task has been removed. We now fetch solely when
the data is needed to prevent putting unnecessary stress on the Advent
of Code website.
- The option to display the Global Leaderboard within Discord has been
removed. Rather, we now link to the website. This simplified the code
for now, although we could add it back later.
- An additional command, `.aoc refresh`, has been added to allow Admins
and the Events Lead to force the cache to be invalidated. This should
be done sparingly to not overburden the AoC website.
- I've also made sure that the daily notification task actually pings
the notification role by setting the `allowed_mentions` kwarg.
|
| |
|
|
|
|
| |
As the Advent of Code file was getting massive, I've removed the old
single-file based extension as I'm going to replace it with a partially
rewritten subpackage-based extension.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've added a unified approach to setting data for multiple leaderboards
using environmental variables. Instead of setting separate variables for
the three pieces of data we have, hoping that the position of each board
matches up in the three fields, I now set one environmental variable,
AOC_LEADERBOARDS, that holds delimited data.
The data is in the format:
board_id1,session1,join_code1::board_id2,session2,join_code2[::...]
The staff leaderboards should be included as usual in this environmental
variable. Another environment variable, AOC_STAFF_LEADERBOARD_ID, can be
used to designate which leaderboard should be used as the staff board.
I've also made some other constants configurable in this commit and
added the role ID of the Events Lead role to allow the Events Lead to
force a reload of the leaderboard cache.
|
| |
|
| |
Co-authored-by: Joe Banks <[email protected]>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |\ |
|
| | |\ |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
This commit implements a wonder twins inspired command. This is a purely fun command that uses real transformations from the show to make random new transformations. The yaml is all hand transcribed from the actual show.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Our dear knight, Sir Lancebot, will now get their deployment information
from the private python-discord/kubernetes repository. The workflow will
use GitHub Personal Access Token to access this private repository.
To not mix up files, the repositories are checked out side-by-side in
subdirectories of the workflow directory.
|
| | |/
|/|
| |
| |
| |
| | |
I've narrowed down repository events that trigger a Build to the "push"
event specifically. This means that we never build for a "pull request"
trigger, even if the source branch is called "master".
|
| | | |
|
| |\ \ |
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
python-discord/lemon/refactor/seasonalbot_name_change
Rebrand bot to Sir Lancebot.
|
| | | | |
| | | |
| | | |
| | | | |
We no longer have this channel, so this cog serves no purpose.
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
I've tried to replace this with generic references where appropriate,
but a lot of the time it just doesn't make a lot of sense to do so.
|
| | |/ / |
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
# Conflicts:
# bot/exts/evergreen/branding.py
# bot/exts/halloween/candy_collection.py
# bot/exts/halloween/hacktoberstats.py
|
| | |/
| |
| |
| |
| | |
We need to attach an inline cache manifest to the image we build and
push to the GHCR to be able to use the registry as a cache source for
subsequent builds. I've added it to the build workflow configuration.configuration.
|
| | |
| |
| | |
Our two workflows, Lint and Build, now have separate status badges that link to the latest results from that workflow.
|
| | |\
| | |
| | | |
Fix flake8 check in CI and separate Lint and Build jobs into separate workflows
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I've separated the lint and build jobs into two separate workflows:
- Lint: .github/workflows/lint.yaml
- Build: .github/workflows/build.yaml
The main difference is that the Build workflow will be triggered if the
Lint workflow completes while it's been run on the "master" branch. The
build job will check if the Lint run was successful and if it were, it
actually builds the container, pushes it the GHCR, and triggers the
deployment to our kubernetes cluster.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We ripped some features out of the bot to make the migration to
kubernetes easier. However, that process left us with some linting
errors that will play up if anyone makes a PR.
I've added "noqa" to the valid TODO lines and commented out lines that
introduced now unused names or tried to use now undefined names. This
should have no influence on the bot, as it does not touch code that is
actually being run at the moment.
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unfortunately, the flake8 action we were using from the marketplace
required us to use the `pull_request_target` event, which runs in the
context of the target repository to protect secrets.
However, this also meant that flake8 would run on files already merged
into our master branch, not the actual changes made in teh PR! That's
obviously pretty useless as a guard against merging linting errors into
our repository.
This change sidesteps the issue by removing the marketplace action and
replacing it by a direct `flake8` run command. To make sure error output
ends up as a GitHub Actions Annotation, we ask `flake8` to format its
error messages using the correct GitHub Workflow Command format:
::error file={filename},line={line},col={col}::{message}
Whenever something is printed to stdout/stderr in that format, GitHub
Actions will automatically interpret it as the "register error message"
workflow command.
Since this doesn't require a GitHub Token with "write" permissions, we
can now switch back to the safer `pull_request` event that gets a
read-only GitHub Token.
|
| | |
| |
| | |
Co-authored-by: Jeremiah Boby <[email protected]>
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|