christian/waters-boards
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

Deploy from a dedicated runner on Chronicles-AB
Deploy Waters Boards to AWS / deploy (push) Failing after 2m6s
Details

Browse Source 
The workflow now runs on the aws-deploy label: an act_runner container on the
Gitea NAS, registered for this repo only. The checklist app's nas runner on
Chronicles-NA is no longer involved.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
michael
2026-10-15 10:59:01 -04:00
co-authored by Claude Fable 5.1
parent aad1f40948
commit ecfb26d40a
2 changed files with 19 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+8 -4
View File
@@ -127,8 +127,10 @@ healthcheck, and prints what `https://boards.watersmedia.org/healthz` returns. S
to deploy to a host other than `boards-aws`.
**Deploy from Gitea Actions.** The Gitea server is only reachable from inside the church network,
so AWS can't pull from it. Instead the `nas` runner, which is inside the network and can reach
the internet, runs the same `deploy.sh` and pushes to the box over SSH. The workflow
so AWS can't pull from it. Instead a runner inside the network runs the same `deploy.sh` and
pushes to the box over SSH. That runner is a container on Chronicles-AB (the NAS that hosts
Gitea), in `/volume2/docker/gitea-runner-boards`, registered for this repo only with the label
`aws-deploy`. The checklist app's `nas` runner on Chronicles-NA is separate and untouched. The workflow
(`.gitea/workflows/deploy.yml`) runs on every push to `main` that touches `server/` or
`deploy/aws/`, or by hand from the Gitea Actions tab. One-time setup:
@@ -140,8 +142,10 @@ the internet, runs the same `deploy.sh` and pushes to the box over SSH. The work
3. In **Settings → Actions → Variables**, add `DEPLOY_HOST` (the static IP) and
`DEPLOY_ENABLED` = `true`. Until `DEPLOY_ENABLED` is `true`, the deploy job is skipped, so
pushes made before the box was ready don't show as failures.
4. The `nas` runner must be registered where it can see this repo (user- or instance-level, not
only on the checklist repo).
4. If the runner ever needs rebuilding: on Chronicles-AB, `start-runner.sh` in that folder
recreates the container. To register it afresh, delete `.runner` there, put a new token in
`runner.env` (`docker exec -u git gitea gitea actions generate-runner-token --scope
christian/waters-boards` on that NAS), and run the script again.
**What a deploy never touches:** `data/` and `.env`. It deletes nothing on the box. It rebuilds
without taking the running container down first, so a failed build leaves the old version