Test settings for running Django tests with PostgreSQL are not present

[Raphael Gaschignard]

If I check out Django and want to run its tests, there's no settings file for running them with PostgreSQL.

There _is_ one for sqlite (tests/test_sqlite.py), which requires no moving parts of course.

There is a settings file that gets copied to tests/test_postgres.py by a handful of jobs configured in Github Actions.

      - name: Create PostgreSQL settings file
        run: mv ./.github/workflows/data/test_postgres.py.tpl ./tests/test_postgres.py

On top of this, a Jenkins job seems to copy over its own test_postgres.py file for its testing purposes (along with many other configuration files).

+ cp -r /home/jenkins/djangodata/oracle19.env /home/jenkins/djangodata/oragis19.env /home/jenkins/djangodata/runtests_jenkins.sh /home/jenkins/djangodata/test_mysql.py /home/jenkins/djangodata/test_mysql_gis.py /home/jenkins/djangodata/test_oracle19.py /home/jenkins/djangodata/test_oracle19_host.py /home/jenkins/djangodata/test_oragis19.py /home/jenkins/djangodata/test_postgis.py /home/jenkins/djangodata/test_postgres.py /home/jenkins/djangodata/test_spatialite.py /home/jenkins/djangodata/test_sqlite3.py .

While the Jenkins config is private, this comment on GH (​https://github.com/django/django/pull/18827/files#r1849925192) seemed to indicate that the Jenkins settings file is quite similar.

I think we should check in tests/test_postgres.py in tests. Working on Django locally I feel like I shouldn't need to create an off-tree source file for test settings when there's already one in the tree (just as the template file, hidden away in .github).

If there is a concern about the DB name being hardcoded, environment variables feels like the canonical way of doing it.

Not having that file in the source tree means that any issue with PG, if I want to describe the issue I first have to share a config (see #35921).

My maximalist position is I think that since Jenkins is private, then as much of it as possible should be checked into Django proper, so that any sort of CI failure could be investigated with confidence, and rely less on forensics. I have a really hard time imagining what could be in test settings files that couldn't live in tests (or tests/settings/ if one is unhappy with filling up the top level directory with settings files). I haven't thought about this deeply, though.

[Mariusz Felisiak]

Even if we will copy test_postgres.py to the tests directory, Jenkins will still use a different settings file as it uses some environment variables to set test database names etc. Moreover it's already ​described in docs how to create a settings module for other databases. Last but not least, why for PostgreSQL and not for other supported databases? I don't see much value in doing this, but I will leave the final decision to someone less involved in our CI. (I may be biased.)

[Raphael Gaschignard]

What are set by environment variables? DB name/hostname/username/pw/port... are there any other ones involved?

I think we should check in all of the DB settings files, into tests, without cleaning anything up. Checking in the settings files removes any doubts about what settings are used in CI. This isn't theoretical, I spent some time today trying to debug an issue I was seeing locally and not on CI.

You might not see an upside to doing this, and I understand that this might generate pressure to "clean up" the settings files. I am proposing we don't clean them up. But maybe the settings files have trickiness beyond environment variables, and I'll move on to other things.

[Mariusz Felisiak]

I spent some time today trying to debug an issue I was seeing locally and not on CI.

... and it had nothing to do with settings file.

[Sarah Boyce]

We also have django-docker-box for running tests on different databases: ​https://docs.djangoproject.com/en/5.1/internals/contributing/writing-code/unit-tests/#running-tests-using-django-docker-box

I don't think we need to provide more in the Django repo for local test setup by default.
It makes sense to me that SQLite is available by default (easy setup and this is all you need for many tickets)