* fix: Give more meaningful context in subproc failures
* fix: Handle supervisor escalation if no exc is raised
* fix: only apply sudo if not already running as sudo
* ci: fix easy-install.py test
related to https://github.com/frappe/frappe_docker/pull/1032
* ci: fix easy-install.py
patched bench removed and frappe-bench installed
--no-mariadb-socket required for new-site
* fix: remove frappe version from .env
* feat(easy-install): option to set version
Co-authored-by: Ankush Menat <ankush@frappe.io>
* fix: ignore supervisor restart failures where possible
Ignores proc manager restart failure during:
- App install
- App uninstall
Reason:
- You might not have setup prod yet
- This is useful during docker image building where proc manager wont be
running **yet**.
* ci: dont fail-fast
matrix has no dependency.
Also added
- New methods for printing
- Better env file management
- Better password generation
- Added zip repository downloads
- default container version set to v14
Most developers don't need 3 separate workers in development. This changes procfile to use single worker to consume from all queues in development.
Pros:
- Lighter development setups
Cons:
- Not "equivalent to production" - not required in most cases so eh.
You can still edit procfile to start whatever process you want anyway.
As gunicorn is long running process, potentially running for days
without restart the workers might start accumulating garbage that's
never cleaned up and memory usage spikes after some use.
This largely happens because of third-party module imports like pandas,
openpyxl, numpy etc. All of these are required only for few requests and
can be easily re-loaded when required.
`max_requests` restarts the worker after processing number of configured
requests.
How to use?
- If you have more than 1 gunicorn workers then this is automatically
enabled. You can tweak the max_requests parameter with
`gunicorn_max_requests` key in common_site_config
- If you just have 1 gunicorn worker (not recommended) then this is not
automatically enabled as restarting the only worker can cause spikes
in response times whenever restart is triggered.
