fix: production ready docker build with ci workflow

[ChichiCaleb]

What does this PR do?

builds a production ready docker image

• builds a leaner and more secure docker image (< 1/3) the size of the current calcom image

• abilty to change host and any chosen inlined build time variable with runtime variable

• db migration at runtime

• implemented postgres healthcheck and service_healthy option in compose removing the need for wait-for-it script

• ability to run unit test in docker

builds a full featured ci with ability to:

• build a test image and push to GHCR which will subequently be pulled by integration-test
  and trivy scan jobs for their respective actions

• builds and runs unit test specified in the repo by targeting unit-test layer of multistage docker build
  however uses the cache from test image to save time

• pulls test image from GHCR and runs integration test in docker compose

• pulls test image from GHCR and run a trivy vulnerability scan for high and crtical CVEs (non-blocking)
  and uploads the sarif result to github security tab

• generates changelog.MD file and create releases using conventional commits.

  • creates a prelease when a pull request is made to main branch following a succesful unit and integration test.

  • creates a release when a merge is made to the main branch and adds either the prelease or released version to github output to be used by final image published to docker hub

• builds the final image and adds latest tag and image:V*.*.* semantic versioning tag to merge request
  and image:v*.*.*-alpha.* tag to pull requests made to main branch before pushing to dockerhub

  • this is automated by the use of conventionalcommits

• adds the Docker image tag(s)/labels pushed to docker hub,to the pull request comment section for reference purpose

Fixes #12032

Requirement/Documentation

• In repo settings under actions enable:

  • Read and write permissions

• create a github Personal access Token and add as repo secret with the name RELEASE_MAIN for automated
  changelog generation and release enabling the following:

  • Repo
  • workflow
  • write package
  • admin:org

• In repo settings under rules enable:

  • repository admin bypass list

Type of change

• Chore (refactoring code, technical debt, workflow improvements)

How should this be tested?

  git clone https://github.com/calcom/cal.com.git

• Duplicate .env.example to .env in infra/docker/web

• A workflow flow run, pull request or merge request triggers the ci workflow

• start the services in docker compose and test locally with:

  docker compose -f infra/docker/web/docker-compose.yaml up

Mandatory Tasks

• Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
2 out of 3 committers have signed the CLA.

✅ zomars
✅ keithwillcode
❌ chichi

---

chichi seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[github-actions]

Thank you for following the naming conventions! 🙏 Feel free to join our discord and post your PR link.

[github-actions]

📦 Next.js Bundle Analysis for @calcom/web

This analysis was generated by the Next.js Bundle Analysis action. 🤖

This PR introduced no changes to the JavaScript bundle! 🙌

[keithwillcode]

Wow, thanks so much for this contribution, @ChichiCaleb. We’ve slotted it to be reviewed during the 3.9 milestone which starts the 15th. 🙏🏼

[ChichiCaleb]

thanks for the great work this community has been doing

[vercel]

Someone is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[zomars]

If we merge this PR means that the calcom/docker repo would be deprecated?

[keithwillcode]

What are these placeholders needed for?

[ChichiCaleb]

It is needed by the replace-placeholder.sh due to next.js inline embedding of variables to avoid multiple docker image build for each environment.

• The script reads each line from the placeholder.yml file, splits it into a key and a value based on the colon (:) delimiter, and trims any leading or trailing whitespace from the key and value.

• For each key-value pair from the placeholder.yml file, the script iterates over all environment variables (could be docker compose env variable or even env variable in kubernetes manifest)to find a match. If a match is found and the environment variable has a non-empty value, the script uses sed to replace the placeholder value in the .next folder with the environment variable value. It excludes .git directories from this operation.

SO basically the keys in placeholder.yaml are used to check for similar entries in env variable
while the values in placeholder.yaml are used to check for actual strings that need replacement in .next folder

this is the best I could come up with as at the time to enable reusable single docker build

[keithwillcode]

Going to put this back into draft for now as there are a couple of things I'd like to put into this

1. Remove the job we have in the repo that kicks off the downstream Docker jobs in cal.com/docker.
2. Deal with the placeholder environment variables.
3. Change this a bit so that it doesn't run these expensive Docker builds too often. We recently introduced a ready-for-e2e label that is checked before running the entire E2E test suite, since it's slow and expensive. Would like to introduce something similar for this.

[compgeniuses]

its funny how everytime there is a major Update released, i ussuall come back here to check on this PR if its been merged.

[compgeniuses]

whatever happened with this PR actually

[retrogtx]

Closing due to staleness. Don't hesitate to re-open when ready!