Use Scarf endpoint for Cal.com container

[arjundevarajan]

Update docker-compose.yaml to utilize Scarf endpoint for the Cal.com container. Scarf is a tool that allows maintainers to track open-source project adoption and usage metrics. Updating the image references in the docker-compose.yaml file to redirect through Scarf first lets these metrics be collected for product improvement

[krumware]

This can be done via a docker-compose.override.yml file, but I'm not sure if it belongs in the base

[aviaviavi]

The intention of this change is for the Cal.com team to have better visibility into the download metrics of the Docker installation. That's most effective when it's instrumented as a default, rather than being patched as an override.

[PeerRich]

fyi: i asked @aviaviavi to raise a PR, im just not sure what the implications are of merging this

[aviaviavi]

To give a bit more explanation: the idea is that when the Docker Compose installation is invoked, the calendso container will be downloaded from Cal.com's Scarf endpoint, where the client is then seamlessly redirected to Docker Hub. There is no user experience impact from this change but it does ensure anonymized download metrics are visible to your org.

[krumware]

understood, thanks for the context! we're moving to github packages. what we'll the URL look like for that?

[aviaviavi]

One of the cool parts is that you won't actually have to update this URL when you make that change. You can just update the configuration within Scarf to configure redirects to point to ghcr.io, and it will immediately start sending the traffic there. You'll never need to update the public URL that end-users download from, no matter how many times you switch container registries in the future.

[arjundevarajan]

Hi @krumware were there any other roadblocks here? Let us know if there's anything we can help with!

[krumware]

Shifting over to GitHub packages at the moment is all, a couple of things in flux there. Can you shoot me access to the admin client? (On the calcom slack is cool too)

[arjundevarajan]

Hi @krumware if you make an account at https://app.scarf.sh/register, @PeerRich should be able to add you as an admin to the Calcom org!

[krumware]

sent him a note, thanks!

[PeerRich]

created a scarf account: peer@cal.com, waiting to get admin access and will add @krumware then

[arjundevarajan]

Hi @PeerRich you are now the owner of the Calcom organization on Scarf, you should be able to add other users!

[PeerRich]

added krum

[krumware]

@arjundevarajan we've updated the config on scarf to pull from the new docker repository location of calcom/cal.com, but the package in scarf still shows the calendso/calendso pull command. Can you advise on how to change that?

[PeerRich]

here it still says calendso/calendso

[PeerRich]

should I create a new package?

[PeerRich]

i dont think you can rename existing packages

[aviaviavi]

Apologies @PeerRich and @krumware you were doing the right thing but it looks like there was a bug on our side causing the pull command to not update as expected. It's updated now.

[aviaviavi]

Keep in mind that you have the calendso/* collection in Scarf set up so the current docker compose file pointing to the old name still continues to work. When you're ready to move to GHCR we can move everything over at once.

[krumware]

We actually were able to obtain the calcom dockerhub organization, so we're hoping to eliminate the usage of calendso altogether. Is this possible while keeping the statistics?

[krumware]

thanks @aviaviavi, can we update the pull command again? we'd like to reflect calcom/cal.com instead of calcom/calcom (updated URL includes the period . in cal.com)

[arjundevarajan]

@krumware the pull command is updated!

[krumware]

thanks! updated on this end

[PeerRich]

thank you @arjundevarajan

[arjundevarajan]

@krumware what do you want the behavior there to be when someone tries to download the old calendso container from Scarf? Would you want it to break? Or to continue to go to the old Calendso container?

[krumware]

If someone still has the old calendar scarf.sh endpoint we would want that to pull from the updated calcom/cal.com docker hub 👍

[arjundevarajan]

Unfortunately this is not possible because container clients use that image name to compute a signature, so serving cal.com containers to users asking for calendso causes the clients to reject the download

[arjundevarajan]

Basically, we can either a) continue to send calendso requests through to DockerHub, or we can b) send calendso requests to something broken so the download doesn't work at all

[krumware]

Let's continue to send requests through to dockerhub, we don't want to break anyone. That's good to know on the naming. We're going to keep updating the calendso namespace, with a deprecation notice.

Thanks!

[arjundevarajan]

Sounds good. It looks like you also have an additional empty package set up on Scarf with a typo (calenSDo instead of calenDSo) - want me to go ahead and delete that incorrect one?

[PeerRich]

Sounds good. It looks like you also have an additional empty package set up on Scarf with a typo (calenSDo instead of calenDSo) - want me to go ahead and delete that incorrect one?

yes please

[arjundevarajan]

Done!