-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
System tests on k8s #793
base: main
Are you sure you want to change the base?
System tests on k8s #793
Changes from all commits
1c7b476
aa2d2f6
1f42b94
1b4df03
d81b146
defae66
26b2117
44c7fb6
9882155
40d4fb7
8b1185c
6d82a81
a284362
de8758c
ace0f24
5043ed3
2581e68
32f609c
a3fab82
40cc1c3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
System Tests | ||
============ | ||
|
||
The system tests are run by a project hosted in a GitLab private repository, `Hyperion System Testing`_. | ||
|
||
This contains a ``.gitlab-ci`` pipeline that defines a job that runs the tests. | ||
|
||
System Test Images | ||
------------------ | ||
|
||
The system tests require a number of container images to run: | ||
|
||
* The test runner image | ||
* An ISPyB MariaDB database server image | ||
* An ExpEye image | ||
|
||
It is expected that these images should need to change only infrequently and builds are triggered | ||
manually as needed - see the Hyperion System Testing project for how to rebuild them and how to trigger the tests. | ||
|
||
.. _`Hyperion System Testing`: https://gitlab.diamond.ac.uk/MX-GDA/hyperion-system-testing |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -119,6 +119,7 @@ markers = [ | |
"dlstbx: marks tests as requiring dlstbx (deselect with '-m \"not dlstbx\"')", | ||
"skip_log_setup: marks tests so that loggers are not setup before the test.", | ||
"skip_in_pycharm: marks test as not working in pycharm testrunner", | ||
"system_test: marks tests as a system test" | ||
] | ||
addopts = """ | ||
--tb=native -vv --doctest-modules --doctest-glob="*.rst" --durations=10 | ||
|
@@ -165,7 +166,7 @@ legacy_tox_ini = """ | |
[tox] | ||
skipsdist=True | ||
|
||
[testenv:{pre-commit,type-checking,tests,docs}] | ||
[testenv:{pre-commit,type-checking,tests,docs,systemtests}] | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nit: We've been calling it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Unfortunately, dashes have a special meaning within tox: https://tox.wiki/en/latest/user_guide.html
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm, should we also change |
||
# Don't create a virtualenv for the command, requires tox-direct plugin | ||
direct = True | ||
passenv = * | ||
|
@@ -180,6 +181,7 @@ commands = | |
type-checking: pyright src tests {posargs} | ||
tests: pytest --cov=mx_bluesky --cov-report term --cov-report xml:cov.xml {posargs} | ||
docs: sphinx-{posargs:build -EW --keep-going} -T docs build/html | ||
systemtests: pytest --junit-xml=systemtests_output.xml -m system_test tests/system_tests | ||
commands_pre = | ||
docs: /usr/bin/bash -c "{toxinidir}/utility_scripts/generate_plantuml.py > \ | ||
docs/developer/hyperion/reference/param_hierarchy.puml" | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,4 @@ | ||
import os | ||
import re | ||
from decimal import Decimal | ||
from unittest.mock import AsyncMock, patch | ||
|
@@ -8,6 +9,8 @@ | |
from dodal.devices.oav.oav_parameters import OAVConfig | ||
from ophyd_async.testing import set_mock_value | ||
|
||
from mx_bluesky.hyperion.parameters.constants import CONST | ||
|
||
# Map all the case-sensitive column names from their normalised versions | ||
DATA_COLLECTION_COLUMN_MAP = { | ||
s.lower(): s | ||
|
@@ -119,6 +122,15 @@ | |
} | ||
|
||
|
||
@pytest.fixture(autouse=True) | ||
def use_dev_ispyb_unless_overridden_by_environment(): | ||
ispyb_config_path = os.environ.get( | ||
"ISPYB_CONFIG_PATH", CONST.SIM.DEV_ISPYB_DATABASE_CFG | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Where is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We don't override it for the containerised system tests - the test credentials are mounted to the default place. |
||
) | ||
with patch.dict(os.environ, {"ISPYB_CONFIG_PATH": ispyb_config_path}): | ||
yield | ||
|
||
|
||
@pytest.fixture | ||
def undulator_for_system_test(undulator): | ||
set_mock_value(undulator.current_gap, 1.11) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there are any system tests which we permanently want to leave in the option to locally run them, we should explain how to run them here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think long term the plan would be that rather than run locally directly against the ispyb dev database + expeye staging, we would run them locally against the test instances running in podman. Then we could get rid of the various ST_xxx config options.
This is what I'm currently doing, however there are a few minor wrinkles with podman that I have run into.
It's somewhat complicated:
However I seem to run into slightly different problems depending which of the above I'm using. Note that a lot of these issues are also dependent on how you are running podman/docker and whether they are running with root privileges. So it's doubly complicated as if I ran them on my laptop or at home instead of my workstation I'd probably get different results.
Bottom line is, for ideal local dev scenario, the test containers need to be routable from the outside so that you can run individual python test modules locally against the test service instances. The services also need to be routable to each other.
If you want to run the test container locally as well it needs to be able to reach the outside in order to pull from GH/pypi
The solution I have at the moment is to run in podman with the test instance via the bridging network but able to mount a local RO git repo, this is reasonable but to use it you have to shell in to the container.
It is definitely possible to get what I want with docker as I have pretty much exactly this setup on my home server, but there I have root and also the server is configured as a router. </end of rant>