This was added in a newer version of django-webpack loader to be used in
CI. Previously we had some monkey patches to deal with this but they
could break when changes happen to the upstream django-webpack-loader
library.
This should be a more robust solution to keep CI working and to reduce
complexity on future upgrades.
The cms/startup.py and lms/startup.py files were created to
allow us to do a lot of custom initialization around things
like the ModuleStore, monkey-patching, adding MIME types to
our process, etc. As far back as 2017, we recognized that
this was a bad thing, marked these modules as "deprecated",
and started removing things or putting them in the standard
Django locations for them (0279181).
In its current state, these startup modules no longer do any
custom work, and just invoke django.startup(). But this is
meant for running Django code in "standalone" usage, e.g. if
you have a script that isn't a management command but needs
some Django functionality.
The "runserver" command used during development normally
launches a child process to serve requests and knows how to
kill and respawn that process when files are modified, so
that changes are reflected. It can also normally handle the
case where there's a SyntaxError in the child process, and
fixing that error will reload the code again.
Something about running django.startup() manually interferes
with this functionality in "runserver". It still reloads the
code in response to changes, but if the code gets into a
broken state for any reason (like a syntax error), the master
process itself dies. That causes the container to restart,
only to die again shortly afterwards in a loop until the
error is fixed. The container restarts will break any shell
you had opened into the container, as well as any IDE
integrations that connected to that container to access the
files and Python instance.
Getting rid of the custom startup code fixes this and moves
us one small step closer to being a more normal Django
project.
- added more default options to pytest calls in setup.cfg and pytest.ini files.
- pytest-json-report's plugin name in pluggy has changed, so added option for multiple names
This change only implements pytest hooks when we know pytest_json_report plugin has
been loaded. Previously, the hooks were being loaded before plugin, thus causing errors
cause(pytest_sessionfinish needs the plugin to function).
* Added pytest-json-report plugin
- modifying app-opts in setup.cfg
- adding hook to all conftest.py files in repo
- setting report to be saved to test_root/log/warnings.json
- Writing custom logic to save json report to avoid overwrite if pytest called twice
This was created to allow us to easily parse through test warnings in jenkins
The imports were sorted in May, which broke the monkeypatching in
safe_lxml. I added two tests that the XML parsers are properly patched,
but they didn't pass until I added the monkeypatching to the start of
the test runs. Once that was done, some tests failed because they
relied on specific details of how empty elements are represented. Those
tests are now fixed.
