Add CI and deploy workflows for Gitea Actions
Some checks failed
CI / backend-lint (push) Failing after 1m43s
CI / frontend-lint (push) Failing after 1m6s

CI runs ruff and eslint/tsc on push to develop and PRs. Deploy
workflow is manual (workflow_dispatch) and builds, pushes, and
deploys images to Unraid via SSH.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Julian Tabel
2026-02-10 12:17:20 +01:00
parent 0c4cc815be
commit 7f8890086f
3 changed files with 90 additions and 9 deletions

View File

@@ -1,10 +1,11 @@
---
# nuzlocke-tracker-jlzs
title: Implement Gitea Actions CI/CD pipeline
status: draft
status: in-progress
type: task
priority: normal
created_at: 2026-02-10T09:38:15Z
updated_at: 2026-02-10T09:38:15Z
updated_at: 2026-02-10T11:12:32Z
parent: nuzlocke-tracker-ahza
---
@@ -14,15 +15,15 @@ Set up Gitea Actions as the CI/CD pipeline for the nuzlocke-tracker. Gitea Actio
- Gitea is already running on Unraid behind Nginx Proxy Manager (`gitea.nerdboden.de`)
- Images are currently built locally and pushed to the Gitea container registry via `deploy.sh`
- Gitea Actions can automate building, pushing images, and triggering deployment on push to `main`
- A Gitea Actions runner is already deployed on Unraid and connected to the Gitea instance
- The workflow syntax is compatible with GitHub Actions, so the same `.github/workflows/` files work on both platforms
## Checklist
- [ ] **Enable Gitea Actions on the Gitea instance** ensure the Actions feature is enabled in `app.ini` (`[actions] ENABLED = true`) and restart Gitea
- [ ] **Set up a Gitea Actions runner** deploy an `act_runner` container on Unraid (or the same host as Gitea), register it with the Gitea instance, and verify it picks up jobs
- [ ] **Create CI workflow** (`.github/workflows/ci.yml`) — on push to `develop` and PRs: lint, run tests (backend + frontend), and report status
- [ ] **Create deploy workflow** (`.github/workflows/deploy.yml`) — on push to `main`: build Docker images (linux/amd64), push to the Gitea container registry, and trigger redeployment on Unraid via SSH
- [ ] **Configure secrets in Gitea**add repository or org-level secrets for registry credentials, SSH key/host for deployment, and any other sensitive values the workflows need
- [ ] **Test the full pipeline** — push a change through `feature/*``develop` `main` and verify the CI and deploy workflows run successfully end-to-end
- [x] **Enable Gitea Actions on the Gitea instance** — Actions feature is enabled and runner is connected
- [x] **Set up a Gitea Actions runner**`act_runner` is deployed on Unraid and registered with Gitea
- [x] **Create CI workflow** (`.github/workflows/ci.yml`) — on push to `develop` and PRs: run `ruff check` + `ruff format --check` for backend, `eslint` + `tsc` for frontend. Tests can be added later when they exist.
- [x] **Create deploy workflow** (`.github/workflows/deploy.yml`) — triggered via `workflow_dispatch` on `main`: build Docker images (linux/amd64), push to the Gitea container registry, deploy to Unraid via SSH (`docker compose pull && docker compose up -d`)
- [ ] **Configure secrets in Gitea**generate a new SSH keypair, add the public key to Unraid root user's `authorized_keys`, add the private key as a Gitea repo secret (`DEPLOY_SSH_KEY`). Also add any registry credentials or other sensitive values the workflows need.
- [ ] **Test the full pipeline** — push a change through `feature/*``develop` (verify CI runs), then merge `develop``main` and trigger the deploy workflow via `workflow_dispatch` to verify end-to-end
- [ ] **Update deployment docs** — document the Gitea Actions setup, how to manage the runner, and how CI/CD fits into the deployment workflow