mariadb*, mysql*, percona-server: fix CI test issues

[gromgit]

For mariadb*:

1. Don't run post-install in CI, so mysql_install_db doesn't trip over arbitrary contents of CI box
2. Run a proper test case

mysql* and percona-server already have decent test blocks, so I only applied [1] above.

• Have you followed the guidelines for contributing?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install <formula>)?

---

[carlocab]

Would it make sense to do this for all the mariadbs + mysql@5.{6,7} in this PR to demonstrate that this fixes the CI issues?

[SMillerDev]

See #60190 as well for a running attempt

[gromgit]

Would it make sense to do this for all the mariadbs + mysql@5.{6,7} in this PR to demonstrate that this fixes the CI issues?

Yes, but I'm starting with the latest version first, to make sure the new test works in CI. I've been burned by "works on local, not in CI" enough times. 😁

[carlocab]

Ah, so you must be an expert at fixing those then. I'd appreciate it if you could take a look at #66688

Update: Yep, @gromgit is definitely an expert

[gromgit]

See #60190 as well for a running attempt

That seems like an orthogonal issue. Adding version-specific data dirs into the mix just means that post-install will fail only on the versions with data dirs that were pre-b0rked for reasons unknown.

Or am I missing your point?

[fxcoudert]

See #52004 for how this was handled on postgresql

[SMillerDev]

That seems like an orthogonal issue. Adding version-specific data dirs into the mix just means that post-install will fail only on the versions with data dirs that were pre-b0rked for reasons unknown.

It would reduce the conflicts to just mariadb 5.6 - mysql 5.6 style, but it was more of an indication of prior art anyway.

[gromgit]

See #52004 for how this was handled on postgresql

Yup, this PR was actually informed by PostgreSQL's approach. In fact, I think that for DBMSes and similar dataspace management packages, the general rule of thumb should be that CI:

1. avoids touching/creating any existing dataspaces
2. creates a temporary dataspace for testing

[fxcoudert]

Not sure why it's draft, but it looks good to me. @gromgit let me know when you're satisfied with your own work ;)

[gromgit]

@fxcoudert Sorry, I decided to sleep on it, as I had a nagging feeling I'd forgotten something.

It turns out I had: All the test MariaDB servers were running on the default port instead of free_port. 🤦

Fixed that, and disabled CI post-install on mysql* and percona-server as well.

Only one audit failure, which looks like a transient issue (the URL itself isn't broken):

Error: 1 problem in 1 formula detected
mariadb@10.4:
  * Stable: The URL https://downloads.mariadb.org/f/mariadb-10.4.17/source/mariadb-10.4.17.tar.gz is not reachable

[BrewTestBot]

@Rylan12 has triggered a merge.