This should solve the problem of getting `nodejs: not found` when
running `paver test_js_run -s lms` in lms-shell, which cropped up in
the past few days.
I don't know why this stopped working recently, but I don't have `nodejs`
on my recently re-created devstack, and some people with an older devstack
have both. Maybe a recent node.js release got rid of an alias.
'npm install' command execution was changed from paver.easy.sh()
to subprocess.Popen() in commit 0dd13fad1b,
but exception handling was not updated accordingly. Due to this,
errors in 'npm install' execution were not detected.
Fixed the most frequently occurring deprecation warnings, which were causing over half of the 34,140 deprecation warnings raised during the unit tests:
* `Use of .. or absolute path in a resource path is not allowed and will raise exceptions in a future release` - most of these were due to a single mis-configured resource path with a leading slash.
* `count is deprecated. Use Collection.count_documents instead.` - I added a handful of simple workarounds for this pymongo deprecation that shouldn't increase the query counts
Also did some cleanup of unused code in pavelib after the recent split of the new `i18n_compilejs` command from `i18n_dummy`. (This had caused a diff-quality failure on the first commit.)
This patch adds compilejs
management command to be executed
on pull translations enabling
availability of js/jsx translations
for lms/cms code.
PROD-960
* 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
These tests essentially duplicate the logic for how the pytest commands
are generated and then compare the duplicated logic to the original
logic. This is pretty brittle and since we're running all the variants
here pretty regularly I think we have other ways of knowing if we caused
the command to break.
I don't think these tests are providing sufficient value to merit their
added complexity.
They are running into issues because of a bug in moto but looking closer
at what they are testing. Both tests test the happy path of the
underlying function. In the happy path scenario all boto calls succeed
and all theses test do is test that but with all the boto calls mocked
out. So we're just testing whether the mock is a good mock of boto
which is not useful.
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
ran python-modernize and isort on files mentioned in INCR-390
