feat(templates): add Cal.diy self-hosted scheduling starter - #928
Open
dviejokfs wants to merge 5 commits into
Open
feat(templates): add Cal.diy self-hosted scheduling starter#928dviejokfs wants to merge 5 commits into
dviejokfs wants to merge 5 commits into
Conversation
Cal.diy is Cal.com's MIT-licensed, self-hosted community edition. Adds it as a project-creation starter (git+Dockerfile build, Postgres service dependency) so operators can self-host booking/scheduling infrastructure on Temps instead of a SaaS like Calendly. Upstream recommends personal/non-production use only, so this ships as a starter template rather than a version-pinned "service" catalog entry. Signed-off-by: David Viejo <dviejo@kfs.es>
Greptile SummaryThe PR replaces the Cal.diy source-build starter with an immutable service template and adds architecture-specific image selection.
Confidence Score: 5/5The PR appears safe to merge because the previously reported mutable-source deployment path has been replaced by immutable image deployment. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| crates/temps-core/src/templates.rs | Adds the optional architecture-specific image field and enforces immutable digests for service templates. |
| crates/temps-core/templates/services/cal-diy.yaml | Defines Cal.diy as a service template using immutable amd64 and arm64 image digests. |
| crates/temps-projects/src/handlers/handlers.rs | Resolves architecture-specific images before serving or creating projects and adds focused selection tests. |
| crates/temps-projects/src/handlers/templates.rs | Exposes the optional arm64 image variant in template API responses. |
Flowchart
%%{init: {'theme': 'neutral'}}%%
flowchart LR
A[Load service template] --> B{Console host architecture}
B -->|aarch64| C[Select image_arm64 digest]
B -->|other| D[Select default image digest]
C --> E[Return resolved template]
D --> E
E --> F[Create DockerImage project]
F --> G[Persist immutable image runtime]
G --> H[Deploy pinned image without source build]
Reviews (4): Last reviewed commit: "fix(templates): pin Cal.diy to calcom/ca..." | Re-trigger Greptile
Moves the Cal.diy template from templates/starters/ to templates/services/ so it appears in the "Services" gallery alongside Keycloak and Browserless, matching the pattern of a curated app backed by a Temps-managed PostgreSQL database. This requires a version-pinned, sha256-digest-locked image, which the previous starter entry avoided for lack of a verified one. docker.io/calendso/calendso publishes real tagged releases (cal.diy's image is still shipped under its pre-rename name) — pinned to v6.2.0, the latest release. Postgres connectivity is wired via managed_service_bindings (DATABASE_URL/DATABASE_DIRECT_URL <- POSTGRES_URL) instead of manual copy-paste env vars, since bindings are only resolved for service-kind templates. Signed-off-by: David Viejo <dviejo@kfs.es>
…emplates Some upstream projects don't publish a real multi-arch manifest under one tag/digest -- amd64 and arm64 ship as separate, separately-versioned images instead. cal-diy's v6.2.0 image (docker.io/calendso/calendso) is one of these: it 404s pulling on arm64 hosts because the pinned digest only ever resolves to the amd64 variant. Adds an optional `image_arm64` field to service templates (same pinned-digest validation as `image`), exposes it through the API, and resolves between the two at project-creation time based on the host architecture. This assumes a homogeneous fleet since the deploy target's architecture isn't known until scheduling, after project creation -- true per-node arch-aware resolution would need to move into the deploy path, which is out of scope here. cal-diy.yaml now pins both variants: amd64 -> v6.2.0, arm64 -> v6.2.0-arm. Signed-off-by: David Viejo <dviejo@kfs.es>
… sees it The create-project form always submits template.image as an explicit runtime override, even when the user never edited it -- so the arch-selection fallback added in resolve_image_template_runtime never actually ran for a real UI-driven deploy: by the time the request arrives, an untouched default is indistinguishable from a deliberate override. Resolves image vs image_arm64 by host architecture in the two template-serving endpoints (list_project_templates, get_project_template) instead, so the value the form is pre-filled with -- and therefore submits -- is already correct. Signed-off-by: David Viejo <dviejo@kfs.es>
…endso Same release build, same digests (verified: identical sha256 for both v6.2.0 and v6.2.0-arm) -- calcom/cal.com is just a better-known alias for the same push. calcom/cal.diy, the name matching the project's own git repo, has no tags published to it as of this writing, so it can't be used. Signed-off-by: David Viejo <dviejo@kfs.es>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
crates/temps-core/templates/starters/cal-diy.yaml, a project-creation starter for Cal.diy (Cal.com's MIT-licensed, self-hosted community edition of Calendly-style scheduling)dockerfilepreset (it ships a rootDockerfile), requests a linkedpostgresservice, and declares the real required env vars sourced from cal.diy's own.env.example(DATABASE_URL,DATABASE_DIRECT_URL,NEXTAUTH_SECRET,CALENDSO_ENCRYPTION_KEY, etc.), marking credential-shaped valuessecret: truetemplates/starters/(source-build) rather thantemplates/services/(the pinned-image catalog): theservices/validator requires an immutablesha256-pinned image, and there's no verifiably published runnable image for cal.diy to pin (its GHCR listing only shows a build-cache package)Why
Lets operators self-host scheduling/booking infrastructure (e.g. for a "book a setup call" onboarding step) on Temps instead of a SaaS like Calendly, consistent with the no-vendor-lock-in self-hosting story.
Test plan
cargo test --lib -p temps-core templates::— 34 passed (bundled catalog parses and validates)cargo check --lib -p temps-core— cleanpython3 scripts/source_attribution.py check— passed