adding the gitea runners and making it not possible for anyone to join the gitea

This commit is contained in:
itsamejms
2026-08-26 21:02:51 +01:00
parent e20d31955c
commit 8fc079880b
4 changed files with 110 additions and 3 deletions
+68 -1
View File
@@ -111,4 +111,71 @@ restore the DB backup that matches the version you’re rolling back to.
- The Mermaid size cap (`GITEA__markup__MERMAID_MAX_SOURCE_CHARACTERS=50000`) and the
Jupyter renderer env vars carry forward unchanged across versions.
- Major Gitea versions occasionally change bundled git requirements; the official
image ships its own git, so host git version is irrelevant here.
image ships its own git, so host git version is irrelevant here.
### Actions runner, CORS & OAuth (for the ever-near site)
The `ever-near` site uses Sveltia CMS backed by this Gitea instance. That needs three
things Gitea didn't have before: **Actions** (to build + deploy on push), **CORS**
(so the CMS in the browser can call the Gitea API), and an **OAuth2 app** (so editors
sign in with PKCE instead of a personal token). `docker-compose.yml` now enables the
first two via env vars and adds a `runner` service behind a `runner` profile.
**1. Ship the updated compose file and runner config to the VPS:**
```bash
scp docker-compose.yml runner_config.yaml ubuntu@vps-123c23bd.vps.ovh.net:~/gitea/
```
**2. Rebuild the server.** The compose network is now pinned to the literal name `gitea`
(so job containers can join it — see `runner_config.yaml`), which is a one-time network
change, so do a clean `down`/`up` (~10s downtime; Caddy restarts too):
```bash
cd ~/gitea
sudo docker compose down
sudo docker compose up -d --build
sudo docker compose logs -f server # watch for actions/cors config lines on boot
```
**3. Enable Actions on the repo** (one-off, in the web UI):
`gitea.jms.rocks/jameshtwose/ever-near` → Settings → Actions → Enable Actions.
**4. Get a runner registration token** (pick one):
- Web UI: Site Administration → Actions → Runners → copy the **Registration token**.
- Or CLI: `sudo docker exec gitea_server gitea --config /data/gitea/conf/app.ini actions generate-runner-token`
**5. Put the token in `~/gitea/.env`** (gitignored, never committed):
```bash
printf 'GITEA_RUNNER_REGISTRATION_TOKEN=%s\n' '<TOKEN>' >> ~/gitea/.env
```
**6. Start the runner** (separate profile so it only runs once the token is set):
```bash
sudo docker compose --profile runner up -d runner
sudo docker compose logs -f runner # should log "Runner registered successfully"
```
The first workflow run pulls the job image `docker.gitea.com/runner-images:ubuntu-latest`
(Node, git, Docker CLI) — give it a minute. `runner_config.yaml` attaches each job
container to the `gitea` network so `actions/checkout` can resolve `server:3000`.
**7. Register the OAuth2 app for Sveltia CMS** (web UI, no server restart):
- Site Administration → OAuth2 Applications → **Add a new OAuth2 application**.
- Application name: `ever-near CMS`
- Redirect URI: `https://ever-near.web.app/admin/index.html`
- **Uncheck "Confidential client"** (PKCE needs a public client).
- Copy the **Client ID** into `ever-near/public/admin/config.yml` as `app_id`, commit,
and push — the Gitea Action rebuilds + redeploys the site with it.
**Gotchas**
- **Job containers must join the `gitea` network** or `actions/checkout` fails with
`Could not resolve host: server`. That's what `runner_config.yaml`
(`container.network: gitea`) does — don't remove it. The compose network is pinned to
the literal name `gitea` via `networks.gitea.name` so the config matches regardless of
the compose project name.
- `uses: actions/checkout@v4` / `actions/setup-node@v4` resolve through Gitea's default
actions mirror (`gitea.com/actions/*`). If a job can't find an action, set
`GITEA__actions__DEFAULT_ACTIONS_URL=https://gitea.com` (already the default) or
reference the action fully: `uses: https://gitea.com/actions/checkout@v4`.
- CORS is scoped to `ever-near.web.app` only. Add more origins to
`GITEA__cors__ALLOW_DOMAINS` (comma-separated) if you connect a custom domain later.
- The runner is behind the `runner` profile; a plain `docker compose up -d` won't start
it. Use `docker compose --profile runner up -d runner`.