[rzo1]

Following up on @solomax suggestion in #207: the pull request build covers Derby and H2 only, so a defect invisible on those two reaches master and is found when someone runs another database by hand. Two recent cases — a JPQL LIKE pattern that matched only on Derby for several releases (OPENJPA-3009) and six tests asserting the SQL shape Derby and H2 emit (OPENJPA-3010, your MySQL report).

This adds a Databases workflow running the existing test-mysql-docker, test-mariadb-docker and test-postgresql-docker profiles weekly (Mondays 04:17 UTC) plus workflow_dispatch for use before a risky merge. It is separate from pr-validation.yml, so it never blocks a pull request.

Two implementation notes: the docker-maven-plugin declarations in those profiles carry configuration but no executions, so nothing starts a container during an ordinary build — the servers therefore come from Actions service containers with health checks, using the credentials each profile already expects. And it is one job per database rather than a matrix, because MySQL and MariaDB both listen on 3306 and a service container cannot be selected per matrix entry.

I verified locally that each profile connects to a container started with exactly these service settings (MySQL needed no extra GRANT, which my earlier manual runs did). Java 21 only, to keep the weekly cost down — happy to add 17 if you would rather mirror the PR matrix. Expect the first scheduled run to be red until #208 lands, since testLikeExpr still fails on the MySQL family on master.

[solomax]

this new job failed with: Cannot get a connection, pool error Timeout waiting for idle object, maxWaitDuration=PT9.999992769S

I believe we need to add some sort of email notification in case of failures .....

[rzo1]

Both tracked:

• OPENJPA-3015 / [OPENJPA-3015] Mail the dev list when a workflow run fails #214 adds notifications.jobs to .asf.yaml, pointed at dev@openjpa.apache.org. Per the infra docs that mails a run that fails and one that succeeds after a series of failures, and says nothing about successful runs, so it should not be noisy. It only takes effect once it is in master.
• OPENJPA-3016 for the failures themselves.

On the run (38204987477): MySQL passed, PostgreSQL had one failure in TestPessimisticLocks, and MariaDB failed the criteria package in bulk before the pool ran dry — TestTypesafeCriteria 124/45/70, TestMetaModelTypesafeCriteria 29/10/11, TestTypeSafeCondExpression 55/9/27, TestSubqueries 28/13/15. The connection timeouts appear afterwards, in TestMultiselect, which makes the pool exhaustion look like a consequence: the criteria tests fail for some dictionary reason and their failure paths leak connections until the pool is empty.

So there are two things to fix, and the second matters regardless of the first — a failing test should not take the rest of the suite with it. I am looking at both, including whether MariaDBDictionary is missing something its MySQL sibling sets, since MySQL passed the same suite.

[solomax]

thanks a lot :)