From ffb6f130c5193debe47fa8f8ae6c3042e12777e9 Mon Sep 17 00:00:00 2001 From: Nicole Rappe Date: Fri, 16 May 2025 19:41:57 -0600 Subject: [PATCH] Update blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md --- .../05-16-2025 Learning to Leverage Gitea Runners.md | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md b/blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md index 4767b62..d33cff4 100644 --- a/blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md +++ b/blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md @@ -33,7 +33,7 @@ When I finally got around to figuring out the general architecture of how [Gitea - The production server hot-loads the changed configuration files (e.g. Material MkDocs, Traefik, Nginx, etc) and the changes go to into effect immediately ### Docker-Compose Runner Deployment -When it comes to deploying a runner, (*assuming you want to use a docker-based runner) it has a few simple things that need to be configured, the `docker-compose.yml` and the `.env` files. These tell the runner to reach out to Gitea server to register the runner with the given repository that you generated a registration token on. +When it comes to deploying a runner, (*assuming you want to use a docker-based runner*) it has a few simple things that need to be configured, the `docker-compose.yml` and the `.env` files. These tell the runner to reach out to Gitea server to register the runner with the given repository that you generated a registration token on. ```yaml title="docker-compose.yml" version: "3.8" @@ -57,8 +57,14 @@ RUNNER_NAME=gitea-runner-mkdocs REGISTRATION_TOKEN= ``` +### Creating the `config.yaml` +The oddball thing about the way that I configured the Gitea Act Runner was telling it to run the container in "host mode" which tells it to run the tasks / workflows directly on the container itself instead of spinning up an instanced container (referred to as "*Docker-in-Docker*"). This keeps things simpler, but requires us to add a line to the `config.yaml` located at `/srv/containers/gitea-runner-mkdocs/config.yaml`. You can use your preferred text editor to add the following to the file's contents. This tells the runner to use itself for the tasks instead of an instanced docker container. +```yaml title="/srv/containers/gitea-runner-mkdocs/config.yaml" +container_engine: "" +``` + ### Runner Workflow Task Files -When it comes to telling the runner what to do and how to do it, you create what are called runner "**Workflows***. These files reside within `/.gitea/workflows` and are `.yaml` format. You can have multiple workflows for one repository, with different flows that fire-off on different runners. An example of the flow used to replace Git-Repo-Updater's functionality below: +When it comes to telling the runner what to do and how to do it, you create what are called runner "**Workflows**". These files reside within `/.gitea/workflows` and are `.yaml` format. You can have multiple workflows for one repository, with different flows that fire-off on different runners. An example of the flow used to replace Git-Repo-Updater's functionality can be seen below. In the workflow below, it spins up a runner within the Alpine Linux environment that the `docker.io/gitea/act_runner:latest` uses, then installs NodeJS, Git, and Rsync for the core functionality that mirrors Git-Repo-Updater: