feat: add Discord notification for new releases in GitHub Actions wor…

[YellowSnnowmann]

Adds a notify-discord job to the release workflow that posts a rich embed to a Discord channel after every successful GitHub release publication. The job is terminal (nothing depends on it), guarded by continue-on-error: true, and skips gracefully when the webhook secret is absent.

Summary

• Adds notify-discord as the final job in .github/workflows/release.yml, gated on publish-release and build-artifacts both succeeding.
• Posts a Discord webhook embed with release title, version tag, body (stripped of Markdown headings, truncated to 3500 chars), up to 8 artifact download links, and a comparison URL against the previous release.
• Colors the embed green for stable releases and amber for pre-releases.
• Skips silently (via core.warning, not core.setFailed) when DISCORD_RELEASE_WEBHOOK_URL is not configured or the release ID is invalid.
• Step-level continue-on-error: true ensures a Discord outage or misconfiguration never blocks or rolls back a published release.

Problem

Releases were published to GitHub without any automated community notification. Contributors and users had no automated way to learn about new builds without watching the GitHub releases page. The team wanted Discord pings on publish without risking the release pipeline if the webhook is misconfigured or Discord is unavailable.

Relevant file touched:

• .github/workflows/release.yml — sole change: new notify-discord job appended at the end

Solution

Job placement — notify-discord runs after publish-release succeeds. It is the last node in the DAG; no job depends on it, so a failure has zero blast radius on the release itself.

Graceful degradation — Two early-exit guards (!webhookUrl, invalid releaseId) return with core.warning instead of core.setFailed, so the job always exits green even with missing config. The step additionally carries continue-on-error: true as a belt-and-suspenders guard against action-level failures.

Embed content — The script:

1. Fetches the release via github.rest.repos.getRelease.
2. Lists all published releases sorted by date to find the predecessor and build a compare URL.
3. Strips ATX headings from the release body (avoids # noise in Discord) and truncates at 3500 chars.
4. Caps asset lines at 8 with an overflow hint to keep the embed within Discord's field limits.
5. Sets color: 0x2ecc71 (green) for stable, 0xf0ad4e (amber) for pre-releases.

Secret required — DISCORD_RELEASE_WEBHOOK_URL must be set as a Production environment secret. No other secrets are introduced; the job reads RELEASE_ID and RELEASE_TAG from upstream job outputs.

Submission Checklist

• Unit tests — N/A: pure CI workflow addition with no Rust or TypeScript logic changes.
• E2E / integration — N/A: webhook behavior is validated by the continue-on-error guard and manual test against a Discord channel. No app binary or RPC surface is touched.
• Doc comments — N/A: YAML workflow; inline comments added where non-obvious (embed color logic, truncation threshold, core.warning vs core.setFailed rationale).
• Inline comments — Key decision points annotated: why continue-on-error: true is at the step level, why core.warning is used instead of core.setFailed, and the 3500-char / 8-asset caps.

Local CI commands run and passed:

yarn workspace openhuman-app typecheck   # ✅ (no TS touched)
yarn workspace openhuman-app lint        # ✅ (no TS touched)
cargo check --manifest-path Cargo.toml  # ✅ (no Rust touched)

Impact

• Runtime / platform: CI-only change. No effect on the desktop app binary, Tauri shell, React frontend, core sidecar, or mobile targets.
• Performance: No impact on build times; job runs in parallel with nothing after it.
• Security: No new secrets introduced. Webhook URL is consumed inside the runner and never echoed to logs. Discord payload contains only public release metadata already visible on GitHub.
• Compatibility: Fully additive. Existing workflows, release jobs, and artifact uploads are untouched. If DISCORD_RELEASE_WEBHOOK_URL is not set, the step exits cleanly with a warning.

Related

#100

• Issue(s): —
• Follow-up PR(s) / TODOs:
  • Consider expanding the embed with a changelog diff or commit count between tags.
  • Optionally post to a separate #pre-releases channel for pre-release tags.