fix: improve and fix some wording in the CI section (#675)

Reviewed-on: https://codeberg.org/Codeberg/Documentation/pulls/675
Reviewed-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
Reviewed-by: Bastian Greshake Tzovaras <gedankenstuecke@noreply.codeberg.org>
Co-authored-by: dawe <dawedawe@posteo.de>
Co-committed-by: dawe <dawedawe@posteo.de>
This commit is contained in:
dawe 2025-09-19 13:19:37 +02:00 committed by Bastian Greshake Tzovaras
parent 4b19f1ec6a
commit 23b6a2e990
3 changed files with 5 additions and 6 deletions

View file

@ -78,7 +78,7 @@ Forgejo Runner is released in both binary and container image (OCI) forms:
Before you deploy the Runner, you need to generate its configuration files and modify as suited.
You can generate them to your current directory by either running the binary on host or in a Docker container.
You can generate them in your current directory by either running the binary on host or in a Docker container.
Make sure to replace `{TOKEN}` with the registration token you copied, and `{NAME}` with any identifier to monitor it
on Codeberg.

View file

@ -7,7 +7,7 @@ eleventyNavigation:
Codeberg's CI resources are run by volunteers, and as such have some limitations in terms of shared resources. However, it is not necessary to self-host and administer your own full CI instance as you can add your own Woodpecker agents to your user or organization.
Some example use-cases where a self-hosted agent are recommended include: when you want faster feedback from CI, to handle long-running or resource-intensive jobs, creating specialized environments for specific architectures, hardware-in-the-loop testing, or setting up larger networked integration tests.
Some example use-cases where a self-hosted agent is recommended include: when you want faster feedback from CI, to handle long-running or resource-intensive jobs, creating specialized environments for specific architectures, hardware-in-the-loop testing, or setting up larger networked integration tests.
This guide will walk you through [setting up your own Woodpecker agent](https://woodpecker-ci.org/docs/administration/configuration/agent) to communicate with Codeberg's CI infrastructure and configuring your workflows to use it.
@ -145,7 +145,7 @@ steps:
You can also add labels to the agent's configuration that can be used in workflows. Labels are key-value maps assigned to specific agents by using the `WOODPECKER_AGENT_LABELS` variable.
For example, say you're creating an IoT project that needs a machine with a specific peripheral, such as a LoRa radio, for testing. You have an agent that has the module attached and you need a way to tell Woodpecker to use that particular machine. [Radio hardware often depends on what part of the world you're in,](https://en.wikipedia.org/wiki/ITU_Region) you also want specify where your agent is located.
For example, say you're creating an IoT project that needs a machine with a specific peripheral, such as a LoRa radio, for testing. You have an agent that has the module attached and you need a way to tell Woodpecker to use that particular machine. [Radio hardware often depends on what part of the world you're in,](https://en.wikipedia.org/wiki/ITU_Region) you also want to specify where your agent is located.
Here is how to add the necessary environment variable to [an agent's docker compose script](#creating-an-agent-with-docker-compose) to label it in ITU Region 1 (Europe is in Region 1) with a lora module attached:

View file

@ -35,12 +35,11 @@ Repositories owned by your codeberg account should automatically be available as
For the usage of our Woodpecker instance, keep the following in mind:
- **CI access is provided as-is and might break at any time** and for an undefined period of time, due to server issues,
for testing and maintenance purpose or human error.
for testing and maintenance purposes or human error.
- **Resource usage must be reasonable** for the intended use-case. CI requires substantial computing resources
(cloning the repo and pulling the image, installing required tools, building and throwing everything away).
Please try to ensure a good balance between code quality/automation and resource usage.
Therefore, please consider twice how to create a good balance between ensuring code quality for your project and
resource usage therefore.
resource usage.
- The CI service requires manual onboarding and Woodpecker has limited Role-Based Access Control (RBAC) capabilities,
which will be a problem for projects with a team-based permission structure or many individual collaborators.
- `linux/amd64` is the sole build target on the Woodpecker CI deployment.