claudetools/.claude/memory/rmm-dashboard-beta-before-main.md

name, description, metadata

name	description	metadata
rmm-dashboard-beta-before-main	GuruRMM website/dashboard changes must be tested on beta BEFORE being pushed to main, unless told otherwise	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