J3vb/OwnCord
1
0
Fork 0
mirror of https://github.com/J3vb/OwnCord.git synced 2026-09-03 03:50:00 +03:00
Code Issues Packages Projects Releases Wiki Activity
Files
c0c8736674ccecf9e6594c3cebd34ee384095d34
OwnCord/.github/workflows/release.yml
T
J3vbandClaude c0c8736674 B1-7: community intake and automation authorization (RL-21 / L-15, RL-22 / L-16, RL-16 / R-09) (#1419) 
* ci(claude): constrain automation triggers and bound run cost (L-16)

The Claude Code workflow consumes a metered credential, and the repository
stated nothing about who may spend it or for how long. Whatever downstream
behaviour happens to hold, an invariant this repository depends on should be
asserted and tested here, not inherited from a pinned dependency that a routine
version bump can re-derive.

Three controls, in the one workflow that spends:

- **Authorization.** The job condition now requires the actor to be on an
  explicit maintainer allowlist as well as the trigger text to mention the bot.
  An allowlist rather than an association check: this repository has exactly one
  collaborator, the term is unambiguous to read and to review, and it matches
  the actor-term pattern `ci.yml` already uses to exclude Dependabot. Adding a
  login is a one-line edit, which is the honest cost.
- **Duration.** `timeout-minutes: 30`, in the band every other long-running job
  here uses. Without it the job inherits GitHub's 360-minute default — the wrong
  ceiling for metered work, and the only job in the repository that lacked one.
- **Fan-out.** A `concurrency` group keyed on the issue or pull request number
  with `cancel-in-progress: true`, so repeated triggers on one thread collapse
  into a single run instead of running in parallel. Exactly one of
  `github.event.issue.number` and `github.event.pull_request.number` is present
  per triggering event, so the key is stable across all four.

The `permissions:` block and the checkout are deliberately untouched. The
permissions are already minimal and the checkout takes no `ref:`, so it reads
the base branch rather than proposed code — both correct, and rewriting either
would be churn.

`scripts/check-workflow-guards.mjs` keeps all three from silently regressing.
Modelled on `scripts/check-doc-counts.mjs`: same `--selftest`-then-assert shape,
same dependency-free approach. It is text-level rather than YAML-parsed on
purpose — the root has no YAML parser, and adding a dependency to assert that a
file contains a `timeout-minutes` key would be a poor trade. That limit is
stated in the file: these are presence-and-shape checks, not semantics.

It runs from `CHECK_HYGIENE` in `scripts/run.mjs`, so it is reachable as
`npm run check:hygiene` locally and executes inside `Repository Hygiene`, which
is already a pinned required check on `dev`. No new CI job and no new pin — the
guard is blocking from the moment it lands.

`actionlint` cannot do this job. It validates expression syntax, action inputs
and runner labels; a job condition is valid input to it whatever the condition
admits, and it has no notion of cost at all. The two tools are complementary
and both now run.

Also corrects the record: `docs/plans/b1-repository-foundation-2026-08-25.md`
claimed impact was bounded by read-only content permissions. The workflow's own
token block is least-privilege, but that is not the only identity a run can
hold, so the claim was narrower than the truth and is now stated accurately.

And `docs/security.md` gains the private-coordination section that two planning
documents already cite it for. The citation pointed at a policy that was not
written down; it now says what stays private, that the rule covers the
repository's own automation and settings rather than only product code, and
that a commit message on a public repository is a disclosure channel.

Verified: both directions, per guard. `node scripts/check-workflow-guards.mjs`
exits 0 on the current tree and reports four guards present. Deleting the
`timeout-minutes` line makes it exit 1 naming that guard and the invariant to
restore; replacing the actor term with `true` makes it exit 1 naming that one;
restoring each returns exit 0. `--selftest` passes eight assertions covering
every guard's absence, a commented-out guard (which must not count), and the two
shapes that must not trip it — any positive timeout value, and any concurrency
key. `npm run check:hygiene` passes with prettier, shellcheck, actionlint and
both new steps running for real; actionlint accepts the edited workflow.

Not included: the workflow's `permissions:` block and checkout step, per above.
No change to the action version or its inputs. `ci.yml`, `release.yml` and
`load-baseline.yml` are outside this item — none is reachable the same way, and
each already carries per-job least-privilege permissions, and where relevant a
timeout and a concurrency group. `METERED` in the new script lists one workflow
because one workflow spends; a second entry is a one-line change when that
changes.

Refs RL-22, L-16

* feat(intake): structured bug form, and route ideas to Discussions (RL-21)

Both issue templates were Markdown with front matter, so nothing they collected
was structured, required, or validated. A reporter could submit the form
untouched. The Environment block was three bullets with `Windows 11` prefilled
as the OS — the single most common answer, pre-filled, on a project that ships
Windows and Linux builds and an ARM64 client.

And `feature_request.md` existed at all, which is the direct violation: BPR-100
says Issues is the bug tracker and Discussions hosts support, ideas and
community feedback. A feature-request template routes ideas into Issues by
construction.

Done:
- `bug_report.md` → `bug_report.yml`, a real issue form. Six fields are
  `validations: required` — what happened, steps to reproduce, component, OS,
  architecture, deployment mode — because those six are what turns a report into
  something reproducible. The rest are optional on purpose; a form that demands
  everything gets abandoned.
- `feature_request.md` deleted. Nothing in the tree referenced either template
  by filename, so this breaks no link, script, or workflow.
- `config.yml` gains three routed destinations and keeps `blank_issues_enabled:
  false` — which is what makes the routing hold, since a blank issue bypasses
  every form and every warning on one.

The new environment fields are drawn from what this project actually ships, not
from a generic template:
- **Architecture** x64 / ARM64, with the note that ARM64 is the Linux desktop
  client today and there is no ARM64 server release.
- **Deployment mode** covering the six paths `docs/deployment.md` documents —
  prebuilt binary on either OS, from source, Docker/Compose, systemd, Windows
  service.
- **TLS mode** matching `tls.mode`'s four values exactly, `off` quoted so YAML
  does not read it as boolean false.
- **Network topology** — direct, port forward, reverse proxy, Tailscale — because
  voice bugs in particular bifurcate hard on this, and the reverse-proxy path
  cannot carry the WebRTC UDP range at all.
- **Separate client and server versions.** They are obtained differently and can
  legitimately differ. The server field says where to look — admin panel or the
  startup banner — and explicitly tolerates "unknown", because the version is
  deliberately absent from the unauthenticated `/health` endpoint as
  anti-fingerprinting hardening, so a non-admin reporter genuinely cannot get it.
- **Client webview**, WebView2 or WebKitGTK. No "PWA" option: no PWA exists, B1
  excludes browser and PWA work, and BPR-092 forbids presenting unavailable
  behaviour as functional. The field is diagnostic today regardless — the desktop
  client renders through the OS webview, and that already drives real bug classes.

Every public template now carries the disclosure warning BPR-101 asks for, and
the security contact link is first in the chooser, above the Discussions links.

Four files, 189 insertions, 58 deletions.

Verified: both files parse as YAML, and the form was checked against the issue
form schema rather than only for parseability — 13 body elements, 12 unique ids
with no collisions, every non-markdown element carrying an id and a label, every
dropdown carrying options, and the markdown block carrying neither an id nor
validations (both of which GitHub rejects). `config.yml` has
`blank_issues_enabled: false` and four contact links each with exactly
name/url/about. `npm run check:hygiene` passes.

The gap that verification leaves, stated plainly: nothing in this repository
validates issue-form schema. Prettier confirms the YAML parses and actionlint
does not read `.github/ISSUE_TEMPLATE/` at all, so a file that is valid YAML but
an invalid form disappears from the "New issue" chooser silently. The checks
above are a local stand-in, not the real gate. The live chooser needs a look
after merge — which BPR-100's closure evidence ("dry-run submissions reach the
intended destination") requires in any case.

Not included: the Discussions `?category=` slugs are written as `q-a` and
`ideas`, GitHub's defaults. If this repository's categories were renamed, a
wrong slug drops the user on the category picker rather than erroring — confirm
against the live Discussions tab before relying on them. No PR-template or
documentation changes here; those are the next commit. L-15 is not closed by
this commit alone: BPR-100 names six surfaces and three of them are docs.

Refs RL-21, L-15

* docs(intake): route contributors, and state the security path (RL-21)

The previous commit fixed the forms. This is the half BPR-100 and BPR-102
actually ask for and the B1 plan's bullet does not mention: their closure
evidence names repository navigation, support links and contribution docs
alongside the issue forms, so a `.github/`-only change cannot satisfy either.

Three gaps, each verified rather than assumed:

**Discussions was invisible.** The only link to it anywhere in the tree was
inside `.github/ISSUE_TEMPLATE/config.yml` — the new-issue chooser. So "route
ideas and feedback to Discussions" worked for exactly one audience: people who
had already decided to file an issue. `README.md` and `docs/README.md` now each
carry the routing, so it is reachable from the two pages a newcomer actually
lands on.

**`docs/contributing.md` never mentioned security reporting.** Five files
carry the "never a public issue" rule — the root `README.md`, `CONTRIBUTING.md`,
`SECURITY.md`, `docs/security.md`, `CLAUDE.md` — and every one of them delegates
the full process to `docs/contributing.md`, which is also the document BPR-102's
evidence row sends a fresh contributor to. It said nothing about it. It now has
a routing table and a security section that says the thing that actually matters
on a public repository: the PR description, the commits and the branch name are
disclosure channels, so a fix for a vulnerability describes the control it adds
and nothing else.

**The README contradicted the issue chooser.** The banner said "there's no
support" while the chooser offered a link named "Community Support". Both were
defensible in isolation and together they told a user two different things
before they had read anything else. The banner now says the honest version — no
support *commitment* — and a "Getting Help and Reporting Problems" table names
the right destination for each kind of message without promising a response.

Also in the PR template, which the audit's remedy names as "PR guidance":
- The Test Plan asked for `npm test` / `go test ./...` / `npx tsc --noEmit`.
  Those predate B1-4's root facade; `npm run check` is the entry point CI gates
  on and the one `CONTRIBUTING.md` and `README.md` now tell people to run.
- A generated-files checkbox naming all five, since CI fails on drift and a
  hand-edited generated file is the failure that wastes a cycle.
- A `Not included:` prompt, because `docs/contributing.md` makes a written
  deferral a required commit element and the template asked for it nowhere.
- The disclosure warning BPR-101 wants on public templates.

Two stale claims fixed while in these files: `docs/contributing.md` said "ten
status checks are required" three lines from a section that says twelve, and
`docs/plans/README.md` still read "B1-0 done, B1-1 next" six phases later — in
the index that declares itself the authority over plan headers.

Five files, 70 insertions, 12 deletions.

Verified: `git grep "ten status checks"` returns nothing.
`node scripts/check-doc-counts.mjs` still agrees on 21 claims across 8 watched
documents — `docs/plans/README.md` and `README.md` are both watched, so a
count claim broken by these edits would have failed here.
`npm run check:hygiene` passes with prettier, shellcheck, actionlint and the
workflow-guard check all running.

One nearby claim checked and deliberately left: `docs/contributing.md` also says
"four of the ten" a hundred lines later. That is four of ten *CI steps keying on
a cache-dependency-path*, not required checks — correct in context, and changing
it would have been a wrong fix to a right-looking grep hit.

Not included: L-15 is **not** closed. BPR-100's closure evidence requires
dry-run submissions that reach the intended destination, and BPR-102's requires
a fresh Windows and Linux contributor to follow these docs and land a passing
sample change. Neither is a file edit. BPR-101 additionally wants a tabletop
report proving private receipt, triage, advisory and coordinated disclosure —
no such artifact exists in the tree, and this commit does not create one.
`CODE_OF_CONDUCT.md` and `GOVERNANCE.md` do not exist in this repository; adding
them is community-health scope, not RL-21's, and neither is named by the audit
row or the register row.

Refs RL-21, L-15

* ci(release): require exact-SHA gate evidence before publishing (RL-16)

A tag push starts `release.yml` and nothing else — `ci.yml` has no `tags:`
trigger. And `release.yml` re-runs none of the required checks: it verifies the
version, builds, boot-smokes and signs, which is a different question from
"did the gate pass on this commit". So a tag could publish from a commit whose
CI was red, and nothing would notice.

It already has. `v1.2.0-alpha.3` published from `fb04a579`, whose CI run
concluded **failure** — `Server Build & Test (windows-latest)`, the race and
coverage step. The Release run on the same commit went green and shipped. That
is R-09 demonstrated rather than hypothesised, and it is the fixture this commit
is verified against.

The obvious fix — re-run the test suite inside `release.yml` — is the wrong one.
It would double the tag-time cost, still not cover the checks that run in other
workflows (CodeQL's three `Analyze` jobs exist in no workflow file at all), and
answer a weaker question: "does it pass now" rather than "did the gate pass on
this commit". The evidence already exists; nothing was reading it.

Done:
- `scripts/verify-gate-evidence.mjs` resolves the tagged SHA's check runs and
  asserts every required context is present and `success`. `skipped` and
  `neutral` are not success — a required check that skipped on the tagged commit
  proves nothing about it — and a still-`in_progress` check is called out as
  unfinished rather than treated as absent. Where a context reported more than
  once, the latest attempt decides, in both directions.
- The required set is **parsed out of `b0-dev-branch-protection.sh`**, not
  restated. Pinning a thirteenth check cannot leave this gate behind, and a
  change to that file's shape fails the self-test rather than silently
  weakening the gate.
- A `gate-evidence` job in `release.yml` that `verify-versions` needs. Every
  build job already needs `verify-versions` and both publishers need those, so
  one edge gates the whole graph — including the GHCR push, which today can
  mutate `:latest` before `publish` has run at all.
- `permissions: checks: read` and nothing else.

It is a script rather than a `run:` block because of the rule in the `ci-check`
skill: a step that exists only in `release.yml` first executes at tag time, so
its own bugs surface on the release. `Server/scripts/docker-smoke.sh` is the
worked example — one script, two call sites. Here the second call site is
`--selftest`, run by `ci.yml`'s docs-consistency job on every pull request.

`docs/plans/b1-release-tag-protection.sh` covers the half a workflow file
cannot express: a ruleset on `refs/tags/v*` blocking update and deletion, and a
`release` environment with a required reviewer. **NOT APPLIED** — both are
repository-settings writes this session cannot make. Run
`bash docs/plans/b1-release-tag-protection.sh` when you want them.

Deliberately **no `environment: release` key** in `release.yml` yet. The key is
PR-landable, but naming an environment that does not exist stalls the next
release; the script says to add it after creating the environment, and says why.

Verified: both directions, on real data rather than only fixtures. Feeding the
actual check runs from `fb04a579` — the commit alpha.3 shipped from — through
`evaluate` returns **NOT RELEASABLE**, naming `Server Build & Test
(windows-latest): failure` first. Feeding PR #1418's real check runs on
`8875238` returns **RELEASABLE**, and correctly ignores the red
`github-advanced-security` result because it is not a pinned context — the gate
tracks the required set, not "everything is green". `--selftest` passes 12
assertions covering a missing check, a failure, an unfinished run, `skipped`,
`neutral`, both re-run orderings, an unrequired extra, and a commit with no
checks at all. `bash -n` and `shellcheck` are clean on the new script and both
its heredocs parse as JSON. `npm run check:hygiene` passes with actionlint over
both edited workflows.

The module gained a direct-invocation guard so it can be imported and tested
without reaching the network — compared against `argv[1]` rather than
`import.meta.main`, which needs Node 24.2 against an engines floor of `>=24`
and would silently no-op on 24.0.

Not included: the network path itself is exercised only at tag time. The
self-test covers the decision logic and the required-set parsing, which is where
the bugs live; a live API call needs a token this environment does not have.
R-09's "protected release approval" limb stays open until the settings script is
run — the register phases R-09 **B1/B10**, so that half is B10's. `release.yml`'s
version stamping, both signing keys, the fail-closed minisign verify,
`checksums.sha256`'s bare filenames, both cold-boot smokes and the `git archive`
source snapshot are untouched; the remedy says to retain them and this commit
only adds an edge in front of them.

Refs RL-16, R-09

* docs(plans): record B1 progress through B1-7

B1-6 (#1418) merged and B1-7 is this branch, so the header and the plan index
both move on. B1-8 — the platform contract map — is next, and it is documentation
only: it records the browser-neutral contract folders and their owners, and moves
no native behaviour. Adapter extraction stays B7.

Verified: `node scripts/check-doc-counts.mjs` still agrees on 21 claims across 8
watched documents, both edited files among them; prettier clean.

Refs R-08

---------

Co-authored-by: Claude <noreply@anthropic.com>
2026-08-27 17:25:22 +00:00

625 lines
25 KiB
YAML
Raw Blame History

name: Release
on:
push:
tags:
- "v*"
# A deleted-and-re-pushed tag (it has happened — see the checksum note in the
# publish job) must not race two publish runs: `gh release create` fails
# loudly on the second run, but the ghcr :latest push does not, and which run
# wins it would be arbitrary. Queue, never cancel — a half-cancelled release
# is worse than a slow one.
concurrency:
group: release-${{ github.ref_name }}
cancel-in-progress: false
jobs:
# R-09 / RL-16. ci.yml has no `tags:` trigger, so a tag push starts this
# workflow and nothing else — and this workflow re-runs none of the required
# checks. It builds, smokes and signs, which is a different question from
# "did the gate pass on this commit".
#
# It did not, at least once: v1.2.0-alpha.3 published from a commit whose
# `Server Build & Test (windows-latest)` had concluded failure. Nothing
# noticed, because nothing looked.
#
# The required set is read out of b0-dev-branch-protection.sh rather than
# restated here, so pinning a new check cannot leave this gate behind. The
# logic lives in a script with a --selftest that ci.yml runs on every PR:
# a step that exists only in this file first executes at tag time, which is
# the wrong place to discover its bugs.
gate-evidence:
name: Verify exact-SHA gate evidence
runs-on: ubuntu-latest
permissions:
contents: read
checks: read
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
- uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
with:
node-version: 24
- name: Required checks must be green on the tagged commit
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
GITHUB_REPOSITORY: ${{ github.repository }}
run: node scripts/verify-gate-evidence.mjs "${{ github.sha }}"
# The v1.1.0-alpha.4 release shipped clients still versioned 1.1.0-alpha.3
# because the client manifests weren't bumped before tagging — deployed
# clients then never saw the update. Fail fast on that mismatch, before any
# expensive build starts.
verify-versions:
name: Verify client version matches tag
# Every build job needs verify-versions, and both publishers need those, so
# one edge here gates the whole graph — nothing builds, pushes to GHCR, or
# creates a Release on a commit that did not pass.
needs: gate-evidence
runs-on: ubuntu-latest
permissions:
contents: read
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
- name: Compare tag with client manifests
shell: bash
run: |
TAG_VERSION="${GITHUB_REF_NAME#v}"
TAURI_VERSION=$(node -p "require('./Client/src-tauri/tauri.conf.json').version")
NPM_VERSION=$(node -p "require('./Client/package.json').version")
CARGO_VERSION=$(sed -n 's/^version = "\(.*\)"$/\1/p' Client/src-tauri/Cargo.toml | head -1)
fail=0
for pair in "tauri.conf.json:$TAURI_VERSION" "package.json:$NPM_VERSION" "Cargo.toml:$CARGO_VERSION"; do
file="${pair%%:*}"; ver="${pair#*:}"
if [ "$ver" != "$TAG_VERSION" ]; then
echo "::error::Release tag v$TAG_VERSION does not match client version $ver in $file — bump the client version before tagging."
fail=1
fi
done
exit $fail
release-client-windows:
name: Build Tauri (Windows)
needs: verify-versions
runs-on: windows-latest
permissions:
contents: read
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
- uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
with:
node-version: 24
cache: npm
cache-dependency-path: Client/package-lock.json
- name: Install Rust
uses: dtolnay/rust-toolchain@29eef336d9b2848a0b548edc03f92a220660cdb8 # stable
- name: Rust cache
uses: swatinem/rust-cache@6323deb102c322ba6fcbdcafc7e3dddab59af2b6 # v2.9.2
with:
workspaces: Client/src-tauri
- name: Install npm dependencies
working-directory: Client
run: npm ci
- name: Build Tauri app
working-directory: Client
env:
TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
TAURI_SIGNING_PRIVATE_KEY_PASSWORD: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY_PASSWORD }}
run: npm run tauri build
- name: Stage Windows release assets
shell: bash
run: |
mkdir -p release-staging
NSIS_DIR="Client/src-tauri/target/release/bundle/nsis"
INSTALLER=$(find "$NSIS_DIR" -name "*.exe" | head -1)
cp "$INSTALLER" release-staging/
NSIS_ZIP=$(find "$NSIS_DIR" -name "*_x64-setup.nsis.zip" ! -name "*.sig" | head -1)
if [ -n "$NSIS_ZIP" ] && [ -f "$NSIS_ZIP" ]; then cp "$NSIS_ZIP" release-staging/; fi
NSIS_SIG=$(find "$NSIS_DIR" -name "*_x64-setup.nsis.zip.sig" | head -1)
if [ -n "$NSIS_SIG" ] && [ -f "$NSIS_SIG" ]; then cp "$NSIS_SIG" release-staging/; fi
- name: Upload Windows release assets
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
with:
name: windows-release-assets
path: release-staging/
release-client-linux:
name: Build Tauri (Linux)
needs: verify-versions
runs-on: ubuntu-22.04
permissions:
contents: read
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
- uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
with:
node-version: 24
cache: npm
cache-dependency-path: Client/package-lock.json
- name: Install Linux system dependencies
run: |
sudo apt-get update
sudo apt-get install -y \
libwebkit2gtk-4.1-dev \
libgtk-3-dev \
libayatana-appindicator3-dev \
libsecret-1-dev \
libdbus-1-dev \
libasound2-dev \
libssl-dev \
patchelf \
librsvg2-dev \
xdg-utils
- name: Install Rust
uses: dtolnay/rust-toolchain@29eef336d9b2848a0b548edc03f92a220660cdb8 # stable
- name: Rust cache
uses: swatinem/rust-cache@6323deb102c322ba6fcbdcafc7e3dddab59af2b6 # v2.9.2
with:
workspaces: Client/src-tauri
- name: Install npm dependencies
working-directory: Client
run: npm ci
- name: Build Tauri app (AppImage + deb)
working-directory: Client
env:
TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
TAURI_SIGNING_PRIVATE_KEY_PASSWORD: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY_PASSWORD }}
run: npm run tauri build -- --bundles appimage,deb
# linuxdeploy bundles the runner's libwayland-* into the AppImage, which
# breaks Mesa EGL init on newer hosts (white window on Arch/Fedora —
# EGL_BAD_PARAMETER). Strip them and regenerate the updater artifact +
# signatures for the patched image.
- name: Strip host-incompatible libs from AppImage and re-sign
working-directory: Client
shell: bash
env:
TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
TAURI_SIGNING_PRIVATE_KEY_PASSWORD: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY_PASSWORD }}
run: |
BUNDLE_DIR="src-tauri/target/release/bundle/appimage"
APPIMAGE=$(find "$BUNDLE_DIR" -name "*.AppImage" ! -name "*.sig" | head -1)
bash scripts/strip-appimage-bundled-libs.sh "$APPIMAGE"
TARBALL="$APPIMAGE.tar.gz"
rm -f "$TARBALL" "$APPIMAGE.sig" "$TARBALL.sig"
tar czf "$TARBALL" -C "$(dirname "$APPIMAGE")" "$(basename "$APPIMAGE")"
# Sign straight from the environment. TAURI_SIGNING_PRIVATE_KEY is
# the env form of --private-key, so ALSO passing -f/--private-key-path
# makes the CLI abort: "the argument '--private-key-path' cannot be
# used with '--private-key'". Keeping the key in the env instead of a
# temp file also keeps it off the runner's disk.
npx tauri signer sign -p "$TAURI_SIGNING_PRIVATE_KEY_PASSWORD" "$APPIMAGE"
npx tauri signer sign -p "$TAURI_SIGNING_PRIVATE_KEY_PASSWORD" "$TARBALL"
- name: Stage Linux release assets
shell: bash
run: |
mkdir -p linux-staging
BUNDLE_DIR="Client/src-tauri/target/release/bundle"
# AppImage
APPIMAGE=$(find "$BUNDLE_DIR/appimage" -name "*.AppImage" ! -name "*.sig" | head -1)
if [ -n "$APPIMAGE" ] && [ -f "$APPIMAGE" ]; then cp "$APPIMAGE" linux-staging/; fi
APPIMAGE_SIG=$(find "$BUNDLE_DIR/appimage" -name "*.AppImage.sig" | head -1)
if [ -n "$APPIMAGE_SIG" ] && [ -f "$APPIMAGE_SIG" ]; then cp "$APPIMAGE_SIG" linux-staging/; fi
APPIMAGE_TAR=$(find "$BUNDLE_DIR/appimage" -name "*.AppImage.tar.gz" ! -name "*.sig" | head -1)
if [ -n "$APPIMAGE_TAR" ] && [ -f "$APPIMAGE_TAR" ]; then cp "$APPIMAGE_TAR" linux-staging/; fi
APPIMAGE_TAR_SIG=$(find "$BUNDLE_DIR/appimage" -name "*.AppImage.tar.gz.sig" | head -1)
if [ -n "$APPIMAGE_TAR_SIG" ] && [ -f "$APPIMAGE_TAR_SIG" ]; then cp "$APPIMAGE_TAR_SIG" linux-staging/; fi
# .deb
DEB=$(find "$BUNDLE_DIR/deb" -name "*.deb" | head -1)
if [ -n "$DEB" ] && [ -f "$DEB" ]; then cp "$DEB" linux-staging/; fi
- name: Upload Linux release assets
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
with:
name: linux-release-assets
path: linux-staging/
release-server:
name: Build server (${{ matrix.os }})
needs: verify-versions
strategy:
fail-fast: false
matrix:
include:
- os: windows-latest
artifact: server-windows
- os: ubuntu-latest
artifact: server-linux
runs-on: ${{ matrix.os }}
permissions:
contents: read
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
- uses: actions/setup-go@40f1582b2485089dde7abd97c1529aa768e1baff # v5.6.0
with:
go-version: "1.26"
- name: Extract version from tag
shell: bash
run: |
VERSION="${GITHUB_REF_NAME#v}"
echo "VERSION=$VERSION" >> "$GITHUB_ENV"
- name: Build server (Windows)
if: matrix.os == 'windows-latest'
shell: bash
run: cd Server && go build -o chatserver.exe -ldflags "-s -w -X main.version=$VERSION" .
- name: Build server (Linux)
if: matrix.os == 'ubuntu-latest'
working-directory: Server
env:
CGO_ENABLED: "0"
run: go build -o chatserver -ldflags "-s -w -X main.version=$VERSION" .
# Boot-smoke the EXACT artifact that ships: this feed drives the signed
# self-update, so a binary that compiles but dies on boot would deploy
# itself to every auto-updating instance. CI's tests exercise the same
# commit but never this build (release ldflags, CGO_ENABLED=0) and never
# execute the produced binary. First run writes config.yaml, generates a
# self-signed cert, migrates a fresh SQLite DB — a real cold boot.
- name: Boot-smoke server binary
shell: bash
working-directory: Server
run: |
SMOKE_DIR="$RUNNER_TEMP/owncord-smoke"
mkdir -p "$SMOKE_DIR"
cd "$SMOKE_DIR"
BIN="$GITHUB_WORKSPACE/Server/chatserver"
[ -f "$GITHUB_WORKSPACE/Server/chatserver.exe" ] && BIN="$GITHUB_WORKSPACE/Server/chatserver.exe"
"$BIN" &
SERVER_PID=$!
ok=0
for _ in $(seq 1 30); do
sleep 1
if ! kill -0 "$SERVER_PID" 2>/dev/null; then
echo "::error::server process exited during boot smoke"
exit 1
fi
if "$BIN" healthcheck; then ok=1; break; fi
done
kill "$SERVER_PID" 2>/dev/null || true
wait "$SERVER_PID" 2>/dev/null || true
if [ "$ok" != "1" ]; then
echo "::error::server never reported healthy within 30s"
exit 1
fi
echo "boot smoke passed"
- name: Create tar.gz (Linux)
if: matrix.os == 'ubuntu-latest'
working-directory: Server
run: tar czf ../chatserver-linux-amd64.tar.gz chatserver
- name: Upload Windows binary
if: matrix.os == 'windows-latest'
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
with:
name: ${{ matrix.artifact }}
path: Server/chatserver.exe
- name: Upload Linux archive
if: matrix.os == 'ubuntu-latest'
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
with:
name: ${{ matrix.artifact }}
path: chatserver-linux-amd64.tar.gz
release-client-linux-arm64:
name: Build Tauri (Linux ARM64)
needs: verify-versions
runs-on: ubuntu-22.04-arm
permissions:
contents: read
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
- uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
with:
node-version: 24
cache: npm
cache-dependency-path: Client/package-lock.json
- name: Install Linux system dependencies
run: |
sudo apt-get update
sudo apt-get install -y \
libwebkit2gtk-4.1-dev \
libgtk-3-dev \
libayatana-appindicator3-dev \
libsecret-1-dev \
libdbus-1-dev \
libasound2-dev \
libssl-dev \
patchelf \
librsvg2-dev \
xdg-utils
- name: Install Rust
uses: dtolnay/rust-toolchain@29eef336d9b2848a0b548edc03f92a220660cdb8 # stable
- name: Rust cache
uses: swatinem/rust-cache@6323deb102c322ba6fcbdcafc7e3dddab59af2b6 # v2.9.2
with:
workspaces: Client/src-tauri
- name: Install npm dependencies
working-directory: Client
run: npm ci
- name: Build Tauri app (AppImage + deb)
working-directory: Client
env:
TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
TAURI_SIGNING_PRIVATE_KEY_PASSWORD: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY_PASSWORD }}
run: npm run tauri build -- --bundles appimage,deb
# Same strip + re-sign as the x86_64 job — see the comment there.
- name: Strip host-incompatible libs from AppImage and re-sign
working-directory: Client
shell: bash
env:
TAURI_SIGNING_PRIVATE_KEY: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY }}
TAURI_SIGNING_PRIVATE_KEY_PASSWORD: ${{ secrets.TAURI_SIGNING_PRIVATE_KEY_PASSWORD }}
run: |
BUNDLE_DIR="src-tauri/target/release/bundle/appimage"
APPIMAGE=$(find "$BUNDLE_DIR" -name "*.AppImage" ! -name "*.sig" | head -1)
bash scripts/strip-appimage-bundled-libs.sh "$APPIMAGE"
TARBALL="$APPIMAGE.tar.gz"
rm -f "$TARBALL" "$APPIMAGE.sig" "$TARBALL.sig"
tar czf "$TARBALL" -C "$(dirname "$APPIMAGE")" "$(basename "$APPIMAGE")"
# Sign straight from the environment. TAURI_SIGNING_PRIVATE_KEY is
# the env form of --private-key, so ALSO passing -f/--private-key-path
# makes the CLI abort: "the argument '--private-key-path' cannot be
# used with '--private-key'". Keeping the key in the env instead of a
# temp file also keeps it off the runner's disk.
npx tauri signer sign -p "$TAURI_SIGNING_PRIVATE_KEY_PASSWORD" "$APPIMAGE"
npx tauri signer sign -p "$TAURI_SIGNING_PRIVATE_KEY_PASSWORD" "$TARBALL"
- name: Stage Linux ARM64 release assets
shell: bash
run: |
mkdir -p linux-arm64-staging
BUNDLE_DIR="Client/src-tauri/target/release/bundle"
# AppImage + updater artifact (.tar.gz) + signatures. Every filename
# must carry the arch: FindClientAssets matches on the
# _aarch64.AppImage.tar.gz suffix, and arch-less names would collide
# with the x86_64 assets when both artifact sets are downloaded into
# the same linux/ directory at publish time. Inserting _aarch64
# before ".AppImage" renames installer, tar.gz, and .sig
# consistently, so signatures keep pairing with their artifacts.
for f in "$BUNDLE_DIR"/appimage/*.AppImage "$BUNDLE_DIR"/appimage/*.AppImage.tar.gz "$BUNDLE_DIR"/appimage/*.sig; do
[ -f "$f" ] || continue
base="$(basename "$f")"
[[ "$base" == *aarch64* ]] || base="${base/.AppImage/_aarch64.AppImage}"
cp "$f" "linux-arm64-staging/$base"
done
# .deb
for f in "$BUNDLE_DIR"/deb/*.deb; do
[ -f "$f" ] && cp "$f" linux-arm64-staging/
done
- name: Upload Linux ARM64 release assets
uses: actions/upload-artifact@ea165f8d65b6e75b540449e92b4886f43607fa02 # v4.6.2
with:
name: linux-arm64-release-assets
path: linux-arm64-staging/
release-server-docker:
name: Build & Push Server Docker Image
needs: verify-versions
runs-on: ubuntu-latest
permissions:
contents: read
packages: write
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
- name: Extract version from tag
shell: bash
run: |
VERSION="${GITHUB_REF_NAME#v}"
echo "VERSION=$VERSION" >> "$GITHUB_ENV"
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@8d2750c68a42422c14e847fe6c8ac0403b4cbd6f # v3.12.0
- name: Log in to GitHub Container Registry
uses: docker/login-action@c94ce9fb468520275223c153574b00df6fe4bcc9 # v3.7.0
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Extract Docker metadata
id: meta
uses: docker/metadata-action@c299e40c65443455700f0fdfc63efafe5b349051 # v5.10.0
with:
images: ghcr.io/${{ github.repository_owner }}/owncord-server
tags: |
type=semver,pattern={{version}}
type=semver,pattern={{major}}.{{minor}}
type=raw,value=latest
# Build locally first so the image can be boot-smoked BEFORE anything
# is pushed — a pushed :latest that dies on boot deploys itself to every
# `docker compose pull` upgrade.
- name: Build image (local, for smoke test)
uses: docker/build-push-action@10e90e3645eae34f1e60eeb005ba3a3d33f178e8 # v6.19.2
with:
context: Server/
load: true
build-args: VERSION=${{ env.VERSION }}
tags: owncord-smoke:candidate
cache-from: type=gha
cache-to: type=gha,mode=max
# Shared with ci.yml's docker-build job so the smoke itself is exercised
# on every PR to main — the first alpha.3 release run died here on a
# smoke-harness bug (bare `docker run`, nowhere writable for the
# default config) that no pre-merge check had ever run.
- name: Boot-smoke Docker image
run: bash Server/scripts/docker-smoke.sh owncord-smoke:candidate
- name: Build and push
uses: docker/build-push-action@10e90e3645eae34f1e60eeb005ba3a3d33f178e8 # v6.19.2
with:
context: Server/
push: true
build-args: VERSION=${{ env.VERSION }}
tags: ${{ steps.meta.outputs.tags }}
labels: ${{ steps.meta.outputs.labels }}
cache-from: type=gha
cache-to: type=gha,mode=max
publish:
name: Publish GitHub Release
needs:
[
release-client-windows,
release-client-linux,
release-client-linux-arm64,
release-server,
release-server-docker,
]
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
- uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
with:
node-version: 24
cache: npm
cache-dependency-path: Client/package-lock.json
- name: Download Windows client assets
uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
with:
name: windows-release-assets
path: windows
- name: Download Linux x86_64 client assets
uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
with:
name: linux-release-assets
path: linux
- name: Download Linux ARM64 client assets
uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
with:
name: linux-arm64-release-assets
path: linux
- name: Download Windows server binary
uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
with:
name: server-windows
path: windows
- name: Download Linux server archive
uses: actions/download-artifact@d3f86a106a0bac45b974a628896c90dbdf5c8093 # v4.3.0
with:
name: server-linux
path: linux
- name: Extract version from tag
shell: bash
run: |
VERSION="${GITHUB_REF_NAME#v}"
echo "VERSION=$VERSION" >> "$GITHUB_ENV"
- name: Create source snapshot (AGPL source availability)
shell: bash
run: |
git archive --format=tar.gz --prefix="OwnCord-${VERSION}/" \
-o "owncord-src-${{ github.ref_name }}.tar.gz" HEAD
# Checksum lines must use bare asset filenames: the v1.0.0 updater's
# ParseChecksumFile does an exact match on the last field, so a
# "windows/" prefix would strand every deployed server on 1.0.0.
- name: Generate SHA256 checksums
shell: bash
run: |
(cd windows && sha256sum -- *) > checksums.sha256
(cd linux && sha256sum -- *) >> checksums.sha256
sha256sum owncord-src-*.tar.gz >> checksums.sha256
# The legacy top-level asset/sha256 pair stays bound to the Windows
# binary so already-deployed servers (which only understand the
# single-asset schema) can still verify and update; the assets list
# binds every OS. Server-side schema: updater.releaseManifest.
- name: Generate server update manifest
shell: bash
run: |
WIN_HASH=$(sha256sum windows/chatserver.exe | awk '{print $1}')
LINUX_HASH=$(sha256sum linux/chatserver-linux-amd64.tar.gz | awk '{print $1}')
printf '{"version":"v%s","asset":"chatserver.exe","sha256":"%s","assets":[{"asset":"chatserver.exe","sha256":"%s"},{"asset":"chatserver-linux-amd64.tar.gz","sha256":"%s"}]}' \
"$VERSION" "$WIN_HASH" "$WIN_HASH" "$LINUX_HASH" > windows/server-update-manifest.json
- name: Sign server update assets
working-directory: Client
shell: bash
env:
SERVER_UPDATE_SIGNING_PRIVATE_KEY: ${{ secrets.SERVER_UPDATE_SIGNING_PRIVATE_KEY }}
SERVER_UPDATE_SIGNING_PRIVATE_KEY_PASSWORD: ${{ secrets.SERVER_UPDATE_SIGNING_PRIVATE_KEY_PASSWORD }}
run: |
KEY_PATH=$(mktemp)
printf '%s' "$SERVER_UPDATE_SIGNING_PRIVATE_KEY" > "$KEY_PATH"
trap 'rm -f "$KEY_PATH"' EXIT
npm ci
npx tauri signer sign -f "$KEY_PATH" -p "$SERVER_UPDATE_SIGNING_PRIVATE_KEY_PASSWORD" ../windows/chatserver.exe
npx tauri signer sign -f "$KEY_PATH" -p "$SERVER_UPDATE_SIGNING_PRIVATE_KEY_PASSWORD" ../windows/server-update-manifest.json
# Fail closed before publishing: prove the freshly signed assets verify
# against the pinned public key that ships inside the server binary.
# Catches key/pubkey mismatch, signature format drift, and signer flag
# regressions — each of which has silently broken this pipeline before.
- name: Verify signed assets against pinned server update key
shell: bash
run: |
sudo apt-get update && sudo apt-get install -y minisign
base64 -d Server/updater/server_update_public_key.txt > "$RUNNER_TEMP/server_update.pub"
for f in windows/chatserver.exe windows/server-update-manifest.json; do
base64 -d "$f.sig" > "$RUNNER_TEMP/asset.minisig"
minisign -Vm "$f" -x "$RUNNER_TEMP/asset.minisig" -p "$RUNNER_TEMP/server_update.pub"
done
- name: Install root dependencies (changelogen)
run: npm ci
- name: Generate changelog
shell: bash
run: npx changelogen --output CHANGELOG.md
# Sole publish target. This repo is public, so its own Releases page both
# satisfies AGPL source availability (via the owncord-src snapshot below)
# and serves as the publicly-readable feed that deployed servers and
# clients poll for updates. The former mirror step to a separate public
# releases repo existed only to work around this repo being private.
- name: Create GitHub Release
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
mapfile -t assets < <(find windows linux -type f)
assets+=(checksums.sha256 owncord-src-*.tar.gz)
gh release create "${{ github.ref_name }}" \
--notes-file CHANGELOG.md \
"${assets[@]}"
Reference in New Issue View Git Blame Copy Permalink