* Basic attempt for a release workflow in GH Actions
* move docker release to `release.yml`
* return the docker steps to ci.yml
* return the deploy-docker step to release.yml
* add wait for tests GA
When using pip >=22, we get the following warning:
"DEPRECATION: The HTML index page being used (https://....) is not a proper
HTML 5 document. This is in violation of PEP 503 which requires these pages
to be well-formed HTML 5 documents. Please reach out to the owners of this
index page, and ask them to update this index page to a valid HTML 5
document. pip 22.2 will enforce this behaviour change. Discussion can be
found at https://github.com/pypa/pip/issues/10825"
Adds a new helper script to determine which docker tags are needed for a
given ref going through CI, and uses those tags to populate the GH
actions matrix for a docker deploy step.
Updates the Docker configuration to use the gunicorn server with gevent
workers by default. Adds `waitress` to the docker container, so that if
no server is specified, we will fall back to that rather than `wsgiref`.
Making this happen brought a few other issues to light, which are also
addressed here.
- Docker log output not immediately being flushed to stdout (#358):
resolved by setting the `PYTHONUNBUFFERED` env var to `t` in the
docker container
- When the WSGIRef server is selected, its access logs are written
directly to stderr, rather than going through the logging machinery:
resolved by adding a new `WsgiHandler` class and passing in to
bottle's `run()` method when running the wsgi server. This required a
new `ServerCheck` class to determine whether the wsgi server is
selected when the `auto` option is used
- When using `gunicorn` along with the watchdog cache, package uplaods
were not being picked up by the watcher. Updated the `add_package`
and `remove_package` methods on the `CachingFileBackend` to bust the
cache
* Docker improvements
This addresses much of what was brought up in #359. Specifically, it:
- Significantly improves testing for the Docker image, adding a
`docker/test_docker.py` file using the regular pytest machinery to
set up and run docker images for testing
- Hopefully addresses a variety of permissions issues, by being explicit
about what access pypiserver needs and asking for it, only erroring
if that access is not available
- Requires RX permissions on `/data` (R to read files, X to list files
and to be able to cd into the directory. This is important since
`/data` is the `WORKDIR`)
- Requires RWX permissions on `/data/packages`, so that we can list
packages, write packages, and read packages.
- When running in the default configuration (as root on Linux or
as the pypiserver-named rootish user on Mac), with no volumes
mounted, these requirements are all satisfied
- Volume mounts still must be readable by the pypiserver user (UID
9898) in order for the container to run. However, we now error early
if this is not the case, and direct users to a useful issue.
- If the container is run as a non-root, non-pypiserver user (e.g.
because someone ran `docker run --user=<user_id>`, we try to run
pypiserver as that user). Provided that user has access to the
necessary directories, it should run fine.
- Fixes issues with running help and similar commands
- Updates the Docker image to use `PYPISERVER_PORT` for port
specification, while still falling back to `PORT` for backwards
compatibility
- Moves some docker-related things into a `/docker` directory
- Adds a `Makefile` for building a test fixture package sdist and wheel,
so that test code can call `make mypkg` and not need to worry about it
potentially building multiple times
The only issue #359 raises that's not addressed here is the one of
running pypiserver in the Docker container using some non-default server
for performance. I would like to do some benchmarking before deciding on
what to do there.
Adds an aggregate "tests" job to CI so that we can gate merges on that
without needing to keep merge gates up-to-date with the names of the
various jobs that collectively represent "all tests".
Also dropped the `pull-request` trigger, which I included originally
because I wasn't sure whether the tests on push would run for forks,
which they do!
