# 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`](https://docs.gitea.com/1.26/administration/config-cheat-sheet/) 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](/integrations/gitea-actions/setup) to create the token Atmos uses, then [Plan on Pull Request](/integrations/gitea-actions/plan-on-pull-request) and [Apply on Merge](/integrations/gitea-actions/apply-on-merge). For larger projects, use [affected-component matrices](/integrations/gitea-actions/deploy-affected) to limit work to changed infrastructure.

## What Differs from GitHub Actions

- **Workflow directory** — `.gitea/workflows/` instead of `.github/workflows/`.
- **Checkout** — Run `atmos git clone --ci` instead of `actions/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` (or `GITEA_TOKEN`) and never sends `GITHUB_TOKEN` to Gitea.
- **Permissions** — On Gitea versions that support `permissions:`, grant the job token only the scopes each job needs (for example, `contents: read` for checkout); see [Gitea token permissions](https://docs.gitea.com/usage/actions/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](/ci/planfile-storage) 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 It Locally**

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.

Gitea Actions Example[Read more](/examples/gitea-actions)