Allow usage of config-global.php when running Integration Tests

[jissereitsma]

When running Integration Tests (bin/magento dev:tests:run integration), you will need to customize a couple of files to properly setup the testing environment. Part of this procedure is customizing the phpunit.xml which also defines a file TESTS_GLOBAL_CONFIG_FILE (pointing to either etc/config-global.php or etc/config-global.php.dist). However, configuration files defined in this TESTS_GLOBAL_CONFIG_FILE never end up in the sandbox environment. This issue was also encountered in another issue #15196

With this PR, the TESTS_GLOBAL_CONFIG_FILE is actually put to use. The TESTS_GLOBAL_CONFIG_FILE is picked up properly by the existing bootstrap and then passed on to the constructor of the testing application class. Next, the install() method of the application class is run. This is where the bug occurs. The internal variable $this->globalConfigFile is never used. This PR adds the actual usage of this variable.

Fixed Issues

1. 2.2.4 : Magento 2 integration tests enables all modules #15196: Magento 2 integration tests enables all modules

Manual testing scenarios

1. First, setup integration tests without this PR. Once everything is properly running, a new sandbox environment is created under dev/tests/integration/tmp/sandbox-*. The etc/config.php file in this sandbox should include the entries from either etc/config-global.php or etc/config-global.php.dist. However, it does not.
2. Next, apply this patch and rerun the integration tests. The etc/config.local.php file in the sandbox now should include the entries from the etc/config-global.php file. And this is merged together with the etc/config.php, containing all of the modules added through the Magento setup procedure.

Contribution checklist

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• All automated tests passed successfully (all builds on Travis CI are green)

[magento-engcom-team]

Hi @jissereitsma. Thank you for your contribution
Here is some useful tips how you can test your changes using Magento test environment.
Add the comment under your pull request to deploy test or vanilla Magento instance:

• @magento-engcom-team give me test instance - deploy test instance based on PR changes
• @magento-engcom-team give me {$VERSION} instance - deploy vanilla Magento instance

For more details, please, review the Magento Contributor Assistant documentation

[magento-engcom-team]

Hi @sidolov, thank you for the review.
ENGCOM-3021 has been created to process this Pull Request

[magento-engcom-team]

Hi @jissereitsma. Thank you for your contribution.
We will aim to release these changes as part of 2.2.8.
Please check the release notes for final confirmation.

Please, consider to port this solution to 2.3 release line.
You may use Porting tool to port commits automatically.

[stollr]

@jissereitsma I know this PR is old. In current Magento 2.4.7 the config.local.php is not respected anymore.

Now, I do not find a way to adjust the default config.

[damianachaga]

@stollr The same problem here, have you found any solutiuon?

[stollr]

No, I changed something else, so that I do not need it anymore...

[jissereitsma]

The entire workings of this PR has gone cold a bit. But since this, I'm actually using myself a custom-made librari Yireo IntegrationTestHelper that gives you an OOP-syntax to return the setup variables used by the TestFramework. And this includes an advanced way to include and exclude exactly those modules that you want.

https://github.com/yireo/Yireo_IntegrationTestHelper

Specifically, this is the thing I'm referring to:

$disableModules = (new DisableModules())
    ->disableAll()
    ->enableMagento()
    ->disableByPattern('Sample')
    ->disableMagentoInventory()
    ->disableGraphQl()
    ->enableByName('Yireo_GoogleTagManager2')
    ->toString();

return (new InstallConfig())
    ->setDisableModules($disableModules)
    ->get();

In other words, this scans for all existing modules in your instance, then only enables the Magento core modules, but then disabling MSI, GraphQL and sample data. Usually, this means that the modules are skinned down to 100 modules or less - which also saves a lot of time during the setup.

Sorry for the self-promotion, but I guess this is useful to others.