Docs: both hosts deploy from CI; the site table reads v0.5.2
Test / test (push) Failing after 1m7s

This commit is contained in:
Bendik Aagaard Lynghaug
2026-09-28 18:26:31 +02:00
parent 45240b7cab
commit f0c43c5c0f
2 changed files with 33 additions and 7 deletions
+7 -7
View File
@@ -349,13 +349,13 @@ content repos pin the tag they run (see the end of this file).
## What each site runs
Read from the hosts on 2026-09-28; a rollout is a pin bump in the
site's content repo (`PORTAL_RELEASE` in its `deploy.yml`), or a manual
tarball deploy on kasse.
site's content repo (`PORTAL_RELEASE` in its `deploy.yml`) - on both
hosts now, since kasse's runner deploys its own instances.
| Site | Host | Instance | Version |
|---|---|---|---|
| uhhm.no | ergo | `app@uhhm-portal` | v0.4.0 |
| redoal.com | ergo | `app@redoal-portal` | v0.4.0 |
| westra.klingenbergbygg.no | kasse | `app@westra-portal` | v0.4.0 |
| portal.klingenbergbygg.no | kasse | `app@klingenberg-portal` | v0.4.0 |
| vel.klingenbergbygg.no | kasse | `app@tomtervel-portal` | v0.4.0 |
| uhhm.no | ergo | `app@uhhm-portal` | v0.5.2 |
| redoal.com | ergo | `app@redoal-portal` | v0.5.2 |
| westra.klingenbergbygg.no | kasse | `app@westra-portal` | v0.5.2 |
| portal.klingenbergbygg.no | kasse | `app@klingenberg-portal` | v0.5.2 |
| vel.klingenbergbygg.no | kasse | `app@tomtervel-portal` | v0.5.2 |
+26
View File
@@ -124,3 +124,29 @@ garage bucket allow --read --write <site>-attachments --key <site>-portal-upload
then `GARAGE_S3_ENDPOINT`, `GARAGE_ACCESS_KEY`, `GARAGE_SECRET_KEY` and
`GARAGE_UPLOADS_BUCKET` in that instance's env. Unset, an upload field
fails closed rather than appearing to work and storing nowhere.
## Who deploys what
Both hosts deploy from CI now, and a rollout is the same commit either
way: bump `PORTAL_RELEASE` in the site's own content repo.
| | runner | how it is allowed to |
|---|---|---|
| ergo | `runs-on: bare` | the runner is privileged and writes `/srv/app` and `/etc/app` itself |
| kasse | `runs-on: fish` | the runner is not privileged. It may run one root script, `/usr/local/bin/deploy-portal-instance`, which checks the instance against a fixed list and the tag against a release-tag shape before touching anything |
The kasse grant is a single sudoers line
(`/etc/sudoers.d/30-portal-deploy`). It exists so a workflow can pick
which of three known instances gets which published portal tag, and
nothing else.
Both paths health-check the instance 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, which is how
v0.5.1 reached a host.
`IRIS_RELEASE` in a repo's lint workflow should equal its
`PORTAL_RELEASE`. Bump it only once iris's own publish job has attached
the binary for that tag - portal's release tags iris, but iris builds
and uploads on its own run, and a pin bumped in between fails the lint
on a download that is not there yet.