Updating Herald

Updating Herald

⚠️ On a version before 1.26.0? The in-app Update button won't get you past this one version boundary — see Upgrading from before 1.26.0 below, or the full consolidated checklist: Upgrading past 1.26.0 — read this if anything broke.

The installed version is shown in the web UI's Global Settings tab, with a Check for Updates button that compares it against the latest release on whichever branch is selected in the dropdown next to it — Main (the tested release channel, and the default on every page load) or Develop (beta testing, shows the same untested/incomplete-features warning as the README). Herald also checks automatically once a day in the background, always against main regardless of what's selected in the dropdown — the automatic check has no page open to read a selection from, and only a real release should ever trigger the "Update available" header badge. Clicking that badge jumps to the Global Settings tab.

An Update Herald button runs the actual update without needing to SSH in, from whichever branch is currently selected in the same dropdown:

• Defaults to main on every page load — the selection is never remembered across reloads, so leaving it on Develop and coming back later can't silently target the wrong branch next time
• Downloads and runs the same install.sh a manual update would (with --branch develop automatically added when Develop is selected — the same flag the manual develop-install command below uses)
• Restarts the service, and verifies it actually comes back up on the new version (a real post-restart health check — service active and version file matches — not just "the restart command didn't error") before reporting success
• Runs in the background so the page doesn't hang waiting on it; a live progress panel shows each stage (backing up → downloading → installing → restarting → done)
• The button is disabled server-side (not just in the browser) while an update is genuinely in flight, so a second click — or a second browser tab — can't start a duplicate update on top of it
• Backs up your current config before making any changes — see Backup & Restore

A brief service restart (a few seconds) happens as part of any update — expected, not an error.

If the button says a manual update is required

Herald checks GitHub for a small update-notice.json file every time it checks for updates (same schedule as the version check above). If a future release ever breaks the Update button itself the way the 1.26.0 rename once did — see Upgrading from before 1.26.0 below — this is how it warns you before you click a button that would otherwise silently do nothing: a red warning appears with specific instructions, and the Update Herald button is disabled (both in the browser and on the daemon's own side, so a stale cached page can't bypass it either).

This also fails closed, not open: if Herald can't reach or parse that file at all — including if the GitHub API path itself ever stops resolving, the exact failure mode a repo rename would cause — it assumes a manual update may be needed rather than silently assuming everything's fine. You'll see a generic version of the warning pointing at the manual install command in that case, even without a specific notice being set. This can also show up briefly on an ordinary network hiccup; clicking Check for Updates again once connectivity is back clears it.

(Maintainer note: to warn users of an upcoming breaking change to the update mechanism itself, edit update-notice.json at the repo root — {"manual_update_required_below": "1.30.0", "message": "..."} — as part of or just before the release that introduces the break. Reset both fields to null once the affected version range has aged out.)

Manual / CLI Update

Same commands install.sh itself uses, if you'd rather update over SSH:

curl -fsSL -H "Cache-Control: no-cache" https://raw.githubusercontent.com/N6LKA/AllStar-Herald/main/install.sh | sudo bash

See Getting Started for what the installer does — running it again over an existing install is how both the web UI's Update button and a manual update work under the hood.

Upgrading from before 1.26.0

1.26.0 renamed the GitHub repo from ASL3-Herald to AllStar-Herald (issue #47) and scrubbed the old asl3-herald naming out of every path/file. GitHub redirects the old repo URL automatically, but its archive/tarball download always names the extracted folder after the current repo name — even when requested through the old URL. Any install older than 1.26.0 has the old folder name (ASL3-Herald-main) hardcoded into its self-update step, so that step can't find install.sh inside the downloaded tarball. The update silently does nothing, and the Update button (or the daily background check) leaves you on your old version with no clear error.

This can't be fixed by clicking Update — the broken logic is baked into the code that's already running on your system. One-time fix, run manually over SSH:

curl -fsSL -H "Cache-Control: no-cache" https://raw.githubusercontent.com/N6LKA/AllStar-Herald/main/install.sh | sudo bash

This bypasses the broken tarball-extraction step entirely and installs 1.26.0 directly. After that one-time manual run, the in-app Update button works normally again — this only affects crossing this specific version boundary.

Also check for stale references to the old asl3-herald paths in places install.sh doesn't manage:

• idrecording in rpt.conf, if you've set up the Node ID Generator — this line is entirely your own manual edit to Asterisk's own config, so it's never touched by install.sh. If it still reads /etc/asterisk/scripts/asl3-herald/node-id/node-id, update it to /etc/asterisk/scripts/herald/node-id/node-id and run sudo asterisk -rx "rpt reload" (or restart Asterisk if that doesn't pick it up).
• ASL3-SkywarnPlus-NG-Bridge, if you use it for a weather panel on Allmon3/Supermon — its Weather.JsonPath needs to point at Herald's new weather.json location. Fixed automatically if you update the bridge itself (1.26.0+ of the bridge migrates this the same way Herald's own installer does); otherwise edit /etc/asl3-swp-ng-bridge/config.yaml by hand and re-run the bridge once.
• Any other script or program you've pointed at a Herald-managed file (announcement WAVs, weather.json, etc.) using its old /etc/asterisk/scripts/asl3-herald/... path will need the same one-time path update — Herald's own migration only rewrites what it manages directly (its own config and integration links), not third-party references to it.