#!/usr/bin/env bash
# Deploy (or roll back) Bloom to PRODUCTION.
#
# Production runs the SAME build-once, deploy-many mechanism as dev: it pulls the CI-built,
# SHA-tagged image from the registry and runs it (deploy), or restores the previously-good tag
# (rollback). This script is the single seam for the production target - switching providers later
# is a change to this one file, not the workflow or the app.
#
# Contract from the workflow (deploy-production.yml), via the environment:
#   MODE             - "deploy" (default) or "rollback"
#   BLOOM_IMAGE_TAG  - the image tag to deploy (deploy mode; e.g. sha-abc123def456)
#   REGISTRY_USER / REGISTRY_TOKEN - registry credentials to pull the image
#   DEPLOY_HOST / DEPLOY_SSH_KEY   - the production VM (set on the `production` environment)
#   arg 1            - the rendered env file (from render-env.sh, `production` env config)
#
# Current provider: a VM over SSH, identical to dev - so once the `production` environment has
# DEPLOY_HOST + DEPLOY_SSH_KEY (and its own bot/DB/domain config), production deploys and rolls
# back by tag through the proven scripts/deploy/exedev.sh path. If you later choose a different
# provider (PaaS, Kubernetes, ...), replace the delegation below with that provider's deploy/
# rollback for a tagged image; keep the same MODE + BLOOM_IMAGE_TAG contract.
set -euo pipefail

if [ -z "${DEPLOY_HOST:-}" ]; then
  echo "::error::Production deploy is not configured yet: set DEPLOY_HOST + DEPLOY_SSH_KEY on the \
'production' environment (a VM target, same shape as dev), or implement a different provider in \
scripts/deploy/production.sh. The MODE + BLOOM_IMAGE_TAG (deploy-by-tag) contract stays the same." >&2
  exit 1
fi

# Production is a VM over SSH today: reuse the exact tagged-image deploy/rollback mechanism as dev.
# MODE, BLOOM_IMAGE_TAG, REGISTRY_*, and DEPLOY_* are read from the environment by exedev.sh.
exec bash scripts/deploy/exedev.sh "${1:-env.generated}"
