| Commit message (Collapse) | Author | Age | Lines |
|---|
| ... | |
| | |
| |
| |
| | |
This stops different actions, from the same commit, running in parallel from canceling each other.
|
| | |
| |
| |
| |
| |
| | |
This grouping means any new actions on either a PR or against main, will cancel any running
actions. We do not care about these old actions, as they are out of date, so cancelling
them will mean the actions we do care about get done faster.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This is a rewording of the comments in the PR template, to hopefully clarify intentions.
It also removes unneeded fields.
Signed-off-by: Hassan Abouelela <[email protected]>
|
| | |
| |
| | |
GITHUB_TOKEN has now enough permissions to be used for pushing to GHCR, so we don't need PAT anymore.
|
| | |
| |
| |
| | |
Separate the build and deploy stage and set the environment value for the deployment stage.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
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.
|
| |
|
| |
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.
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
| |
This commit introduces enhanced status embeds for workflow runs that
give more information about run that just ended. An added advantage is
that we can disable the default "give me everything"-setting of GitHub
and fine tune when we want to send embeds.
This allows us to only send an embed for the `lint->build` sequence when
the sequence ends (e.g. in the end when done or after an intermediate
step due to failure/cancellation).
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
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".
|
| |
|
|
|
| |
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.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
We're no longer using DockerHub in our deployment for SeasonalBot, so it
does not make sense to keep pushing containers there.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
| |
GH wasn't making use of the metadata section the same way as the issue templates do, so they appeared in the pre-fill, confusing contributors. This removes the section entirely to prevent the confusion.
|
| |\ |
|
Chris
ToxicKidz
Hassan Abouelela
ks129
Joe Banks
Sebastiaan Zeeff
Sebastiaan Zeeff
Dennis Pham
Matteo Bertucci
Leon Sandøy
scragly