Allow running the tests using only sqlite

[jayvdb]

When running tests on openSUSE build workers, it is highly desirable to not need setting up a postgesql and mysql db in the VM in order to do tests.

As a result, the tests have been disabled for SUSE builds, and incompatible versions can get released.

I was able to get the tests working without these dbs by

1. disabling them in https://github.com/etianen/django-reversion/blob/master/tests/test_project/settings.py#L84-L97
2. Then running sed -i 's/databases = {"default", .*"postgres"}/databases = {"default"}/' tests/test_app/tests/test_*.py to remove the dbs
3. Using pytest-django in order to disable the remaining tests which depend on these dbs: DJANGO_SETTINGS_MODULE=test_project.settings pytest -k 'not (testAddMetaMultDb or MultiDb or MySql or Postgres or testCreateInitialRevisionsDb or testCreateInitialRevisionsModelDb or testDeleteRevisionsDb or testGetForModelDb or testGetForObjectDb or testGetForObjectModelDb or testGetForObjectReferenceModelDb or testGetDeletedDb or testGetDeletedModelDb or testDeleteRevisionsModelDb)'

It would be nice if this could be simplified. e.g. having a TEST_SQLITE_ONLY envvar which the tests detect and do the above behind the scenes.

[etianen]

Hmm. I can see what you're saying, but maybe it makes sense to leave the tests disabled?

After all, running an incomplete test suite is a bit of a false sense of security, and any django-reversion release will have already passed the full CI suite on GH actions.

[jayvdb]

The github actions here verify the versioned code works on the versions tested at the time of the release, while the openSUSE (and other distros) keep running the tests long after that, until they break. e.g. Recently openSUSE switched from Django 3.2 to 4.0, which caused a large subset of the 100+ packages to fail their tests. django-reversion did not break, because the tests had been disabled. I found it was broken because other django packages using django-reversion did have tests running, and they failed.

That we are only running a subset of the test suite does mean it is only a smoke test. It works pretty well for that. We have 18 django packages which are currently failing, with automatic emails sent to the packaging maintainers telling them to fix the package within 6 weeks or the package gets deleted from Tumbleweed. They then work with upstream if there isn't a compatible release out.

If the smoke tests pass, but there is still a problem, users can report the problem in the openSUSE bug tracking system and the package maintainer needs to action that.

[etianen]

Okay, that's a good reason to do this. :) Thanks for explaining.

I'll take an MR that adds a REVERSION_TEST_SQLITE_ONLY option to the test project settings file, and populates this setting from an env var. The tests would then us a skip decorator to ignore tests based on this setting. Does that work for you?