Various Possible Improvements

[william-riley-land]

I've been setting up cal.com using Docker, and found some possible improvements that may be of use to the community:

• Improvements to build speed
• Some security hardening
• Simplify environment variable handling
• Skip need to run replacement script (this may not have been working as intended)
• Remove need for DOCKER_BUILDKIT=0 by moving DB migration to container start up
• Disable telemetry of various packages (you probably won't like this, which I understand, but I am compelled to suggest it for the pro-opt-in side of the debate :)

Of any use?

[krumware]

Lots of great things in here, thanks especially for the security hardening.
Can you by chance re-add the database_password portion back to the .env?

I'll need to verify the changes for the database at build-time. That was required by the build process for doing inserts based on env config values for the plugins, and not required only for the migrations. Did you by chance check on that as well?

[william-riley-land]

Thanks for taking a look. I think I addressed the two issues, let me know how it looks.

[william-riley-land]

Here's what I think the main open questions are, in summary:

• Remove need for submodule
  • Remove need to use the submodule during build
  • Remove submodule as trigger for GitHub action. I have a few ideas how this could be done, but it is probably better done by someone with access to test the GitHub actions (?)
• Remove need for buildX/database access during build
  • Run migrations and seed app store at container start
  • Is the app store script idempotent? If so, fine to run every container start. Otherwise, need a check before running it. Or, run it manually with something like docker compose run calcom npx ts-node --transpile-only packages/prisma/seed-app-store.ts

[krumware]

Remove submodule as trigger for GitHub action. I have a few ideas how this could be done, but it is probably better done by someone with access to test the GitHub actions (?) - it's a remote action trigger, still necessary because the release is actually performed in the cal.com repo. Using the release as an arg should be fine, the way you have it.
But another thought is this could be challenging for development workflow if folks still want to use a local directory with changes and not pull from remote every build. Is there a good solution to allow both?

I'm still working to get some confirmation on the changes that have allowed the removal of the build-time variable insertion.

[william-riley-land]

That makes sense. This set up assumes that the user wants to take the Dockerfile and get the software running as quickly as possible, but there are other considerations around publishing the official image and supporting workflows with custom updates to the codebase. Are there any of the updates from this PR that seem ready to go (or close)? I can pull them out into a separate PR if you'd like.

To me it seems straightforward for a user to change the main ADD line to a different git URL or just ADD . if needed. (As an aside, why not just include the Dockerfile in the main repo? Of course cal.com probably has a good reason for setting it up in its own repo, but it seems like an area where the build/publish process could be simplified.)

Note that by default, using ADD with a git link does not pull from the repo every time, it is cached and only pulled when the tag (or commit SHA) has changed. Of course if that layer is deleted, for example by running docker system prune, the repo will be pulled again. The pull takes only a few seconds, which is a small fraction of the build time in my experience.

[william-riley-land]

I've continued to work on this. I've made some updates and now I have it running with v4.0.7. I haven't pushed it here.

Is there any interest in any of the features in the PR? Zoom works fine; that's the only integration I am using though. Happy to run other tests if there is interest. Also happy to separate into smaller PRs, if the work is valuable to anyone else.