From 232bbfc4b64cf55acd71e4cd70c77b7b322a04ab Mon Sep 17 00:00:00 2001 From: Nicole Rappe Date: Fri, 16 May 2025 21:25:17 -0600 Subject: [PATCH] Update blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md --- blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 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 4bb5cfa..392a0a7 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 @@ -24,7 +24,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 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: +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 (*within my specific GitOps code-to-server use-case*) 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