Because of this I think in their composer.json -
"codeception/stub": "^2.0 | ^3.0" ?
Wait so the Codeception image here (https://hub.docker.com/r/codeception/codeception) uses 3.x ?
yup, that's the exact problem i was talking 'bout
... OK, there's a new image on dockerhub, at https://hub.docker.com/repository/docker/yourpropertyexpert/codeception4
can't wait to ckeckout your image, Mark
i'll let you know once i try it
thanks!
When you installed C3, it installed pretty much everything you needed.
With C4, when you install it, it just installs a "core."
When you run (a script it includes) it analyses your code, works out what other modules you need to run, and then updates your composer.json to include them JUST FOR THAT PROJECT.... and then relies on composer.
This has many advantages:
- Easier for them to maintain the codebase, since modules can be released independently
- Easier to customise what you have per project
... but the downside is stuff like "docker when used in a CI system", where you want an image that contains everything you'll need...
It may be that there needs to be a "full image", as part of the official project, that includes ALL the possible modules, and is updated weekly anyway..
... but that's an extra workload for the project team.
you need to give a command to the SHELL
So try something like "php /var/www/vendor/bin/codecept run" ... or possibly just "codecept run" instead of the "run".
My docker image is an image that allows codeception to be run... not one that auto-executes it.
i've got a testing environment which sometimes acts strangely under stress
dlike to know if i can add say 1-5 ms between commands and see if there r any changes
3 replies
