| Commit message (Collapse) | Author | Age | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
I accidentally escaped a single quote in a run command; I've removed it
now. I also changed the job name to `lint-test-build-push` to better
reflect the contents of the job.
|
|
|
|
|
|
| |
Now we've migrated to GitHub Actions, we don't need have XML reports of
our unit tests as we're no longer using the Azure test result
application.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I've migrated the build pipeline to GitHub Actions and changed the
container registry to GitHub Container Registry. In the process, I've
made some changes to our docker setup and caching:
- We are now using a single multi-stage Dockerfile
Instead of three separate dockerfiles, we are now using a
single multi-stage Dockerfile that can be used to build the three images
we want using build targets.
In part, this is because we're now using the docker buildx build action
currently recommended by docker. This new engine runs in a sandboxed
mode, meaning that while it can export built images to `docker` running
in the host, it cannot import local images from it to base builds on.
- Docker builds are now cached within GitHub Actions
The builds are now cached using the GitHub Actions cache of the build
cache directory. The cache keys try to match a cache generated by a
build that matches the current build as closely as possible. In case of
a cache miss, we fall back to caching from the latest image pushed to
the container repository.
- The `base` and `venv` images now have an inline cache manifest
In order to fall back intelligently to caching from the repository, the
final build and push action for the `base` and `venv` images includes an
"inline" cache manifest. This means that the build process can inspect,
without pulling, if it makes sense to pull layers to speed up the build.
The other options, pushing a cache manifest separately (not inline), is
currently not supported by GHCR.
The custom caching script has been removed.
- Linting errors are now added as GitHub Actions annotations
Just like for some of our other pipelines, linting now generates
annotations if linting errors are observed.
- Coverage is pushed to coveralls.io
A coverage summary is now pushed to coveralls.io. Each CI run will get a
unique job that's linked in the CI output. If the run is attached to a
PR, coveralls.io will automatically add a check link with the coverage
result to the PR as well.
- The README.md, Pipfile, docker-compose, and scripts have been updated
As we now need to pull from and link to the GHCR, I've updated the other
files to reflect these changes, including Pipfile run commands. I've
also changed the CI badge and added a coveralls.io badge.
|
|\ |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|\ |
|
| | |
|
|/ |
|
|\
| |
| | |
Add python-levenshtein and sort Pipfile (dev)packages
|
| | |
|
|/ |
|
|\
| |
| | |
add --dev flag to readme
|
|/ |
|
|\
| |
| | |
Fix venv being created in Dockerfile
|
| |
| |
| |
| |
| | |
`pipenv run` creates a venv because it cannot detect that a --system
install was done. The solution is to invoke gunicorn directly.
|
| |
| |
| |
| |
| | |
This will make it easy to maintain a consistent config without relying
on invocation via pipenv.
|
|/
|
|
|
| |
There will be more config files to come so it's cleaner to have them
together than littering the root directory with more files.
|
|\
| |
| | |
Document a simpler way to run snekbox
|
| | |
|
| |
| |
| |
| |
| |
| | |
As convenient as it may be, it is redundant to list out the config in
the docs. It also may fall out of sync with the actual config should
someone forget to update the docs.
|
| |
| |
| |
| | |
Makes the Markdown less cluttered when editing it.
|
|/
|
|
|
|
|
|
| |
The current run instructions are geared towards developers. A simpler
way to run snekbox is to start a container with `docker run` via the
image published on Docker Hub.
Resolves #57
|
|\
| |
| | |
Update contributor doc
|
|/ |
|
|\
| |
| | |
Add sentry integration
|
| | |
|
| |
| |
| | |
Co-Authored-By: Mark <[email protected]>
|
|/ |
|
|\
| |
| | |
Use port mapping, change container name to snekbox.
|
| | |
|
| |\
| |/
|/| |
|
| |
| |
| | |
This is to attempt to avoid matching the bot's typing event being resent at the 5 second mark, which seems to be causing it to hang around after the timeout message.
|
|\ \
| | |
| | | |
CI Improvements
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Error handling is performed inside can_pull so the callers of the
function don't always check its exit code. Because set -e present, if
can_pull returns 1, bash would consider that function a failed call and
thus exit the entire script with code 1. That, in turn, would cause the
CI job to fail.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Azure website has proven to not be reliable for displaying the
JUnit output. Furthermore, some may simply prefer the format of the
output in the terminal over the JUnit representation on the Azure site.
Nevertheless, the JUnit output isn't that bad (when there's actually
a lint error) so it will remain for now. It also provides historical
statistics on occurrences of errors, which is kind of cool, I guess...
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since #62, the dependencies have been installed to the system
interpreter. Therefore, it's not necessary to run through pipenv to
ensure the commands run through an activated virtual environment.
This should also fix pipenv run creating a virtual environment. It seems
it cannot tell when it should be using the system interpreter. It
probably wasn't designed for that anyway i.e. the intent was to run
commands directly in such case, which is what this PR will do.
|
| | | |
|
| | |
| | |
| | |
| | | |
The array shouldn't be expanded when testing with -v.
|