It's possible for the tests to pass but when the user runs ws install on a harness for the app init step to fail; for example if app init relies on dev dependencies. I had this experience when working on the Spryker harness.
This is due to the fact that when install_environment is run, dev dependencies have previously been installed in the console container and are still present. So an app init that relies on dev dependencies will succeed in the test run but fail when the user actually uses the harness.
Ideally we would have a test_harness_install step that started from a clean environment but this would add a lot of additional time to the test run.
To resolve this issue we need to think of the most efficient way of testing app init as it would run for the user and deployments.
I've updated the title and description to include deployments as affected by the build/test hiding the issue, since they run app init/migrate without dev dependencies (which is correct)
It's possible for the tests to pass but when the user runs
ws install
on a harness for theapp init
step to fail; for example if app init relies on dev dependencies. I had this experience when working on the Spryker harness.This is due to the fact that when
install_environment
is run, dev dependencies have previously been installed in the console container and are still present. So anapp init
that relies on dev dependencies will succeed in the test run but fail when the user actually uses the harness.Ideally we would have a
test_harness_install
step that started from a clean environment but this would add a lot of additional time to the test run.To resolve this issue we need to think of the most efficient way of testing
app init
as it would run for the user and deployments.