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>
36 lines
1.2 KiB
YAML
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"
|