You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ran into an interesting situation and not sure if its a bug or if I've got something different going on.
I setup a testbed on AWS running the development-docker a slightly tweaked docker-compose.yml (domain email, and an additional service docker added). Everything was running great but I then did a git pull master from the openemr codebase and discovered none of the new classes in OpenEMR were being loaded.
Thought it was the opcache stuff we added and I tried clearing the cache but that didn't do anything. I went and looked at the composer autoloader and discovered that the openemr/vendor/composer/autoload_classmap.php was missing the new BillingFormType.php class which was the exception I was seeing thrown. Normally, composer would fall back to the filesystem and look for the file if it was missing from the optimized autoloader but I haven't been running into that behavior. What's odd is that my local docker environment is not experiencing this problem, only the aws images which is why I'm scratching me head on this issue.
Looking here: I can see we added an acpu option 9 months ago, but I would have thought people would run into this issue since then.
I was able to work around the issue by just re-dumping the autoload after doing a git pull master:
composer dump-autoload --optimize --apcu
I'm wondering if we need to change up the way openemr.sh works so that we don't run an optimized autoloader on the development dockers. Its actually discouraged per the composer documents as optimize is meant for production workloads and not development.
I've attached the docker-compose file I was using to build the system (had to rename to txt to get it to upload) and changed the domain name/service name to keep confidential the customer for now. docker-compose.yml.txt
The text was updated successfully, but these errors were encountered:
I'm reading this but not prepared to comment because I don't use flex and barely understand it.
I do know that flex's launch script is divergent from a regulat container's though. Is flex considered production-ready? Should the optimize just be yanked from it, or should we add a "development" envvar to the script that the compose yml could set for passthrough which controls optimize?
We could definitely modify it to drop --apcu when in development mode in the flex series dockers though (or even not run composer dump-autoload completely if still getting weird behavior with that). Would use the setting "DEVELOPER_TOOLS" to control this.
btw,
flex can be run in production mode or development mode. Production mode allows grabbing codebase from a git/github branch for custom code users, which is default setting if not using all the development setting bells and whistles. However, we all use flex in development mode since using all the development settings bells and whistles: https://github.com/openemr/openemr/blob/master/docker/development-easy/docker-compose.yml#L34-L68
Ran into an interesting situation and not sure if its a bug or if I've got something different going on.
I setup a testbed on AWS running the development-docker a slightly tweaked docker-compose.yml (domain email, and an additional service docker added). Everything was running great but I then did a git pull master from the openemr codebase and discovered none of the new classes in OpenEMR were being loaded.
Thought it was the opcache stuff we added and I tried clearing the cache but that didn't do anything. I went and looked at the composer autoloader and discovered that the openemr/vendor/composer/autoload_classmap.php was missing the new BillingFormType.php class which was the exception I was seeing thrown. Normally, composer would fall back to the filesystem and look for the file if it was missing from the optimized autoloader but I haven't been running into that behavior. What's odd is that my local docker environment is not experiencing this problem, only the aws images which is why I'm scratching me head on this issue.
Looking here: I can see we added an acpu option 9 months ago, but I would have thought people would run into this issue since then.
openemr-devops/docker/openemr/flex-edge/openemr.sh
Line 270 in 3ce943b
I was able to work around the issue by just re-dumping the autoload after doing a git pull master:
I'm wondering if we need to change up the way openemr.sh works so that we don't run an optimized autoloader on the development dockers. Its actually discouraged per the composer documents as optimize is meant for production workloads and not development.
I've attached the docker-compose file I was using to build the system (had to rename to txt to get it to upload) and changed the domain name/service name to keep confidential the customer for now.
docker-compose.yml.txt
The text was updated successfully, but these errors were encountered: