| Commit message (Collapse) | Author | Age | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The coveralls package has consistently caused issues for us, so it made
sense to switch to something that's a little more decoupled, especially
when it has official support.
Switching is simple, since coverage.py can natively generate the format
used by the coveralls action, and everything else is plug and play.
Signed-off-by: Hassan Abouelela <[email protected]>
|
|
|
|
| |
Signed-off-by: Hassan Abouelela <[email protected]>
|
|
|
|
|
|
|
| |
All dependencies and code are already ready for 3.10, all that's
necessary is to update the number.
Signed-off-by: Hassan Abouelela <[email protected]>
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Poetry 1.2 introduced a regression which broke pip `--user` installs.
These types of install where the main way we did installations in docker
and CI, which made it much more convenient to control their location,
availability, and caching.
Poetry's team does not recognize this as a supported use case, so major
changes were required to get everything working again. Most of the
changes were consolidated into chrislovering/python-poetry-base for
docker, and hassanabouelela/setup-python for CI.
Signed-off-by: Hassan Abouelela <[email protected]>
|
|/
|
|
|
|
|
|
| |
There are currently no warnings emitted during our tests, so this is a
low-cost method of ensuring we can better notice problems such as
deprecation warnings earlier.
Signed-off-by: Hassan Abouelela <[email protected]>
|
|
|
|
|
|
|
| |
Call the migration handler in manage.py when running tests, before
handing control back to django.
Signed-off-by: Hassan Abouelela <[email protected]>
|
|
|
| |
We will keep the issue template currently present on meta: https://github.com/python-discord/meta/blob/main/.github/ISSUE_TEMPLATE/resource-request.yaml
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Hassan Abouelela <[email protected]>
|
|
|
|
|
|
|
| |
Merges the normal dockerfile with the static build one to reduce
duplication.
Signed-off-by: Hassan Abouelela <[email protected]>
|
|
|
|
|
|
|
| |
Reworks the docker build action to use buildx in all steps to make the
caching work. Reduces the wait time on the fetch action.
Signed-off-by: Hassan Abouelela <[email protected]>
|
|
|
|
|
| |
Adds an action which builds and uploads the static site as an artifact,
and a fetch script to be run on the netlify builders.
|
| |
|
| |
|
| |
|
|
|
| |
This pull request template was mainly added so that the second bullet point in [this PR comment](https://github.com/python-discord/api/pull/17#issuecomment-933739292) can be addressed.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
GITHUB_TOKEN has now enough permissions to be used for pushing to GHCR, so we don't need PAT anymore. Also, use `repository_owner` instead of the secret of username.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
| |
We need to make sure that we always upload our PR artifact, even if linting/testing fails. As GitHub Actions inserts an implicit "success" status check if you don't add any explicit status checks, this means that we have to include an "always" status check, even if this step has a condition relying on another "always" step.
|
|
|
|
|
|
| |
Similar to Sir Lancebot and bot, I've added enhanced GitHub Actions
status embeds to our workflow sequence. This means we get fewer embeds,
but with more information!
|
| |
|
| |
|
|\ |
|
| | |
|
| | |
|
|\| |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
I've renamed the file to create a more consistent naming scheme.
|
|/
|
|
|
|
|
|
|
|
|
|
|
| |
I've restructured the build & deploy sequence in our GitHub Actions CI
workflow:
- There's now a separate workflow to deploy to our cluster
- The Build workflow has an additional `if` check to ensure we're only
starting the build & deploy sequences for pushes to master
- We now checkout the python-discord/kubernetes repo to fetch the
deployment.yaml file located in there
|
|
|
| |
The CI was failing on occasion because postgres did not have time enough to start properly before we started running our makemigrations check. I've moved the docker-compose step to earlier in the workflow to give it some time to warm up.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Unfortunately, the way we previously set up our workflow caused flake8
to run on code already committed to master, not the changes made in a
PR, because it ran in the context of the target branch.
This is obviously useless when it comes to protecting our codebase from
linting errors. I've now set up flake8 in a different way, using
Workflow Commands to create error annotions.
I've also split up the workflow into two separate workflows.
|
| |
|