Gitea Actions
Use Gitea Actions to plan infrastructure changes on pull requests, deploy after review, and run jobs across the components in your stacks. Atmos detects Gitea Actions and reports through Gitea's commit statuses and pull request comments.
Get Started
Gitea Actions runs GitHub-Actions-compatible workflows from .gitea/workflows/. Atmos selects its Gitea provider whenever GITEA_ACTIONS=true, even though Gitea's runner also sets GITHUB_ACTIONS=true.
In Gitea 1.26, the first existing directory in WORKFLOW_DIRS is used for Actions workflows. The default order puts .gitea/workflows before .github/workflows, so adding .gitea/workflows can make existing workflows in .github/workflows undiscoverable to Gitea. Migrate or consolidate the workflows Gitea should run into the selected directory.
Start with Setup and Authentication to create the token Atmos uses, then Plan on Pull Request and Apply on Merge. For larger projects, use affected-component matrices to limit work to changed infrastructure.
What Differs from GitHub Actions
- Workflow directory
.gitea/workflows/instead of.github/workflows/.- Checkout
- Run
atmos git clone --ciinstead ofactions/checkout. JavaScript actions need Node.js inside the job container, and the Atmos image does not include it. - Token
- Atmos reads
ATMOS_CI_GITEA_TOKEN(orGITEA_TOKEN) and never sendsGITHUB_TOKENto Gitea. - Permissions
- On Gitea versions that support
permissions:, grant the job token only the scopes each job needs (for example,contents: readfor checkout); see Gitea token permissions. Older versions may ignore this setting, so restrict access using the server and repository settings. These settings do not restrict a separate personal access token. Atmos reports through commit statuses. - Apply after merge
- Gitea cannot map a merge commit back to its pull request, so a deploy plans the merged commit fresh instead of verifying the plan reviewed in the pull request.
- Not available
- Deployment approvals (Gitea ignores
environment:), OIDC cloud authentication, and merge queues.
Provider Capabilities
The Gitea provider supports commit statuses, marker-based pull request comment updates, status queries, job output and environment files, and log groups. It reads GITEA_* metadata first, falling back to the runner's compatible GITHUB_* variables. Atmos updates only comments owned by the authenticated account. Job summary files are written when the runner supplies one; their display depends on the runner version.
For affected-component detection, check out the pull request's head SHA. Atmos resolves its base SHA from the event payload; unknown pull request checkouts remain unresolved. Push runs use the event's before SHA. A new branch with an all-zero before has no inferred base.
Gitea does not automatically use GitHub artifact storage. Configure a shared planfile store when plans need to survive between jobs. Without a configured planfile store, Atmos skips planfile upload and download, so plans do not persist between jobs. The provider does not yet support remote Actions cache, GitHub Checks annotations, commit comments, or merged-pull-request plan provenance resolution.
Workflow Guides
Run Atmos in Gitea Actions jobs and give it a token for commit statuses and pull request comments.
Review infrastructure changes before merging a pull request. Run an Atmos plan in Gitea Actions and publish the results as job summaries, commit statuses, and pull request comments.
Deploy infrastructure after a change merges, with Atmos running in Gitea Actions.
Run Gitea Actions jobs only for component instances affected by a change.
Run a Gitea Actions workflow across every component instance in your stacks.
Catch mistakes in Gitea Actions workflows before running infrastructure commands.
The Gitea Actions example starts a Gitea server emulator and a runner on your machine, then runs every workflow in these guides. The same workflows run in Atmos's own end-to-end tests.
