RunicGateway/runicgateway.com
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(deploy): correct the image size, and say what a missing rgcom runner does
All checks were successful
PR checks / checks (pull_request) Successful in 1m19s
Details

Browse Source 
The image measures 757 MB, not the ~600 MB the requirements table guessed. And
until the rgcom runner exists the deploy job simply queues, which is worth stating
in both the workflow and DEPLOY.md: build has already published the image by then,
so the manual pull works throughout and the queued job goes when the runner does.

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
claude
2026-08-25 16:57:25 -05:00
parent f2e59a2426
commit 1558111050
2 changed files with 9 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
.gitea/workflows/build-image.yml
View File

@@ -114,6 +114,10 @@ jobs:
runs-on: rgcom runs-on: rgcom
# Guard against a workflow_dispatch fired from a branch: only main is deployed. # Guard against a workflow_dispatch fired from a branch: only main is deployed.
if: github.ref == 'refs/heads/main' if: github.ref == 'refs/heads/main'
# Until a runner with this label exists, this job simply QUEUES. That is the
# intended behaviour and it breaks nothing: `build` has already published the
# image, so `docker compose pull && up -d` by hand is available the whole time,
# and the queued job runs the moment the runner registers.
steps: steps:
- name: Pull the fresh image and recreate the container - name: Pull the fresh image and recreate the container

6
DEPLOY.md
View File

@@ -39,7 +39,7 @@ Very little, and that is deliberate (`PLAN.md` §6).
|---|---| |---|---|
| **Runtime** | Docker, with Compose v2 (`docker compose`, not `docker-compose`) | | **Runtime** | Docker, with Compose v2 (`docker compose`, not `docker-compose`) |
| **CPU / RAM** | One core and 512 MB is comfortable. Every page but two is prerendered HTML | | **CPU / RAM** | One core and 512 MB is comfortable. Every page but two is prerendered HTML |
| **Disk** | ~600 MB for the image, plus a SQLite file that will not reach a megabyte | | **Disk** | ~750 MB for the image, plus a SQLite file that will not reach a megabyte |
| **Network out** | Only to pull the image. The running site makes no outbound request of any kind | | **Network out** | Only to pull the image. The running site makes no outbound request of any kind |
| **Network in** | One HTTP port, reached by your reverse proxy | | **Network in** | One HTTP port, reached by your reverse proxy |
| **Database** | None. No MariaDB, no Redis, no second service | | **Database** | None. No MariaDB, no Redis, no second service |
@@ -309,6 +309,10 @@ container. Without it the job starts in a container with no Docker socket and no
Make sure the user the runner runs as can talk to Docker (`docker ps` succeeds) and can read and Make sure the user the runner runs as can talk to Docker (`docker ps` succeeds) and can read and
write `/opt/runicgateway.com`. write `/opt/runicgateway.com`.
**Until that runner exists, the deploy job just queues**, and nothing is harmed: the image has
already been built and pushed by the time it would run, so the manual update below works throughout,
and the queued job goes as soon as the runner registers.
**To update by hand instead** — always available, and what you do if the runner is down: **To update by hand instead** — always available, and what you do if the runner is down:
```bash ```bash