sync: auto-sync from HOWARD-HOME at 2026-06-21 12:00:27
Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-06-21 12:00:27
This commit is contained in:
34
.claude/memory/rmm-dashboard-beta-before-main.md
Normal file
34
.claude/memory/rmm-dashboard-beta-before-main.md
Normal file
@@ -0,0 +1,34 @@
|
||||
---
|
||||
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]]
|
||||
Reference in New Issue
Block a user