I may need more app-familiar eyes on my refactor before I would consider this no longer a draft PR and would be ready for review. Still, I think this container adheres to the implied restrictions of the license, namely the "no repackaging" clause.

By default, I set it to use the commit ID which was being referenced by the tricky to use

git submodules.

I think the method I'm using now is more robust and you can actually set it to use any upstream

REPOSITORY_URL

if you want to locally pin your own fork to your own deployed build rather than the mainline. This should allow for a better streamline for developers trying to produce code for PR's.

As I'm not really familiar with how Node apps exactly work behind the invocation commands I'm not really sure what a couple of the features such as

--max-old-space-size=

does but I included it as a configurable option for invocation.

Also, I would genuinely prefer not to require the

prisma studio

the container itself is a pre-requisite for adding a user, so if someone knew what commands I would use for testing for default users and creating one, I would happily bake them into

start.sh

One challenge with the PR, is that moving everything out of the dockerfile bypasses the packaging benefits of containers. In many cases, it's considered anti-pattern to push everything into a shell script. This also can be particularly frustrating to users who clone and build from systems with different line endings. One compromise though, is that there can be merits of the bootstrapping scripting, and the contents of the dockerfile doesn't necessarily need to be removed in order to gain some of those merits

Right now, it looks like all of the build-time pieces were removed, and the bootstrapping would likely introduce a long startup time, as well as startup resource requirements

I see that there's a basic boot mode, but if the bootstrap and a volume definition isn't already there, then that looks like it won't run on first boot

(and early apologies too, there's a lot to dig into, so if I missed something I'm sorry! I also am intending for this to be good feedback without criticism!)

My ideal scenarios: For developers: dependencies should be preinstalled, allowing for instant boot with optional filesystem mounting. For users in production: container should boot nearly instantly, and container should be immutable, with controlled runtime configuration via environmental variables/secrets

Thanks a lot for the speedy feedback! It's helpful because if these replies were weeks from now, they might be out of working memory. 😆

I mean, correct me if my assumptions are wrong with how the app works with build time versus boot time functions, but it seems as though when deploying this, you need access to the Postgres DB.

Anyways thanks for the time and attention to the Pull Request hopefully someone tests how it works and sends me some feedback tailored to getting it running smoothly and even better if we can merge it.

https://github.com/calcom/cal.com/discussions/3449 I was hoping to get some eyeballs on this issue? (thanks @zomars for pointing me to this channel. I didn't notice it existed)

@Colin - Krumware I was really hoping to get this PR at least to a working state. Was your feedback the blocking issue I should resolve despite my possible misunderstanding that it functions as it might have to?

Sorry, I just haven't had the time to jump into. I did finally wrap up the arm64 automated build, ready for @Peer’s review. I still plan to take a deeper look into it

Oh, awesome! Thanks, I was a little disheartened for a moment there. Hopefully, this won't have any blocking reason not to be buildable for any specific architecture.

Realistically a big thing that I can skip is building the app in production and even git pulling on the target if there are some details satisfied. 1. @Peer or someone gives consent to allow the software to be packaged in the docker container. 2. Also, if the app can be confirmed whether or not it needs to be built next to the production Postgres database or not. 3. Finally just need to figure out the tidbit I'm missing to get the Cal service started.

function basic_start() {
  cd $APP_PATH
  echo "Waiting for a healthy Postgres server connection prior to booting."
  wait-for-it.sh $DATABASE_HOST -- echo "database is up"
  npx prisma migrate deploy --schema $APP_PATH/packages/prisma/schema.prisma
  npx ts-node --transpile-only $APP_PATH/packages/prisma/seed-app-store.ts
  echo "Final systems checks cleared and are go for launch."
  yarn start
}

This container also exposes a lot of configurability right on the front end as well.

Hey @Peer I noticed I got a Github org invite.

If my PR gets to a point where its merge-able I'll try and add Docker Secret support as well from PR #77

https://github.com/calcom/docker/pull/77/files looks pretty good but I think I'd use the

ifndef

function I added to ensure that Docker Secrets are read on sensitive variables.

fyi i am no docker expert, just a guy with admin access 🙏

@Colin - Krumware is likely a good point of contact

Fair, I feel like I've been handed quite the torch of power here. I'm happy to make it go. However, I still would like to hear if you're good with my packaging the Cal source code into the Docker container because technically, we're "community contributors," and the container functionality is technically repackaging.

I guess having this under the Calcom org itself is technically permission.

Hey Team, do we have any updates on https://github.com/calcom/docker/issues/122 Thanks

I believe the migration issue embedded in the thread was resolved

While deploying the calcom docker-compose, I didn't find the experience to be very smooth. Start database, build calcom, start prisma, add user using prisma, start calcom. Ideally prisma (seeing it for the first time so not sure how feasible it is going to be what I say next) should connect to the database after everything has been initialized. Just thinking out loud here, database should start, an init script should intialize it, and then calcom should connect to the database directly after that. Is there anyway I can contribute to have the experience be this way ?

Most of the effort is related to requirements on the build side. There is also a first-start setup wizard coming. The core team is aware of the issues and has tasks in place, stay tuned

Hi guys - do you have official containers somewhere I can pull or do I have to build them all by myself?