Fix integration tests with Docker image for PostgreSQL 10.5

[danxuliu]

The parameters used for the Docker container of PostgreSQL relied on a bug in the Docker image that has been recently fixed: when the container was started a postgres user was always created as a superuser, and also with create role privileges. If --env POSTGRES_USER=XXX was set in the container then, in addition to the postgres user, the given user was created too as a superuser; however, in this case, it had no explicit create role privilege (although as a superuser it would bypass the privilege checks and thus be able to create roles). Besides that, a database with the same name as the given user was also created.

When Nextcloud is installed on PostgreSQL it is checked if the user has create role privileges; if it does not then the given database user is the one that will be used by Nextcloud. Then a database with the given name is created, but if the given name already exists then all the privileges for the public role are revoked from the database instead.

In the above scenario, when the Docker container of PostgreSQL was started for the integration tests --env POSTGRES_USER=oc_autotest was used, so a superuser named oc_autotest and a database named oc_autotest were created. Then, in the installation of Nextcloud, it was checked if the user oc_autotest had create role privileges; it did not (even if as a superuser it could create roles, but it is an implicit privilege, not an explicit one), so that user was the one used. As a database named like the POSTGRES_USER was automatically created when the container was started and it was the database name given to the installer too then the privileges for the public role were revoked from that database and the installation went on happily.

All this started to fail when the bug was fixed in the Docker image. Note that the Docker image tag used is postgres:10; this is not a fixed tag, but one that is updated every time a new postgres:10.X image is released. Thus, the integration tests run in Drone always use the latest Docker image for PostgreSQL 10.

After the fix, if --env POSTGRES_USER=XXX is set in the container then the postgres user is not created and only the given user is created as a superuser, and now with create role privileges too; the database with the same name as the given user is still created.

Due to this, when the Docker container of PostgreSQL was started with the latest image for the integration tests, in the installation of Nextcloud it was checked if the user oc_autotest had create role privileges; now it did, so a new user, which would be the one used by Nextcloud, was created based on the admin user name. However, as the given database also exists, then the privileges for the public role were revoked from the database, but the new user was not granted any privilege in the existing database. Thus, the installation failed with Error while trying to create admin user: Failed to connect to the database: An exception occured in driver: SQLSTATE[08006] [7] FATAL: permission denied for database "nextcloud" DETAIL: User does not have CONNECT privilege..

This is a bug in the Nextcloud installer reported in nextcloud/server#11311, but not fixed yet at the time of this writing.

However, the unit tests on PostgreSQL were fixed in the server without fixing the installer. How? By using a specific name for the database created when the Docker container starts.

If --env POSTGRES_DB=YYY is set in the container then the database is created with the given name, instead of with the name of the user given in POSTGRES_USER. Thus, as the database oc_autotest_dummy is created when the container starts, but the database name given to Nextcloud is oc_autotest, the installer creates the user oc_admin and then creates the database oc_autotest making oc_admin its owner, and now the installation can go on happily.

This same approach is the one used in this pull request to fix the integration tests on PostgreSQL.

[nickvergessen]

Great, a TL,DR would be appreciated next time 😆
So only one test remaining?