Create a new pytest folder for live system testing with normal services

[AlanCoding]

SUMMARY

This is intended to solve the problem of testing job-related behaviors.

The idea is to keep using as much of our normal testing system as possible, but not use the test database system. This is difficult with pytest-django installed. I can do it by creating a new test folder, and doing a cd into that. I've thought about it, and I'm willing to pay that price.

So I want to uninstall pytest-django, but without actually uninstalling it. I just take all its critical connection points and throw them in the trash. This means that the tests will operate directly on the database, unprotected. Just the way I like it. It is very easy to break things in this state, and that is just what we will do.

Unlike make test, this new make live_test can only be ran as a part of make docker-compose. That rule seems easy enough to me. It's honestly weird that make test runs in a single awx_devel container. If you were going to do that, don't bother with a container in the first place?

My demo test bypasses uWSGI, because didn't need it. It borrows the mock request fixtures we already have to make a "request". Why? Because it works. The task manager gets the message, dispatches it, and it does the full job lifecycle, events and all.

2024-12-05 04:29:41,706 INFO     [167a56f5] awx.main.commands.run_callback_receiver Starting EOF event processing for Job 23
2024-12-05 04:29:41,707 INFO     [167a56f5] awx.analytics.job_lifecycle job-23 post run {"type": "job", "task_id": 23, "state": "post_run", "work_unit_id": "awx1R9oUSnWU", "task_name": "Demo Job Template"}
2024-12-05 04:29:41,756 INFO     [167a56f5] awx.analytics.job_lifecycle job-23 finalize run {"type": "job", "task_id": 23, "state": "finalize_run", "work_unit_id": "awx1R9oUSnWU", "task_name": "Demo Job Template"}
2024-12-05 04:29:42,556 INFO     [-] awx.analytics.job_lifecycle job-23 stats wrapup finished {"type": "job", "task_id": 23, "state": "stats_wrapup_finished", "work_unit_id": "awx1R9oUSnWU", "task_name": "Demo Job Template"}

We want a philosophy of a test environment as isolated as reasonable, while still being useful. Because of that, it is never envisioned that we would make true API requests with this. It has the ORM, and everything can be done with that. The core goal of these tests are to see custody of jobs passed to the dispatcher/receptor/runner stack and test for outcomes in both the database and filesystem.

ISSUE TYPE

• Breaking Change

[AlanCoding]

Progress

>       assert job.status == 'successful', f'Job was not successful id={job.id} status={job.status}'
E       AssertionError: Job was not successful id=1 status=running
E       assert 'running' == 'successful'
E         
E         - successful
E         + running

this is almost certainly because it is still pulling the image, and increasing the timeout should do it.

[PabloHiro]

Awesome addition. Loving the README.md

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[fosterseth]

what unsets DJANGO_SETTINGS_MODULE from awx/pytest.ini? is that what "no:django" does?

[AlanCoding]

IIRC, it only respects the pytest.ini from the current directory, and you can only run these from the awx/main/tests/live directory. So the pytest.ini from a parent folder won't even be considered.

Using -p no:django disables the plugin "django", which has pytest_ prefixed, so the full plugin name is pytest_django. So this disables the pytest-django, it is installed as a library but pytest doesn't load it as a plugin.

[fosterseth]

ah okay thanks for the explanation