Files
questions/.gitea/workflows/deploy.yml
T
blandClaude Opus 5 d1e375177f Deploy this instance from CI
Kasse's runner can now ship a portal release here, the way the ergo
sites already do: PORTAL_RELEASE is the pin, and bumping it is the
rollout. No more ssh and a script run by hand across all three
instances at once.

The runner is not root. It may run one script, which checks the
instance against a fixed list and the tag against a release-tag shape
before it touches anything, and then health-checks the site without a
forwarded header - so a check cannot pass while the site is broken for
everything that is not Caddy, which is how v0.5.1 got out.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-28 18:24:13 +02:00

36 lines
1.2 KiB
YAML

name: Deploy instance
# This content repo owns its portal instance: which portal version runs
# on kasse. uhhm/portal only publishes versioned release artifacts;
# PORTAL_RELEASE below pins the one this site runs, so every rollout is
# a commit - auditable, and revertable by reverting it.
#
# Content-only changes never come through here: lint-and-reload
# hot-swaps those into the running instance over NATS.
#
# Runs on the host runner, because a deploy has to touch this host's
# filesystem and its units. It is allowed exactly one root action:
# /usr/local/bin/deploy-portal-instance, which checks the instance
# against a fixed list and the tag against a release-tag shape before
# it touches anything, and health-checks the site afterwards without a
# forwarded header - a check that sends the header Caddy would send
# cannot tell you the site is broken for everything that is not Caddy.
on:
workflow_dispatch:
push:
branches: [main]
paths:
- .gitea/workflows/deploy.yml
env:
PORTAL_RELEASE: v0.5.2
INSTANCE: tomtervel-portal
jobs:
deploy:
runs-on: fish
steps:
- name: Ship the pinned release and restart
run: sudo /usr/local/bin/deploy-portal-instance "$INSTANCE" "$PORTAL_RELEASE"