e0f2a5d66a
Some checks failed
continuous-integration/drone/push Build is failing
New recipe recipe-maintainers/Libre-Desk (abra TYPE=libredesk): app libredesk v2.4.0 on :9000 + postgres:17 + redis:7. Adds: - recipe_meta.py: /health probe, BACKUP_CAPABLE (backupbot db labels), upgrade EXPECTED_NA (only one published version so far), WARM_CANONICAL. - install_steps.sh: insert format-compliant enc_key (32-hex) + admin_pwd (upper+lower+num+special) before deploy — abra's generic generator doesn't satisfy LibreDesk's strict secret formats. - custom/: /health 200 probe + served-shell brand/asset probe (real app, not a fallback 200).
33 lines
2.0 KiB
Python
33 lines
2.0 KiB
Python
# Per-recipe harness config for libredesk (LibreDesk — open-source, self-hosted customer-support /
|
||
# help desk; recipe repo recipe-maintainers/Libre-Desk, abra TYPE=libredesk).
|
||
#
|
||
# Stack (compose.yml): app (libredesk/libredesk:v2.4.0, serves on :9000 behind Traefik) + db
|
||
# (postgres:17-alpine, user/db=libredesk) + redis (redis:7-alpine). abra-entrypoint.sh self-installs
|
||
# the schema and runs migrations on boot (`--install --idempotent-install` then `--upgrade`), so the
|
||
# stack comes up ready with no post-deploy step.
|
||
#
|
||
# Secrets have STRICT formats that abra's generic generator does not satisfy, so install_steps.sh
|
||
# inserts compliant values before the single deploy (see that file):
|
||
# - enc_key must be 32 hex chars (AES-256 key) → openssl rand -hex 16
|
||
# - admin_pwd must be 10–72 chars, upper+lower+num+sym → the "System" user's password
|
||
# - db_password is abra-generated (no special format) and left as-is.
|
||
|
||
HEALTH_PATH = "/health" # the app's own healthcheck endpoint (compose hits :9000/health)
|
||
HEALTH_OK = (200,)
|
||
DEPLOY_TIMEOUT = 600 # app + postgres + redis; app runs install+migrate on first boot
|
||
HTTP_TIMEOUT = 300
|
||
BACKUP_CAPABLE = True # db carries backupbot.backup labels (pg_dump pre-hook / psql restore-hook)
|
||
|
||
# Only one published version exists so far (0.1.0+v2.4.0), so there is no PRIOR deployable base to
|
||
# upgrade FROM — the upgrade rung is intentionally N/A (a declared skip, never promoted to a pass).
|
||
# Drop this once a second version is published; the dynamic base then resolves it (last-green warm
|
||
# canonical → same-version step-back → main tip).
|
||
EXPECTED_NA = {
|
||
"upgrade": "only one published version so far (0.1.0+v2.4.0) — no prior deployable base to "
|
||
"upgrade FROM yet; drop this when a second version ships",
|
||
}
|
||
|
||
# canon §2.B: enroll as a DATA-WARM canonical (all recipes enrolled — operator 2026-06-17).
|
||
# The weekly sweep promotes this recipe's canonical to its latest green RELEASE TAG.
|
||
WARM_CANONICAL = True
|