What is the problem you are trying to solve by the feature?

Currently, the Docker SDK assumes that one specifies a specific store to run tests on:

docker:
    testing:
        store: <storename>

When working on a project with a multistore setup, one may want to run unit tests for each defined store, as each of those may be affected by individual logic adjustments from code buckets. However, the need to specify a specific store as the store to test in a deployment file currently seems to translate into the need to create one deploy.yml file for each individual store in which docker -> testing -> store is set accordingly, as docker/sdk testing will load testing.env environment file in which the docker -> testing -> store is hardcoded, overriding any APPLICATION_STORE one may specify for the docker/sdk invocation.

Having multiple deployment files (one per store) may get tedious for local testing, as one would need to deploy the specific deployment file for the specific store one wants to test and switching the store requires the booting of a completely different Docker environment. While the Docker SDK allows to create multiple different Docker environments ("projects") inside a project using SPRYKER_PROJECT_NAME environment variable, those may conflict when booted together due to trying to bind to the same ports.

Another implementation detail of the current testing environment generation in the Docker SDK is the potential for inconsistency of the default store between docker/sdk {cli,console} commands on one hand and docker/sdk testing command on the other hand. While docker/sdk testing will enforce the store specified as the test store to be set for any commands, docker/sdk cli and docker/sdk console may assume a different store by default and so may require APPLICATION_STORE to be set by the user to select the correct store, which can be easy to forget when it is not necessary for docker/sdk testing because it just pre-selects the respective store.

What is the solution do you propose?

I would like to propose to allow the docker -> testing -> store Option to be unset or set to a wildcard value like *, in which case the Docker SDK would not enforce store-specific environment variables as part of the generated testing.env, thus allowing to use APPLICATION_STORE environment variable to select the store context for docker/sdk testing like is already the case for i.e. docker/sdk cli.

What changes in deploy.yml format do you propose?

• Make docker -> testing -> store setting optional and/or allow a wildcard value like * with which no specific store is enforced by generated testing.env file

What changes in command line interface do you propose?

No changes would be necessary for the CLI.

What alternatives have you considered?

Using one deployment file per store

Seems to be the current standard approach for per-store multistore testing, but may not be ideal for local testing where switching between stores may be necessary quite often (see problem description section above). Also, this approach may not scale well when the amount of stores increases, as one typically needs to create a store specific deployment file for both CI as well as local development environments (+2 deployment files per store).

See also

• CommerceQuest thread on Multistore testing: https://forum.commercequest.space/discussion/29033/limitation-in-code-buckets-and-tests