From 0775405a873b6fdd194dd0a27c1b6c10b5496ff4 Mon Sep 17 00:00:00 2001 From: Nicole Rappe Date: Fri, 16 May 2025 19:05:57 -0600 Subject: [PATCH] Update blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md --- ...2025 Learning to Leverage Gitea Runners.md | 46 +++++++++++++++++-- 1 file changed, 42 insertions(+), 4 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 9d466e1..45002b1 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 @@ -23,7 +23,7 @@ When I made the [Git-Repo-Updater docker container stack](https://git.bunny-lab. In addition to the above, I had security concerns with the method of how I was interacting with the underlying container storage folders. I was running the containers as `privileged: true`, which was not safe nor secure if the container itself was breached (not likely, but you never know). I also didn't like the idea that was using my own CI/CD pipeline for something that I was certain existed elsewhere with much more hardening built-in, and I felt that I was intellectually "*falling-behind*" if I didn't figure out how to use them and migrate away from my Git-Repo-Updater project. ## Introduction to Gitea Runners -When I finally got around to figuring out the general architecture of how Gitea "Runners" operate, it seemed so much more intuitive than the method I was using in Git-Repo-Updater. The runners can run as a standalone packages, docker containers, or can exist in other forms. The general idea of how the Runners operate is as-follows: +When I finally got around to figuring out the general architecture of how [Gitea Act "Runners"](https://docs.gitea.com/usage/actions/act-runner) operate, it seemed so much more intuitive than the method I was using in Git-Repo-Updater. The runners can run as a standalone packages, docker containers, or can exist in other forms. The general idea of how the Runners operate is as-follows: - You spin up a Gitea runner docker container on a server that can access the server files that need to be overwritten/modified - The Gitea runner container registers itself to the Gitea server using a registration token generated by a specific Gitea repository @@ -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, 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" @@ -49,5 +49,43 @@ services: volumes: - /srv/containers/gitea-runner-mkdocs/config.yaml:/config.yaml # You have to manually make this file before you start the container - /srv/containers/material-mkdocs/docs/docs:/Gitops_Destination # This is where the repository data will be copied to - - /var/run/docker.sock:/var/run/docker.sock # -``` \ No newline at end of file +``` + +```sh title=".env" +INSTANCE_URL=https://git.bunny-lab.io +RUNNER_NAME=gitea-runner-mkdocs +REGISTRATION_TOKEN= +``` + +### 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: + + +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: +```yaml title=".gitea/workflows/gitops-automatic-deployment.yml" +name: GitOps Automatic Deployment + +on: + push: + branches: [ main ] + +jobs: + GitOps Automatic Deployment: + runs-on: gitea-runner-mkdocs + + steps: + - name: Install Node.js, git, and rsync + run: | + apk add --no-cache nodejs npm git rsync + + - name: Checkout Repository + uses: actions/checkout@v3 + + - name: Copy Repository Data to Production Server + run: | + rsync -a --delete --exclude='.git/' . /Gitops_Destination/ +``` + +!!! note "`runs-on` Variable" + In this example workflow file, we are targeting the previously-mentioned `gitea-runner-mkdocs` runner, which we gave that "label" in the docker-compose.yaml file's `GITEA_RUNNER_LABELS` variable. You can name these labels whatever you want, as a way of organizing which runners run which workflows associated with a repository when changes are made to the repository. +