2.0 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| reference_gururmm_pipeline_vendored | GuruRMM build-pipeline scripts are now version-controlled at deploy/build-pipeline/ in the gururmm repo (2026-06-01); build-shared.sh auto-syncs them to /opt/gururmm each build, so edit-in-repo + push = live — EXCEPT build-shared.sh + webhook-handler.py, which need a manual cp. |
|
The GuruRMM build/CI pipeline runs at /opt/gururmm/ on the gururmm server (172.16.3.30,
root-owned, hand-maintained). Those scripts had silently diverged from the repo's older scripts/
generation (that drift caused the BUG-015 Windows build-gate gap). Reconciled 2026-06-01:
- Source of truth: the live scripts are vendored into the gururmm repo at
deploy/build-pipeline/(build-{windows,linux,mac,agents,server,shared}.sh, sign-windows.sh, webhook-handler.py + README). Commit2bf539e. - Drift-stop (commit
24b5daf):build-shared.sh(runs first every build, aftergit reset --hard origin/main) nowinstall -m 0755-syncs the 6 build scripts fromdeploy/build-pipeline/→/opt/gururmm/each build. So to change a GuruRMM build script: edit it indeploy/build-pipeline/, push to gururmm main — the next build runs it. No manual copy, no restart. - Two exceptions — need a manual
sudo cpon change (they can't self-overwrite mid-run):build-shared.sh(the running puller) andwebhook-handler.py(the persistent HTTP server; also needssudo systemctl restart gururmm-webhookto reload). They change rarely. Seedeploy/build-pipeline/README.md.
Webhook still INVOKES the /opt/gururmm copies (not the repo copies directly) — the sync keeps
them current. The repo's older scripts/webhook-handler.py + scripts/build-agents.sh are a prior
generation, superseded. Build-windows.sh's change-gate watches agent/ installer/ (BUG-015 fix —
installer-only .wxs/.ico changes rebuild the MSI). Supersedes the "repo copy is stale, don't
redeploy" caveat in project_rmm_webhook_docs_guard for the build scripts (not webhook-handler.py).