1.8 KiB
1.8 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| feedback_gururmm_build_channel_default | GuruRMM build pipeline must tag NEW builds beta by default; stable is an explicit promote step. Distinct from agents defaulting to the stable CHANNEL (which is correct). |
|
GuruRMM has two separate "stable" concepts that were conflated in a misunderstanding (corrected by Mike 2026-06-01):
- Agent channel default = stable — CORRECT and intended.
server/src/dbresolve_agent_channelreturns "stable" when an agent/site/client has noupdate_channeloverride. Agents with no override should inherit the stable channel. Leave this as-is. - Build classification default = beta — the FIX. New agent binaries must be tagged
betaby default (a<binary>.channelsidecar = "beta"); promotion tostableis a deliberate, explicit re-tag after a canary verifies. The bug:deploy/build-pipeline/build-windows.shandbuild-linux.shtagged every new buildstable("Mark all new builds as stable by default"), which collapses the beta soak —scanner.rs::get_latest_versiongives beta agents the absolute-latest binary and stable agents the latest stable-tagged one, and withauto_updateon-by-default the whole stable fleet self-updates on reconnect. macOS already does it right (agent/build-macos-pkg.shwrites "beta").
Why: enables beta-first canary rollout (e.g. soak a release on GURU-5070 before the ~46-agent fleet). Mike originally asked for "all agents on the stable channel by default", NOT "all builds classified stable".
How to apply: when releasing GuruRMM agents, expect new builds to land on beta only. Promote to stable explicitly (re-tag the .channel sidecar to "stable" on the server downloads dir) after verifying on a beta box. See feedback_gururmm_builds (builds go through the Gitea webhook pipeline, never run build scripts by hand).