Actions
Local composite actions under .gitea/actions/ capture reusable orchestration steps, while the logic they orchestrate stays in the build system.
- Kind
- Convention
- Domain
- Build & Delivery
- Applies at
.gitea/actions/- Status
- Stable
- Source · managed
.gitea/actions/README.md
01 Defines
A consistent, repository-local path for Gitea composite actions: small units of orchestration — inputs, outputs, ordered calls — that several workflows can share without copying steps between files.
02 Applies when
- The same sequence of workflow steps appears in more than one workflow.
- A workflow has grown long enough that a phase deserves a name and an interface.
- An orchestration pattern proves useful enough that other repositories might adopt it.
03 Boundaries
- Complex build, test, audit, packaging, and environment logic stays in the build system or repository toolkit.
- There is no split into local and shared action categories unless a concrete need appears.
- An action specific to a single workflow is better expressed as a repository script or command.
Expected behaviour
- 01Composite actions focus on orchestration, consistency, reuse, inputs, and outputs.
- 02Repeated workflow steps are promoted into a script or a composite action rather than duplicated.
- 03Actions that stabilise and prove broadly useful are promoted into shared tooling.
Behaviour#
The model is simple: the build system is intelligent, and CI orchestrates it. A composite action exists because an orchestration pattern is reusable — check out, set up credentials, call a command, pass an output along — even when the work underneath remains entirely repository-owned.
- 01 Inline steps A few steps in one workflow file Workflows
- 02
Composite action
Repeated or growing steps get a name, inputs, and outputs under
.gitea/actions/ - 03 Shared tooling Actions that stabilise and prove broadly useful move out of the repository
Not every promotion goes through an action. When the repeated thing is logic rather than orchestration, it moves down into a script or make target instead, where it can be run outside CI.
Actions versus scripts#
Composite action
- Wires steps together for a workflow
- Declares inputs and outputs for callers
- Runs only inside Gitea Actions
- Useful when the sequence is what repeats
Script
- Implements a narrow, deterministic behaviour
- Takes arguments and environment, returns an exit code
- Runs anywhere — locally, in the devcontainer, or from an action
- Useful when the work is what repeats
Layout#
- .gitea/
- actions/
- README.md Owner documentation for local actions
- <action-name>/ One composite action
- action.yml Inputs, outputs, and the ordered steps
- workflows/ Callers of the actions Workflows
Examples#
This repository currently ships no local actions: .gitea/actions/ holds only
its README. That is a reasonable starting point rather than a gap — the folder
gains an action when a sequence of steps starts repeating across workflows, not
before.
Connections