-
Notifications
You must be signed in to change notification settings - Fork 8
Test Magento templates
Test Magento templates for Dockerizer by installing Magento with all possible templates and software combinations.
Templates MUST have default values for all service parameters.
Note that execution may fail due to network issues or a lack of resources. In such case, you can take the command from the log file and test it manually.
Command log file: var/log/magento_test_templates.log
php bin/dockerizer magento:test-templatesThe command reads all Magento templates to collect information about all possible software combinations. Then it generates callbacks to install Magento. This includes installing various Magento versions 160+ times and takes 2+ hours, depending on the hardware.
The command uses pcntl_fork to run installation callbacks in parallel. Before running callbacks, we check the following:
- Free RAM, supposing that every installation uses up to 2.5 GB of RAM (
grep MemAvailable /proc/meminfo) - CPU cores count - 1 (leave at least one core/thread for other operations,
grep cpu.cores /proc/cpuinfo | sort -u)
Every callback does the following:
- Install Magento.
- Check MySQL connection and run
SHOW TABLES;(see docker:mysql:connect). - Switch to the composition with dev tools (e.g.,
docker-compose -f docker-compose.yaml -f docker-compose-dev-tools.yaml up -d --force-recreate) and check that phpMyAdmin is available. - Check that xDebug is configured (
php -i | grep xdebug&&host.docker.internalis present in the configuration). - Dump the database into the
mysql_initdbdirectory, restart composition, and change indexer modes. This ensures that the dump is correct and MySQL entrypoint scripts work as expected. - Switch indexers to
schedulemode, generate fixtures (setup:perf:generate-fixtures /var/www/html/setup/performance-toolkit/profiles/ce/small.xml), switch indexers torealtime, and run reindex. - Reinstall Magento (see magento:reinstall).
- Run frontend tasks (
npm install --save-dev ; grunt clean:luma ; grunt exec:luma ; grunt less:luma).
There are several ways to make the test faster, depending on your needs. For example, we remove a few things when we test various hardware configurations for our developers to select a better one for Magento development. Here are a few tips and tricks:
Tip 1: Use a shared folder for Composer packages. This will save a lot of time on the first run and even more time on the subsequent runs.
Uncomment - ${HOME}/composer_package_cache:/home/docker/.composer/cache in the following files:
/templates/vendor/defaultvalue/dockerizer-templates/service/php/dv_php_apache.yaml/templates/vendor/defaultvalue/dockerizer-templates/service/php/dv_php_apache_unsecure.yaml
Uncomment the following lines in the /src/Platform/Magento/CreateProject.php file:
$this->shell->run(
"docker exec -u root $phpContainerName sh -c 'chown -R docker:docker /home/docker/.composer'"
);Maybe we'll somehow convert this to the command parameter later.
Never use this workaround for installing Magento! Every instance must be installed from scratch. Every instance must
have its own auth.json file with module licenses. Use this trick only for running tests, and remove it when completed.
Tip 2: Comment out switchToDevTools and checkXdebugIsLoadedAndConfigured callbacks in the
/src/Platform/Magento/CreateProject.php file:
// Comment out the following lines:
$testAndEnsureMagentoIsAlive([$this, 'switchToDevTools'], $dockerCompose, $projectRoot);
$testAndEnsureMagentoIsAlive([$this, 'checkXdebugIsLoadedAndConfigured'], $dockerCompose, $projectRoot);Everything runs faster without xDebug.
Tip 3: Remove the npmInstallAndRunGrunt callback from the /src/Platform/Magento/CreateProject.php file:
$testAndEnsureMagentoIsAlive([$this, 'npmInstallAndRunGrunt'], $dockerCompose, $projectRoot, $magentoVersion);This is especially important for testing hardware because network issues may greatly affect test results. With tips 1 and 3, you will get pretty stable result on the second run that just slightly depends on the network.
IMPORTANT! Please, always run full tests on your templates first and before pushing changes or creating a pull request.
-
DOCKERIZER_PROJECTS_ROOT_DIR: The directory where projects are stored. Acts as a firewall to prevent commands from deleting files outside this directory or system temp directory. -
DOCKERIZER_SSL_CERTIFICATES_DIR: In thedocker-compose.yaml- the directory where SSL certificates are stored. -
DOCKERIZER_TRAEFIK_SSL_CONFIGURATION_FILE(.env.local): The path to the Traefik SSL configuration file. Configured automatically to/home/$USER/misc/apps/traefik-reverse-proxy/traefik/configuration/certificates.tomlwhen you install Traefik (seeConfiguring the toolsection on the Wiki home page).
- docker:mysql:connect
- docker:mysql:export-db
- docker:mysql:import-db
- docker:mysql:upload-to-aws
- docker:mysql:generate-metadata
- docker:mysql:reconstruct-db
- docker:mysql:test-metadata
- MacOS and Docker Desktop support
- Bash aliases
- Install Symfony with Dockerizer
- Running-apps-with-existing-Docker-compositions
- Limitations
- Building MySQL images with DB: how it works
- Configure AWS Lambda
- Gitlab pipeline to build images
- Managing AWS S3 access
- Using AWS credentials with Dockerizer
- Access management cheat-sheet
- FAQ