What is the best way to deploy changes while developing without having to rebuild the container? #93
Comments
|
This is a docker question rather than a calcom issue. |
|
I somewhat agree but also disagree with @JoeyFenny it's a container logistics issue and could be documented in the README.md |
Leopere
pushed a commit
to Leopere/calcom-docker
that referenced
this issue
Aug 1, 2022
- added numerous environment variable changes such as implied defaults that can be overriden. - skipped out on using git modules and just pull repo into build/launch step. Adherance to license requires no repackaging and this solves this. - cleaned up now unnecessary .env file. - recycled environment section using yaml features. - writing a few strings to config path to persist data between container starts that focus on cryptography and secrets. - writing installed commit to the config path in case the end user needs to change the upstream git commit ID to a newer version for detection and automagic upgrades. - added docker-compose.override.yml pattern to .gitignore to allow users to customize their local dev environment if they use docker-compose.yml - wrote a dockerfile/container image which allows for uploading the base container to a private or public docker container registry without breaking the license rules. - left .env ignore in case users wish to continue to use the old method. - updated README.md to include updated simplified instructions. - added start.sh script and wait-for-it.sh into the shell $PATH to allow for a potential future of allowing the main executable (node JS app) to run under a limited privilege user while still allowing the init scripts to be executed securely. - added some input sanitation for certain critical variables. - by default disabled/commented out the studio service as its not to typically be run to enforce better default deployment practices. I would like to figure out what specific query to execute via the CLI instead of running a whole container to establish the first user in the end. - wrote relatively unopinionated docker-compose.yml file to avoid causing problems for people trying to deploy this behind a reverse proxy for potential features such as TLS/HTTPS termination. - upgraded compose version to latest '3.9' to be sure to enable most modern feature set. Fixes calcom#87 by providing a working baseline with sober defaults. Fixes calcom#88 by ensuring consistency across all containers Environment vars. Fixes calcom#93 by allowing users to mount the application files within their IDE workspace, however, this will never solve for any times you will need to run yarn build steps. Fixes calcom#99 by no longer using git submodules and just pulling a single commit depth copy of the ORIGIN repository on app bootstrap/first boot. Fixes calcom#113 by no longer requiring build locally if the community maintainer of the Cal docker repository on GitHub will push this image to the hub. Fixes calcom#121 by removing dependency on BuildKit this is done by simply deploying the app if its detected to be the first execution of this container be it due to no container persistence or a commit version upgrade from ORIGIN. Fixes calcom#128 by removing dep on BuildKit Fixes calcom#123 not replicatable and confirmed to be working in repository shipped state. Fixes calcom#136 by building app on first launch from user define-able envvars which can be defined in numerous ways.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the best way to deploy changes while developing without having to rebuild the container?
The text was updated successfully, but these errors were encountered: