| Commit message (Collapse) | Author | Age | Lines |
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| | |
python-discord/sebastiaan/backend/remove-dockerhub-push
Remove DockerHub from GitHub Actions
|
|/
|
|
|
| |
We're no longer using DockerHub in our deployment for SeasonalBot, so it
does not make sense to keep pushing containers there.
|
| |
|
|\ |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| | |
Remove persistence requirements from Seasonalbot
|
| | |
|
| |\
| |/
|/| |
|
| | |
|
|\ \
| | |
| | | |
Migrate to GitHub Actions and GHCR
|
| | |
| | |
| | |
| | |
| | |
| | | |
I've added a bunch of comments to document some of the steps. I've also
removed the unnecessary `persist-credentials: false` option from the
build phase.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We are currently migrating our backend to a Kubernetes cluster. As this
requires changes to our CI anyway, this is a good time to also migrate
our CI Pipeline to GitHub Actions and start using the GitHub Container
Registry to push our builds.
Changes compared to the old situation:
- flake8 linting errors will now show up as GH Actions annotations
- containers are tagged with both "latest" and a short commit SHA
Note: This version of the workflow still pushes to DockerHub IN ADDITION
TO GHCR. This is to make the transition between the two deployment
systems as seamless as possible.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\
| |
| | |
Fix candy mini-game to group leader-board scores correctly
|
| |\
| |/
|/| |
|
|\ \
| | |
| | | |
Bump 'discord.py' to 1.5.1 and use explicit intents
|
| |\ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since we disable both privileged intents, we can just construct an
instance with them already off. As Senjan notes, this will also
future-proof us against any privileged intents added in the future.
Co-authored-by: Senjan21 <[email protected]>
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
With 'd.py' 1.5.1, the Member converter will now lazily fetch the
member object.
It is believed that this removes our need for the intent.
|
| | |
| | |
| | |
| | |
| | | |
Bugfix release:
https://discordpy.readthedocs.io/en/latest/whats_new.html#v1-5-1
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For now, we require the privileged 'Guild Members' intent, to maintain
all current functionality (e.g. Member convertors working with IDs).
In the future, we may look into disabling this intent.
|
| | | |
|
| | |\
| |_|/
|/| | |
|
|\ \ \
| | | |
| | | | |
[Bug] emoji command
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | | |
Co-authored-by: Rohan Reddy Alleti <[email protected]>
|
| | | |
| | | |
| | | | |
Co-authored-by: Rohan Reddy Alleti <[email protected]>
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|