Automation & CI/CD
.gitea/ is the repository’s automation control folder: event-driven workflows and local actions that orchestrate the repository’s own commands.
- Kind
- Architecture
- Domain
- Build & Delivery
- Applies at
.gitea/- Status
- Stable
- Source · managed
.gitea/README.md
01 Defines
The control folder for Gitea Actions: workflow definitions that say when automation runs, and local reusable actions that share orchestration steps, with the actual work kept behind stable repository commands.
02 Applies when
- A repository validates, packages, publishes, or deploys in response to pushes, pull requests, tags, schedules, or manual dispatch.
- The same checks need to run locally, in a devcontainer, and on a CI runner.
- Several workflows share setup or orchestration steps.
03 Boundaries
- Automation orchestrates; build, test, and deployment logic lives in make modules, scripts, and tools.
- Secrets, credentials, and environment-specific configuration are not stored in workflow files.
- Runner capabilities beyond what a workflow documents are not assumed.
Expected behaviour
- 01Workflows delegate to repository-owned commands such as
make validate,make lint, andmake build. - 02Setup, validation, security, artifact, and deployment responsibilities stay distinct.
- 03Third-party actions and images are pinned when they affect security, publishing, or deployment.
- 04The intent of each workflow is stated in its file header.
- 05YAML that grows complex is converted into composite actions under
actions/.
Behaviour#
Gitea Actions runs YAML workflows on runners in response to repository events. This folder holds those recipes, but it deliberately holds very little else. The repository’s behaviour is implemented once, behind its Command Surface , and automation calls it the same way a developer would.
- 01 Event A push, pull request, tag, schedule, or dispatch triggers a workflow Workflows
- 02 Orchestrate The workflow orders jobs and calls shared steps Actions
- 03
Execute
Steps invoke
make validate,make build,make releaseCommand Surface - 04 Implement Make modules and scripts do the actual work Scripts
Because every layer below the workflow is available outside CI, a failure on a runner can be reproduced locally with the same command, and a change to how something builds is made once rather than in each workflow.
Layout#
Runners#
A runner supplies the operating system, shell, tools, network access, credentials, and isolation boundary for a job. Required tools come from the runner image, from a controlled setup step, or from repository-owned tooling — never from an undocumented assumption about what happens to be installed. Keeping workflows compatible with both local and hosted runners follows from the same principle.
Examples#
The commands a workflow is expected to delegate to are the same ones a developer runs:
make validate
make test
make lint
make build
make release
Connections