---
name: rmm-dashboard-beta-before-main
description: GuruRMM website/dashboard changes must be tested on beta BEFORE being pushed to main, unless told otherwise
metadata:
  type: feedback
---

For the GuruRMM **website/dashboard**, Howard wants changes to land on the **beta
test site first** (`https://rmm-beta.azcomputerguru.com`) and be tested there
**before** the branch is pushed/merged to `main` — unless he explicitly says
otherwise. Production is `https://rmm.azcomputerguru.com`.

**Why:** he wants to eyeball UI/UX changes against real data before they go
anywhere near the main branch / production.

**How to apply:**
- Do NOT merge dashboard changes to `main` to get them onto beta. The webhook
  pipeline auto-builds beta *from* `origin/main` (`deploy/build-pipeline/build-dashboard.sh`
  does `git reset --hard origin/main`), so merging to main is exactly what he's
  trying to avoid doing first.
- Instead, deploy the **feature branch** to the beta web root manually: build the
  branch's `dashboard/` (VITE_API_URL unset → bakes the prod API URL, same as the
  pipeline) and rsync `dist/` to `/var/www/gururmm/dashboard-beta/` on the server.
  Use a `git worktree` off the existing `/home/guru/gururmm` checkout so the main
  checkout isn't disturbed. Do NOT update `/opt/gururmm/last-built-commit-dashboard`
  (leave it so the next real main push rebuilds beta from main and reclaims it).
- Beta talks to **live production data/API**, so the preview is real — safe to
  click through, but running an installer enrolls a real agent (use a throwaway
  test site/device).
- Promotion beta→prod is a separate, human-run step: `sudo /opt/gururmm/promote-dashboard.sh --confirm`.
- A cleaner long-term fix would be a pipeline option to build a named branch to
  beta; until then it's the manual worktree build above.

Related: [[gururmm-deploy-pipeline]]