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:
@ -46,7 +46,7 @@ services:
|
||||
GITEA_INSTANCE_URL: "${INSTANCE_URL}"
|
||||
GITEA_RUNNER_REGISTRATION_TOKEN: "${REGISTRATION_TOKEN}"
|
||||
GITEA_RUNNER_NAME: "${RUNNER_NAME}"
|
||||
GITEA_RUNNER_LABELS: "gitea-runner-mkdocs" # This can be anything, and is referenced by the workflow task(s) later.
|
||||
GITEA_RUNNER_LABELS: "${RUNNER_NAME}" # This can be anything, and is referenced by the workflow task(s) later.
|
||||
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
|
||||
@ -64,6 +64,11 @@ The oddball thing about the way that I configured the Gitea Act Runner was telli
|
||||
container_engine: ""
|
||||
```
|
||||
|
||||
!!! info "Quick Config Command"
|
||||
```sh
|
||||
echo 'container_engine: ""' > "/srv/containers/gitea-runner-mkdocs/config.yaml"
|
||||
```
|
||||
|
||||
### 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. 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.
|
||||
|
||||
|
Reference in New Issue
Block a user