Hands-on lab: Gitea Actions on your own Kubernetes

A free, code-first lab that runs GitHub-Actions-compatible CI on your own Kubernetes with Gitea Actions: set up the runner, write your first workflows, chain stages, protect the main branch, use secrets, and build and push an image tagged by commit.

Open the lab on GitHub6 steps · each folder has a short README (goal → run → expect → break it) and the code

What you'll build

The gitea-action-lab runs GitHub-Actions-compatible CI on your own Kubernetes. Gitea queues the jobs, act_runner executes them in containers, and the workflow files are the same YAML you'd use on GitHub:

git push ─► Gitea (queues jobs) ◄─ poll ─ act_runner ─► dind ─► job container (your steps)

It's the first half of a two-lab series: this lab builds and pushes an image; the argocd-gitops-lab then deploys it with GitOps.

A small bakery that bakes to order. Gitea is the order book, the runner is the baker who keeps checking the book for new orders, and each order is baked in a clean oven (a fresh container) so yesterday's crumbs never end up in today's bread.

What you need

A Kubernetes cluster; a single-node k3s VM is enough.
Gitea installed with its Helm chart.
A practice repository: workflows go in .github/workflows/, exactly as on GitHub.

The 6 steps, mapped to this course

Step	Folder	You practise	Course lesson
00	`00-setup`	`act_runner` + Docker-in-Docker on Kubernetes, registered to Gitea	09 · The air-gapped port
01	`01-first-workflow`	A workflow on every push; what checkout really does	01 · Workflows, events and your first pipeline
02	`02-multi-stage-pipeline`	lint → test → package → deploy with `needs:`; stopping workflows you don't need	01, 03 · Real pipelines
03	`03-branch-protection`	No direct pushes; approval, green checks and an issue key on PRs	Git for Engineers, lesson 04
04	`04-secrets-ssh`	Run commands on a remote host with secrets, masked in logs	06 · OIDC federation & secret hygiene
05	`05-build-push-image`	Build, test, push to the registry from `main`, tagged by commit SHA	04 · Build, test and publish container images

Highlights worth knowing before you start

Gitea must know its real address (ROOT_URL), or every job fails at checkout, because the runner clones from that address.
Labels decide where jobs run. runs-on: must match a label your runner offers; ask for one nobody has and the job waits forever.
Every workflow with on: push runs on every push. Disable workflows you're not using, limit them with paths:, or use workflow_dispatch.
Secrets go through env:, never on the command line, and show as *** in logs. The runner must be able to reach any host a job connects to.
Packages belong to the user or organisation, not the repository, in Gitea's registry. Link a package to a repo if you want it shown there.
Docker-in-Docker is privileged: fine for a lab, but the "Hardening the runner" lesson explains what to use in production.

Run the series end to end

Work through steps 00–05 of gitea-action-lab; step 05 leaves a hello-web:<sha7> image in the registry.
Continue with the argocd-gitops-lab to deploy that image to a second cluster with Argo CD.
Move the same workflow files to a GitHub repository and run them there unchanged (only the registry and secrets change).

Recap

Gitea queues, act_runner executes, workflows are GitHub-Actions YAML.
Six steps: runner setup, first workflow, multi-stage pipeline, branch protection, secrets over SSH, build and push an image by commit SHA.
Each step is goal → run → expect → break it; pair it with the course lesson in the table.
Then continue to the Argo CD lab for deployment.

This site is a public version of my personal engineering knowledge hub. It intentionally excludes confidential company information and internal operational details.