CI/CD · dazo/docs

All three workflows run on self-hosted runners, not ubuntu-latest. The runner machine is the target server itself — there is no artifact transfer; the build happens directly on the production server.

The three workflows

Workflow	Branch trigger	Runner label	Deploy directory
`deploy_production.yml`	`v3`	`self-hosted, production`	`${{ vars.PROJECT_DIR }}` (repo variable)
`deploy_staging.yml`	`staging`	`self-hosted, staging`	`/home/dazo-dev-app/htdocs/app.dazo.dev.cicd`
`deploy_toko_digital.yml`	`toko_digital`	`self-hosted, toko_digital`	`/home/deployer/app/dazo.toko-digital`

Trigger

yaml

on:
  push:
    branches:
      - v3   # or staging, or toko_digital

No workflow_dispatch, no pull_request trigger, no approval gate. The only way to trigger a deploy is to push to that branch.

Deploy steps

All three workflows are nearly identical. The sequence: checkout → clear cache → git fetch + git reset --hard → install dependencies → build frontend → fix permissions.

Key differences:

Production uses ${{ vars.PROJECT_DIR }} for the path (GitHub repo variable); staging and toko_digital use hardcoded paths
Staging and toko_digital add NODE_OPTIONS="--max-old-space-size=4096" to the build step
The permissions fix step (sudo /usr/local/bin/chmod-dazo.sh) runs only in production and staging, not toko_digital

What’s missing

No automated tests before deploy, no build verification, no lint, no mandatory staging gate, no approval gate, no automatic rollback, no post-deploy notification, no inter-run dependency cache.