-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MySQL 8 support broken #117
MySQL 8 support broken #117
Comments
The MariaDB client is not compatible with default configurations of MySQL server 8.0, so any PHP app using this config will break. This PR switches to mysql-client, which is generally compatible with MariaDB server as well. Fixes edbizarro#117
I remember back in the time that there's a reason to this change to mariadb-client, but was a long time ago and i don't remember why anymore, so, i think we can change back to mysql-client again and see |
I found that reference. I checked, and it's correct – Debian buster does not provide a MySQL package (which I'm a bit surprised by). MySQL's policy on this is that they provide a repo for Debian packages that you should use instead. Unfortunately this implies a certain amount of inconvenience as per this guide, though the problem here is with the client; we don't need the server. I'll have a go at scripting that in my PR, which won't work in its current state. |
I have found a workaround for this. In the gitlab.ci.yml file, instead of saying:
say:
which makes the client use old-style authentication. Bear in mind that this is very much a workaround as it involves a security downgrade. |
The image uses
mariadb-client
instead ofmysql-client
. This means that anything trying to connect to MySQL 8.0 server will fail by default because the mariaDB client does not include support for thecaching_sha2_password
plugin. This is a fatal error that can't easily be fixed from outside because MariaDB does not support this authentication mechanism, so in a testing scenario like this, it is not an appropriate substitution. This is how it is configured in CI:and here's an example of how it fails in a pipeline:
This was fixed once before in a PR, but that was never merged.
A possible workaround would be to manually install the mysql client package prior to running the pipeline, but that should not be something we need to do in a default config.
The text was updated successfully, but these errors were encountered: