Workflows
Workflow YAML decides when automation runs and in what order, and hands the work itself to stable repository commands and reusable actions.
- Kind
- Orchestration
- Domain
- Build & Delivery
- Applies at
.gitea/workflows/- Status
- Stable
- Source · managed
.gitea/workflows/README.md
01 Defines
Gitea Actions workflow definitions for CI, packaging, publishing, deployment, and maintenance, written as orchestration over repository commands rather than as an implementation of them.
02 Applies when
- Pull requests and main-branch updates need automated checks.
- Artifacts are packaged or published, or environments are deployed, in response to repository events.
- Scheduled or manually dispatched maintenance runs against the repository.
03 Boundaries
- Build, test, audit, packaging, and deployment preparation logic stays in repository commands, build tooling, or actions.
- Repository-specific setup is not hidden inside workflow YAML.
- Important behaviour does not exist only after merge, only on release, or only on one branch.
Expected behaviour
- 01One clear primary CI workflow exercises the full repository path on pull requests and main-branch updates.
- 02Pull request checks are visible, actionable, and representative of main-branch behaviour.
- 03Validation, packaging, publishing, and deployment phases run in an order that is easy to follow.
- 04Event-specific differences are narrow and explicit.
- 05Steps call stable commands such as
make validate,make test,make build, andmake package. - 06Comments state workflow intent wherever the phase model is not obvious.
Behaviour#
A workflow answers three questions: when does automation run, how are its jobs ordered, and which commands or actions does each step invoke. Anything beyond that — how the site builds, how a scanner is configured, how a bucket is uploaded — belongs to the repository, where it can be run and tested without a runner.
- 01
Validate
make validate,make lint,make teston every pull request - 02
Package
make build/make packageproduce the artifact - 03 Publish Artifacts go to a CI, edge, or staging location Release Pipeline
- 04 Deploy Only where the repository has something to deploy Static Site Delivery
The pull request path and the main-branch path should look alike. If a check only runs after merge, a pull request can be green while main breaks; keeping event differences narrow is what makes the pull request result trustworthy.
Orchestration versus implementation#
In the workflow
- Triggers, branch and path filters
- Job ordering, concurrency, and phase boundaries
- Calls to
maketargets and reusable actions - A header comment stating intent
Behind a command or action
- Tool installation and repository-specific setup
- Multi-line shell logic and conditionals
- Build, audit, and packaging details
- Anything a developer would also want to run locally
Examples#
A step in a well-shaped workflow is a single command that means the same thing on a runner and on a laptop:
- name: Validate
run: make validate
The make targets carry the detail. make validate builds the site, validates
Terraform, and checks links because make modules registered those checks — the
workflow does not need to know.
Connections