# On hold — test environment + two-environment pipeline

Only `erp.hexdive.com` exists today, so since 2026-09-15 production is deployed Fitness-style by the
`Build & Deploy` job in `.gitea/workflows/ci-cd.yml`, the one workflow that also runs the PR checks
(docs/40-DEPLOYMENT.md, "Active"). Everything in this folder is the
**test + release** design built on 2026-09-14, kept intact but **inactive**: Gitea only runs workflows
from `.gitea/workflows/`, and nothing active calls these scripts.

| File | What it did |
|---|---|
| `deploy.two-env.yml` | The two-environment workflow: push to `Dev` → test, push to `production` → release; tree-hash change detection against the last successful deploy; nightly Playwright against test; Gitea release per production deploy |
| `scripts/detect.sh` | Decided which side to deploy by comparing tree hashes with `/opt/erpcore/<env>/.deployed` |
| `scripts/build-backend.sh`, `scripts/build-frontend.sh` | Capped container builds into versioned `/opt/erpcore/releases/backend/<hash>` and `erp-web:<hash>`, reused across environments |
| `scripts/deploy-backend.sh`, `scripts/deploy-frontend.sh` | Backup → symlink switch → health check → automatic rollback to the previous release |
| `scripts/release.sh` | Gitea release + `release-YYYY.MM.DD-N` tag with rollback hashes |
| `scripts/e2e.sh` | Playwright suite against test |
| `scripts/prune.sh` | Weekly cleanup of releases, images, backups, reports |
| `apache/test-erp.hexdive.com.conf` | Apache vhost for the test environment |
| `systemd/erpcore@.service` | Unit template for `erpcore@test` / `erpcore@release` |

The full design is documented under **"On hold: two-environment design"** in `docs/40-DEPLOYMENT.md`.

## Bringing it back
1. Create `test-erp.hexdive.com` (DNS + certificate) and do the server bootstrap in that doc section.
2. Move `scripts/*.sh` back to `deploy/scripts/` (they source `common.sh` from their own folder), `apache/` and `systemd/` files back
   to `deploy/apache/` and `deploy/systemd/`, and `deploy.two-env.yml` to `.gitea/workflows/deploy.yml`.
   Then **delete the `build-and-deploy` job from `.gitea/workflows/ci-cd.yml`** (or two workflows will deploy production), remove
   `closed` from its `pull_request` types and the `workflow_dispatch` block, and give it back a per-PR concurrency group
   (`ci-${{ github.event.pull_request.number }}`, `cancel-in-progress: true`) — at that point it is the old `ci.yml`.
   `deploy.two-env.yml` triggers on `push`, so it cannot share one file with the PR checks the way the production-only job does.
3. In `deploy/scripts/common.sh`, uncomment the `test)` and `release)` branches of `load_env` and the `Dev) echo test` mapping.
4. In the checks' `frontend` job, point it back at `build-frontend.sh` with `WITH_CHECKS=true` if you want PR-built images reused by the deploy.
5. Decide how to migrate production from `/home/erp/core/publish` + `erpcore.service` to the versioned
   `/opt/erpcore/release/backend/current` layout + `erpcore@release` (or adjust the scripts to keep the production layout).