This fix is related to the work done for VE-15 as it highlighted a number of issues that became visible while running tests w/ tric in CI (GitHub Actions) context.
This fix is not ideal, but good enough to get the work done, see here.
What this fix does:
Leverage the CODECEPTION_WAIT support in the codeception container to wait an arbitrary 3s before running the tests; this will give the WordPress container script that scaffolds the WordPress installation time to scaffold it correctly; in some instances the tests would run on a partially scaffolded installation.
Explicitly require the creation of the test database in the db service. This is done using the MYSQL_DATABASE env var and will ensure that we're not depending on a supposedly default container behavior to run the tests.
In the context of a CI run the tric tool will run on a freshly-cloned moderntribe/products-test-automation clone; we were not handling the initial setup of the dev/_wordrpess directory correctly.
Remove the use of the custom built WordPress container, for now, to rely on a fixed version of the official WordPress container. This removes, from the debugging in CI context, the "noise" generated by the possibly failing WordPress container build.
THE Gotcha:
In tric stack configuration file we bind the current plugins directory to the /var/www/html/wp-content/plugins directory inside the container.
On first run the directory will not exist and the WordPress container will scaffold the WordPress installation setting the user of the plugins directory to... root.
This would kill tests that would run as the docker user and would not, then, be able to access the files.
Simply spinning up the container first and then running the tests will fix the file mode issues.
This fix is related to the work done for VE-15 as it highlighted a number of issues that became visible while running tests w/
tricin CI (GitHub Actions) context.This fix is not ideal, but good enough to get the work done, see here.
What this fix does:
CODECEPTION_WAITsupport in thecodeceptioncontainer to wait an arbitrary 3s before running the tests; this will give the WordPress container script that scaffolds the WordPress installation time to scaffold it correctly; in some instances the tests would run on a partially scaffolded installation.testdatabase in thedbservice. This is done using theMYSQL_DATABASEenv var and will ensure that we're not depending on a supposedly default container behavior to run the tests.trictool will run on a freshly-clonedmoderntribe/products-test-automationclone; we were not handling the initial setup of thedev/_wordrpessdirectory correctly.THE Gotcha:
In
tricstack configuration file we bind the current plugins directory to the/var/www/html/wp-content/pluginsdirectory inside the container.On first run the directory will not exist and the WordPress container will scaffold the WordPress installation setting the user of the plugins directory to...
root. This would kill tests that would run as thedockeruser and would not, then, be able to access the files. Simply spinning up the container first and then running the tests will fix the file mode issues.This I will look at in another PR.