Update blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md

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 # 
-```
+```
+
+```sh title=".env"
+INSTANCE_URL=https://git.bunny-lab.io
+RUNNER_NAME=gitea-runner-mkdocs
+REGISTRATION_TOKEN=<Generated Here: https://git.bunny-lab.io/bunny-lab/docs/settings/actions/runners>
+```
+
+### 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 `<RepoRoot>/.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.
+