Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.[09:56] <isntall> jthorson: how do i test drupalci to use sqlite for the Drupal DB?
[10:03] <jthorson> isntall: Not coded.
[10:04] <jthorson> We'll need to add a check at the beginning of DrupalCI/Plugin/BuildSteps/environment/DbEnvironment->run(); and if the db parameter is 'sqlite3', add a new variable to the $job->buildVars array that we can use later in processing to ensure we set up the actual sqlite database.
[10:04] <jthorson> And then bail without setting a service container.
[10:06] <jthorson> Then we'll need to play around with the definition/variable plugins to i) create the database file, and ii) ensure the run-tests.sh arguments are constructed properly to support it.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2484103-4.patch | 3.82 KB | amateescu |
| #2 | 2484103.patch | 1.37 KB | amateescu |
Comments
Comment #1
jthorson commentedComment #2
amateescu commentedStarted to look into this a bit but I got lost at "Then we'll need to play around with the definition/variable plugins to i) create the database file, and ii) ensure the run-tests.sh arguments are constructed properly to support it." :/
Comment #3
jthorson commentedOkay ... taking a closer look at the code ... This gets into both DCI_DBURL and DCI_RunScript mangling, which is by far the most complex flow within this code. :)
1) Location within DBEnvironment->run() is correct, but we won't need to set a build variable ... We can key off of DBVersion, so just return from here.
2) The existence of a DCI_DBVersion parameter will trigger src/DrupalCI/Plugin/Preprocess/definition/DBVersion.php to add a 'dbcreate: sqlite' line in the job definition. There could be a problem here with the existing code expecting a database value (which it extracts with an explode() command), when sqlite won't have one.
3) We'll then need to create a src/DrupalCI/Plugin/BuildSteps/dbcreate/SQLite.php plugin, similar to the MySQL.php plugin in the same directory. Output of this plugin should set $cmd to whatever you need to do to create the sqlite database (Is this just 'touch filename'?) and then parent::run($job, $cmd). The DBUrlBase.php, DBUser.php, and DBPassword.php plugins may interfere in the code path here; as they will try to mangle the DCI_DBURL value, which is most likely where we would set the sqlite filename we want to use ... so we may need some special case logic here too. This mangling also gets passed into the --db-url parameter on the run-tests.sh command; so we need to ensure that we end up with a sqlite-compatible db-url that run-tests.sh is happy with after this mangling.
Comment #4
amateescu commentedManaged to get this fully working! Thanks for the detailed explanation, it helped a lot in understanding this part of DrupalCI :)
Here's the output of a test run:
Comment #5
jthorson commentedI'm currently still getting mysql dbcreate commands in the test run with the latest code ... what were your local override values for DCI_DBTYPE and DCI_DBVersion?
Comment #6
jthorson commentedAh ... I see.
I was trying to avoid having to set both DBType and DBVersion ... which feels redundant. So I was simply overriding the DBVersion value in the DBEnvironment class, which wasn't actually taking effect.
So I've verified this runs successfully with the proper local overrides ... I'm going to poke a bit more and see if I can render the DBVersion override redundant.
Comment #7
jthorson commentedLooks like the SQLite preprocess plugin is unnecessary ... committed the rest.
I'd still like to get to the point where we don't need both DBType and DBVersion ... but that became a rathole of dependency calculation when running through the variable preprocessing plugins; and this is good enough for the time being (i.e. acceptable for the alpha target).
Thanks!