Small but important changes:
- We should always be testing in Windows, even if MS Edge is now available on macOS as well.
- We should make a better effort to support older Safari releases, as Safari is tied to OS updates, and device management isn’t always keeping up with releases
This fixes#6393 by modifying the constraint to use an IN condition
which supports both Postgres and SQL Server. Previously, the `|` (OR)
condition was only supported by Postgres because SQL Server only
supports AND conditions.
The implementation follows suggestions from @gasman in
https://github.com/wagtail/wagtail/issues/6393#issuecomment-732161057:
* Migration 0050 is modified to not break on SQL Server
* Added migration 0060 to add or replace the constraint
Additionally, this allows for and documents a `DATABASE_DRIVER` env
variable to be set for testing, to allow a different SQL Server driver
(e.g. FreeTDS on Mac/Linux); and adds the specific `host_is_server`
option for FreeTDS (won't affect SQL Server Native Client on CI).
This change makes several improvements:
* Use in-memory SQLite database for test migrations
The default database is SQLite but its NAME (which SQLite uses as the
filename) was `wagtail`, which isn't valid since
the wagtail codebase already has a `wagtail/` directory. Trying to
run migration creation commands
(https://docs.wagtail.io/en/latest/contributing/developing.html#running-migrations-for-the-test-app-models)
produced an error:
django.db.utils.OperationalError: unable to open database file
because of this conflict.
This change uses an in-memory database as the default database for
tests. If DATABASE_NAME were set to a real file name, then
running the migration command with SQLite creates an empty db with
this filename on running `django-admin`.
Other non-SQLite engines continue to use the original `wagtail` name,
meaning that the `test_wagtail` database gets created just as before.
* Modifies the default values for database USER, PASSWORD, HOST etc to
being an empty string rather than None, to match Django's
[defaults](https://docs.djangoproject.com/en/stable/ref/settings/#host).
This helps avoid any potential issues when Django and database engines
are expecting this being a string.
* Adds documentation to `developing.rst` regarding installation of
required database modules and available environment variables for database
connection customisation
* Normalises the DATABASE_PASSWORD tests environment variable to match
the name in Django's database settings object
Running `npm install` without `--no-save` can introduce spurious changes to package-lock.json due to differences in platform / node version, and these have been known to accidentally sneak into people's PRs. `npm install` without `--no-save` should only be used when actively updating node dependencies in package.json.
This is the correct lexer for interactive console sessions, according to
<http://pygments.org/docs/lexers/>. This does require command lines to
be prefixed with `$`, otherwise they are interpreted as the output of a
command. It highlights the command nicely, including environment
variables, strings, and comments.
As a new contributor I found some of the information for contributing hard to
find easily. I think this restructure should fix that, by bringing relevant
menus under their headings and adding an additional heading for 'more
information' instead of just 'other contributions'.
This more reliably ensures that the user has up-to-date dependencies (e.g. without it, a
beta version of a package like Willow or modelcluster won't get installed if the user has
a stable version already installed)
Thibaud Colas