Due to the threading used in tests/test_exit.py, the tests always hang on server.join()
Rather than running an http service in a thread, I'm trying out using pytest-docker to run a http service in a container alongside the tests. Whilst this introduces the need to have docker and docker-compose locally (I don't think that's a massive ask for developers...), it reduces the complexity of the test and doesn't rely on some scary threading
Update
I can confirm that this unblocks the tests locally AND we can now run them in CI builds too (🤙 🤙 🤙 )
To summarise, this PR:
Removes scary threading in test_exit.py in favour of running a very lightweight FastAPI container which does the exact same thing
Unblocks local running of test_exit.pyand enables running them in CI
Adds pytest-docker as a dev dependency (and because of it, docker and docker-compose)
Removes nasty handling of os.environ which would affect any test being run, not just the tests in test_configuration.py
Due to the threading used in
tests/test_exit.py
, the tests always hang onserver.join()
Rather than running an http service in a thread, I'm trying out using
pytest-docker
to run a http service in a container alongside the tests. Whilst this introduces the need to havedocker
anddocker-compose
locally (I don't think that's a massive ask for developers...), it reduces the complexity of the test and doesn't rely on some scary threadingUpdate
I can confirm that this unblocks the tests locally AND we can now run them in CI builds too (🤙 🤙 🤙 )
To summarise, this PR:
test_exit.py
in favour of running a very lightweight FastAPI container which does the exact same thingtest_exit.py
and enables running them in CIpytest-docker
as a dev dependency (and because of it,docker
anddocker-compose
)os.environ
which would affect any test being run, not just the tests intest_configuration.py
Signed-off-by: Ciaran Evans ciaran@reliably.com