Helm
Hello, In order to have calendso work on our deployment stack we have created a helm chart in order to deploy new build of the calendso docker image easily on kubernetes.
Any feedback is welcome.
The only issues we've had was concerning the licensce env variable that doesnt seem to work
Thanks @finaldzn!
Can you fast forward the readme to include the most recent updates? Also, can you move the chart variables table and other relevant helm-specific items into a readme with the chart? We can link to those from the main readme to keep it clean.
re: the license env variable. There are a number of variables that need to be baked into the image at build time (known limitation of how calendly is trying to optimize use of runtime variables), this might be one of those. So it's on the radar for future, as long as we can specify a custom image path at helm install time.
Please allow some time for testing and review on this one. Thank you for the help!
Hello, I've fast-forward the branch and moved around the readme for the helm chart Let me know if you need anything else :)
Hey @krumware Have you manage to test deploying calendso on a K8S cluster using helm ?
Hi @finaldzn, this is still on my list, sorry for the delay!
My team might try to use this helm chart for deploying Calendso this week - we'll provide feedback along the way.
@finaldzn can you plz fast-forward the branch? There were some license env updates included in other PRs
@finaldzn also, it looks like you may have accidentally included secrets in your PR for google_api_credentials
That force push wiped out the helm additions
Hello, I've updated the branch to reflect the changes you asked. I remain avilable if you need anything else, we can help setting up the basic for an eventual chart museum integration. Thank you
Hello, i've fixed the remaning conflict. I think the branch can be merged now
Thanks @finaldzn! Quick opinion question: should we go ahead and move the appropriate env vars into secrets? Or should that be left up to the user?
@krumware I think that should be left to the user. Your env variable will be leaked if a hacker has access to your kubernetes cluster, if he has access to it then he also has access to the secrets.
@finaldzn FYI, there are some notable ENV variable changes incoming. you may want to keep an eye on my WIP pull request for the docker updates. Mainly NEXTAUTH_SECRET and NEXT_PUBLIC_WEBAPP_URL. In general, check out calcom/cal.com repo's .env.example
@krumware Alright, are the env variable set up at runtime now or is it in the works ? Otherwise it limts a lot the uses for the helm chart.
It's still a little bit muddy but things are evolving
Is this pull request still in consideration? I plan to deploy cal to my kubernetes soon and would love to hear some feedback if I should wait for integration to master or go with the feature-branch?
@krumware can you check?
I need to update the branch, but it might need a few adjustement haven't followed the latest release.
@PhilippKuntschik the branch needs to be updated to include updated changes, including env vars. I plan on taking a deeper dive this weekend as well as seeing if I can add Skaffold.
@krumware by chance do you had time to look at this ?
hey @finaldzn would you mind resolving the conflicts? 🙏

@PeerRich i think its done
@krumware can you check and approve / merge?
@finaldzn @krumware , I am not the author, but can I do something to get this merge request going? Can you point me to the "latest environmental variable changes" you are referring to?
@PhilippKuntschik You would need to take a look at the .env file and update the deployment.yaml and values.yaml file.
Unfortunately I'm away from my computer and I can't do it right now.
@PhilippKuntschik You would need to take a look at the .env file and update the deployment.yaml and values.yaml file.
Unfortunately I'm away from my computer and I can't do it right now.
no worries, just don't want the PR to go stale. If there is an ETA without my help of lets say 2-8 weeks, that's fine with me. If I can help, I assume I would require access to either calcom/docker or medconnectmd/helm repository, is that right?
@PhilippKuntschik You would need to take a look at the .env file and update the deployment.yaml and values.yaml file. Unfortunately I'm away from my computer and I can't do it right now.
no worries, just don't want the PR to go stale. If there is an ETA without my help of lets say 2-8 weeks, that's fine with me. If I can help, I assume I would require access to either calcom/docker or medconnectmd/helm repository, is that right?
would it help if we cherry pick new changes into a new branch that you open? or should we merge this and you make a follow up PR?
@PhilippKuntschik You would need to take a look at the .env file and update the deployment.yaml and values.yaml file. Unfortunately I'm away from my computer and I can't do it right now.
no worries, just don't want the PR to go stale. If there is an ETA without my help of lets say 2-8 weeks, that's fine with me. If I can help, I assume I would require access to either calcom/docker or medconnectmd/helm repository, is that right?
would it help if we cherry pick new changes into a new branch that you open? or should we merge this and you make a follow up PR?
I think the fastest way would be if you merge the changes into a feature-branch that I can fork from to open a new PR? no need to cherry pick that way.
@PhilippKuntschik Do you have any local changes for this that need to be pushed, or an active fork you want to reference? Thanks for the willingness to help here! attention is returning to this
Hello again guys, are the runtime env variable ready ? Because otherwise there is no point in adding the extra env to the templates becuse they couldn't be changed anyway.
Thanks