| Commit message (Collapse) | Author | Age | Lines |
| ... | |
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | |\ \ \
| |_|_|/ / /
|/| | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Closes #224
|
| | | | | |\ \
| |_|_|_|/ /
|/| | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Closes: #136
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- bot/exts/halloween/hacktoberstats.py line 130, better readability
- same file line 208-209 add full stop
|
| | | | | | | |
|
| | | | | | |\
| |_|_|_|_|/
|/| | | | | |
|
| |\ \ \ \ \ \
| |_|/ / / /
|/| | | | |
| | | | | |
| | | | | | |
python-discord/sebastiaan/ci/add-core-dev-approval-check
Add check for core dev approvals on pull requests
|
| | | | | | | |
|
| | |\ \ \ \ \
| |/ / / / /
|/| | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| |/ / / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This commit adds a workflow that checks if a pull request has received
at least one approval from a core developer. If not, the check will fail
and block us from merging the Pull Request.
The reason we're adding this check is because we're moving away from
making the Core Developers team "code owner" of every line in every
repository. This created a lot of "notification" spam, which drowned out
the actually relevant notifications.
This will accomplish the same, at least one core dev needs to approve,
but without the notification spam.
|
| | | | | | |
|
| |/ / / / |
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \ |
|
| | |\ \ \ \ |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|