DDEV project config

[michalkleiner]

Description

Provides DDEV project base and resolves #21883
Replacing community PR #21884 so that it's easier for us to iterate on the work, rebase, test etc.

Review

• Functional review done
• Potential edge cases thought about (behavior of the code with strange input, with strange internal state or possible interactions with other Matomo subsystems)
• Usability review done (is anything maybe unclear or think about anything that would cause people to reach out to support)
• Security review done
• Wording review done
• Code review done
• Tests were added if useful/possible
• Reviewed for breaking changes
• Developer changelog updated if needed
• Documentation added if needed
• Existing documentation updated if needed

[sgiehl]

I haven't tested anything yet, but here are already some thoughts I had while looking at the code:

• If we want to have the ddev config part of this repo, we need to ensure those files are removed before building a release
• Assuming that the actual code is mounted into the vm: Running npm install will fail on windows in this case, as directory depth is kind of always too deep for the file system and in many cases it tries to create symlinks, which isn't supported on windows. A possible workaround is to hold the node_module folders fully inside the vm by e.g. overwriting the path with internal mount points or similar.

[michalkleiner]

Ok, I think this is now in a testable state with some documentation needed.
Would someone be keen to check out this branch and test if these steps work?

1. clone this repo, cd to the repo folder and checkout dev-18030-ddev-env-config branch
2. (optional) run ddev config --project-name my-matomo to adjust the default project name (from matomo) and change all occurrences of matomo.ddev.site to my-matomo.ddev.site
3. run ddev start to start the project up
4. run ddev launch to open the instance in browser
5. follow the installation process (db details should be pre-filled) and log in
6. run ddev matomo:init:tests and see if all the install steps work
7. run ddev matomo:console tests:run to see if tests work
8. run ddev matomo:console tests:run-ui to see if UI tests work

[mneudert]

Suggested change

	#!/bin/bash
	#!/usr/bin/env bash

For all the host commands.

My NixOS box only has /bin/sh and /usr/bin/env available, no /bin/bash. I would not expect someone to have this problem, but /usr/bin/env should be just a tiny bit more portable.

We could also switch to plain /bin/sh, but that may require changes to the read arguments afaik.

[mneudert]

Suggested change

	- exec: MYSQL_PWD=root mysql -uroot -e "CREATE DATABASE IF NOT EXISTS matomo_tests; GRANT ALL ON matomo_tests.* to 'db'@'%';"
	service: db
	- exec: MYSQL_PWD=root mysql -uroot -e "CREATE DATABASE IF NOT EXISTS _UITestFixture; GRANT ALL ON _UITestFixture.* to 'db'@'%';"
	service: db
	- exec: MYSQL_PWD=root mysql -uroot -e "GRANT ALL PRIVILEGES ON *.* to 'db'@'%'"
	service: db
	- exec: MYSQL_PWD=root mysql -uroot -e "GRANT ALL PRIVILEGES ON *.* to 'db'@'localhost'"
	service: db

This would allow us to configure db:db for the tests instead of root:root.

Otherwise there may be databases not visible to the db user, for example when running when running the EmptySite spec:

ddev matomo:console tests:run-ui --persist-fixture-data EmptySite

Without more privileges the created _EmptySite database would not be visible.

Not 100% sure if we need to run the statement for if for @localhost, I think it was required to have both ddev mysql and mysql to have all the privileges..

[michalkleiner]

I wouldn't expect the @localhost to be needed as the db is not running on the same system so PHP will never access it on localhost.

I'll test it out, thanks for pointing this out and identifying a test that can be impacted by this.

[mneudert]

Some of the screenshot tests give really weird results. PhpStorm shows all processed screenshots as "24-bit" instead of "32-bit".

And some screenshots created in the Dashboard spec (e.g. Dashboard_dashboard1_mobile.png) are stretched beyond recognition, though the height/width of the file match the expected screenshots.

[michalkleiner]

24 vs 32 bit wouldn't be a problem if we eventually run CI using ddev as well, as long as the images carry the visual information they should.

Could you please send me some of the image names or even some of the files so that I could compare them with mine?

[mneudert]

Sent you my local images and some additional information. It looks like the DDEV environment generates images without an alpha channel:

// repository
  Type: TrueColorAlpha
  Endianness: Undefined
  Depth: 8-bit
  Channels: 4.0
  Channel depth:
    Red: 8-bit
    Green: 8-bit
    Blue: 8-bit
    Alpha: 1-bit

// ddev
  Type: TrueColor
  Endianness: Undefined
  Depth: 8-bit
  Channels: 3.0
  Channel depth:
    Red: 8-bit
    Green: 8-bit
    Blue: 8-bit