35 lines
1.8 KiB
Markdown
35 lines
1.8 KiB
Markdown
---
|
|
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]]
|