| Commit message (Collapse) | Author | Age | Lines |
|---|
| ... | |
| | |
|
| | |
|
| |
|
|
|
|
| |
This is caused by an upstream issue with setuptools 60.* (via virtualenv) changeing the default to using the setuptools-embedded distutils rather than the stdlib distutils, which breaks within pip's isolated builds.
This is explained quite well here https://github.com/pre-commit/pre-commit/issues/2178#issuecomment-1002163763
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Since our project is licensed under the MIT License, we can't be using any dependencies in our project. This commit adds a step to the CI lint phase that will use pip-licenses to verify that all the installed packages are part of an ALLOWED_LICENSE variable. This variable is currently set to be every license we currently use. We opted to use an allowlist instead of a denylist to make sure that new licenses are reviewed by hand and added to that variable.
|
| |/
|
|
|
|
|
|
|
|
| |
This concurrency rule means that workflow actions will be cancelled if a new set of actions are triggered on the same ref. A ref is either a PR or a branch itself.
Doing this means that if someone pushes to a PR multiple times in quick succession, workflows won't get queued up. Instead, only the workflows from the most recent changes will run, as this is all we really care about anyway.
I see the benefits of this as twofold.
1. The author gets faster feedback about the most recent change pushed, rather than have to wait for all previous runs to completed
2. Other contributors don't need to wait for a queue of redundant workflows to finish.
|
| |
|
|
| |
Signed-off-by: Hassan Abouelela <[email protected]>
|
| |
|
|
| |
Signed-off-by: Hassan Abouelela <[email protected]>
|
| |
|
|
| |
Signed-off-by: Hassan Abouelela <[email protected]>
|
| |
|
|
|
|
|
|
| |
Switches the test runner from unittest to pytest, to allow the usage of
plugins such as xdist. This commit also adds pytest-cov purely as a
generator for .coverage files.
Signed-off-by: Hassan Abouelela <[email protected]>
|
| |
|
|
|
|
|
| |
Updates the Dockerfile, pre-commit, CI, and documentation to reflect the
new dependency manager. Dockerfile is also updated to 3.9.
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
GitHub Actions has an implicit status condition, `success()`, that
is added whenever an `if` condition lacks a status function check
of its own. In this case, while the upload step did check for the
outcome of the previous "always" step, it did not have an actual
status check and, thus, only ran on success.
Since we always want to upload the artifact, even if other steps
failed, I've added the "always" status function now.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces the same custom status embed as is already being
used for Sir Lancebot. The default embeds GitHub sends are disabled, as
they were causing slight issues with rate limits from time to time.
It works like this:
- The Lint & Test workflow stores an artifact with PR information, if we
are linting/testing a PR.
- Whenever we reach the end of a workflow run sequence, a status embed
is send with the conclusion status.
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |
|
|
|
|
|
|
| |
We will now use the deployment information located in the private
python-discord/kubernetes repository. The workflow will use a GitHub
Personal Access Token to access this private repository.
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |
|
|
|
|
|
|
| |
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".
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
I've fixed the deploy stage of our build pipeline, as it got mixed in
with the old workflow file due to a merge conflict. The deploy stage is
currently split into a separate workflow; theoretically, this allows us
to trigger a redeploy from GitHub, without having to build the container
image again.
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |\ |
|
| | |
| |
| |
| |
| |
| | |
It's better to document these steps.
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unfortunately, our old setup did not actually lint the PR, as it was
running in the context of the target repository. To sidestep the issue
of using `pull_request_target` altogether, I've now changed our run of
flake8 to using it directly and having it output its errors in teh
format of Workflow Commands.
This means that our flake8 output will not be translated automatically
in annotations for the run.
In addition, I've split up the workflow into two separate files: one for
linting & testing and one for building (& deploying).
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |/ |
|
| |
|
|
|
|
| |
We don't use DockerHub anymore; let's remove it!
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |
|
|
|
|
|
|
| |
To make the transition easier, we push the Docker container to both
DockerHub and the GitHub Container Registry. I've also added a secondary
tag by short commit SHA.
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |
|
|
| |
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |
|
|
|
|
|
| |
The codeql analysis action we had proved to add little value to our test
suite and has been removed.
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |
|
|
|
| |
The `checkName` value of this action needs to have the same value as the name of the job.
Co-authored-by: Joe Banks <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
By default, the Checkout Actions persists the credentials in the
environment. As our Actions will also run for PRs made from a fork, we
don't want to persist credentials in such a way.
I've also:
- Ported a comment on PIP_USER and pre-commit from the azure configs
- Removed unnecessary id for the pre-commit caching step
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
The dependency `coveralls` was installed directly in GitHub Actions, as
it's not required for local dev environments. However, it's a small
package and there's value in keeping all our dependency specifications
in one place. That's why I've moved it to the [dev] section of our
Pipfile.
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've migrated our Azure CI Pipeline to GitHub Actions. While the general
workflow is the same, there are a few changes:
- `flake8` is no longer run by `pre-commit`, but rather by a separate
action that adds annotations to the GH Action results page.
- As we no longer have need for xml-formatted coverage files, the
xmlrunner for unittest has been removed as a dependency. Instead, we
now publish our coverage results to coveralls.io.
- We use version 2 of docker's GitHub Action build-and-push flow, which
is split over multiple steps instead of one.
- I have changed the badges to GitHub Actions and coveralls.io badges.
Note: Because we accept PRs from forks, we need to be a bit careful with
our secrets. While we do use the `pull_request_target` event, we should
not expose secrets in steps that run code from the repository.
Signed-off-by: Sebastiaan Zeeff <[email protected]>
|
| | |
|
| |
|
Chris Lovering
Matteo Bertucci
Izan
ChrisJL
Joe Banks
Hassan Abouelela
ks129
Joe Banks
Sebastiaan Zeeff
Sebastiaan Zeeff
Leon Sandøy