Update blog/posts/05-16-2025 Learning to Leverage Gitea Runners.md
All checks were successful
GitOps Automatic Deployment / GitOps Automatic Deployment (push) Successful in 7s
All checks were successful
GitOps Automatic Deployment / GitOps Automatic Deployment (push) Successful in 7s
This commit is contained in:
@ -65,7 +65,7 @@ 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 `<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 can be seen 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 `<RepoRoot>/.gitea/workflows` and are `.yaml` format. If you have any familiarity with Ansible, the similarities are staggaring. 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:
|
||||
|
Reference in New Issue
Block a user