← Back to docs

CI/CD and Deployment

How releases are built, published, and applied to the running service.

Release flow

  1. Commit and push to main
  2. Tag the release: git tag vX.Y.Z && git push origin vX.Y.Z
  3. GitHub Actions (release.yml) triggers on the tag push:
    • Builds binaries for all platforms
    • Publishes linux-amd64 and linux-arm64 to releases.experiencenet.com/hydrastreamingmonitor/production/
    • Finalizes the release (updates latest.json)
    • Creates a GitHub Release with all binaries attached

The running service on 78.47.174.83 polls for updates every 6 hours. After tagging, the new binary is live on the release server within ~2 minutes (CI build time), but the running service will not pick it up until its next scheduled check.

Forcing an immediate update

Until issue #382 is resolved (a CI-triggerable update endpoint), there is no in-process command to force an update. The CLI only has serve and version (internal/cli/root.go) — there is no update subcommand, despite what earlier revisions of this doc said.

systemctl restart hydrastreamingmonitor alone does not help: the auto-updater (hydrarelease/pkg/updater, StartAutoCheck) sleeps the full 6h interval before its first check — there is no check-on-start — so a plain restart just re-runs the same binary that was already on disk.

To force an immediate deploy, replicate what the updater itself does on the server:

VERSION=vX.Y.Z   # the tag you just released
ssh root@78.47.174.83 "
  cd /tmp &&
  curl -fsSL -o hsm-new https://releases.experiencenet.com/hydrastreamingmonitor/production/${VERSION}/hydrastreamingmonitor-linux-amd64 &&
  curl -fsSL -o hsm-sums https://releases.experiencenet.com/hydrastreamingmonitor/production/${VERSION}/SHA256SUMS &&
  [ \"\$(sha256sum hsm-new | awk '{print \$1}')\" = \"\$(grep linux-amd64 hsm-sums | awk '{print \$1}')\" ] &&
  chmod +x hsm-new &&
  cp /usr/local/bin/hydrastreamingmonitor /usr/local/bin/hydrastreamingmonitor.backup &&
  mv hsm-new /usr/local/bin/hydrastreamingmonitor &&
  rm -f hsm-sums &&
  systemctl restart hydrastreamingmonitor
"

The checksum check ([ ... ] &&) aborts the whole chain before touching the installed binary if the download doesn't match SHA256SUMS — don't skip it. The previous binary is preserved at /usr/local/bin/hydrastreamingmonitor.backup for rollback (cp it back over hydrastreamingmonitor and restart).

Verifying the running version

ssh root@78.47.174.83 "/usr/local/bin/hydrastreamingmonitor version"

Or check the version badge in the top-right corner of any page on hydrastreamingmonitor.experiencenet.com.

Service management

| Action | Command | |--------|---------| | Status | ssh root@78.47.174.83 "systemctl status hydrastreamingmonitor" | | Logs | ssh root@78.47.174.83 "journalctl -u hydrastreamingmonitor -n 100 --no-pager" | | Restart (same binary) | ssh root@78.47.174.83 "systemctl restart hydrastreamingmonitor" | | Update now | see "Forcing an immediate update" above — no single command, does not pick up a new binary by itself |

Known gap: 6-hour deploy lag

All server-side hydra services use the same 6-hour auto-update poll. None of them have an immediate CI-triggered restart. This is consistent across hydraissue, hydrastreamingmonitor, and others. Issue #382 tracks adding a POST /api/v1/admin/update admin endpoint so CI can trigger an immediate update without SSH.