frappe_docker: APP_NAME in bake.hcl undefined apparently + notes on app
Docker version 20.10.7, build f0df350
I have enjoyed using Frappe and created my first app. Thank you @vrslev for creating the guide, very useful.
I did find the following bug.
error: docker-bake.hcl:14,20-28: Unknown variable; There is no variable named "APP_NAME"., and 3 other diagnostic(s)
I was able to work around this by adding the following to the docker-bake.hcl file.
variable "APP_NAME" {
default = "docbridge"
}
A couple of other notes:
- Might be good to have the list of files to copy formatted in a list instead of in a paragraph.
- Might be worth noting that you need to run the docker build… command from the root of your app instead of from frappe_docker
- https://github.com/castlecraft/custom_frappe_docker If this is no longer the easiest approach to creating custom app builds, it might be worth updating it’s README.
I should really learn how to do a PR…
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 20
Alrighty… I’ll giveup on that idea. I kinda get why production images should be static but I also think it’s pretty limiting to the eco system to not allow apps to be shared easily.
Anyway, I will just use your https://github.com/castlecraft/custom_frappe_docker repo to package multiple apps.
Perhaps loading apps dynamically will be considered for the next version. Thanks for your consideration anyway.
production images won’t work for static assets. static assets are built and packed into nginx. install-app from worker image just takes care of install in python environment.
in case you use bench image, no need to mount each frappe-bench separately, just mount the workspace like this https://github.com/frappe/frappe_docker/blob/main/devcontainer-example/docker-compose.yml
you will need supervisor to achieve what you need to. just change the frappe/bench image for that.
personally, I’ll not accept apps in volume for other images than frappe/bench.
I personally prefer to make things static and declarative in a project as much things as possible.
There’s a “but” though. I stopped thinking about Frappe as a framework. Judging by infrastructure it is a full blown application to which ERPNext delegates its low level things. Somehow we managed to give people template for dockerizing custom apps built with Frappe from developer’s point of view, not DevOps’. If we want to keep it that way—for developers first—we shouldn’t consider custom apps installation using volumes.
@revant I don’t think we should dynamically mount code as volumes. Docker Volumes eat quite a lot of memory, also it would be quite hard to track down versions and orphan volumes.
yes.
one can assume that custom app can be single app and you package it as part of builds where there is no separate build repo
castlecraft/custom_frappe_docker implements custom_app and additional apps as part of builds. it is a separate repo just for builds. This is what might be needed in v14. Add multiple apps including custom and community apps.
I fork and use that repo as a template to setup multiple apps in an image. It is using the updated custom_app documentation. readme mentions that and has a link to docs in this repo
Definitely!
I will check later what you suggest, thanks!