Compared to GitHub Actions
Gitea Actions is designed to be compatible with GitHub Actions, with the differences below.
Additional features
Section titled “Additional features”Absolute action URLs
Section titled “Absolute action URLs”uses: accepts an absolute URL to any git host, e.g. uses: https://gitea.com/actions/checkout@v4.
Action prefixes
Section titled “Action prefixes”uses: accepts these prefixes:
self:references your own Gitea instance, e.g.uses: self:owner/repo@v1oruses: self:owner/repo/.gitea/workflows/build.yml@v1builtin:runs an action built into Gitea Runner, which needs no download and no Node in the job image, e.g.uses: builtin:checkout
builtin:checkout accepts the repository, ref, token, path and fetch-depth inputs of actions/checkout with the same defaults, and fails on any other input.
Workflow-relative actions
Section titled “Workflow-relative actions”$/ references the repository and commit of the workflow, or of the enclosing composite action, e.g. uses: $/.gitea/actions/build.
Unlike ./, it needs no checkout first.
Actions written in Go
Section titled “Actions written in Go”See Creating Go Actions.
Support the non-standard syntax @yearly, @monthly, @weekly, @daily, @hourly on schedule
Section titled “Support the non-standard syntax @yearly, @monthly, @weekly, @daily, @hourly on schedule”schedule also accepts @yearly, @monthly, @weekly, @daily and @hourly, which GitHub does not.
Unsupported workflows syntax
Section titled “Unsupported workflows syntax”jobs.<job_id>.environment
Section titled “jobs.<job_id>.environment”jobs.<job_id>.environment is ignored.
Complex runs-on
Section titled “Complex runs-on”runs-on supports:
- Static strings:
runs-on: self-hosted - Arrays of labels:
runs-on: [linux, self-hosted] - String expressions:
runs-on: ${{ github.event_name == 'push' && 'ubuntu-latest' || 'self-hosted' }} - Arrays containing expressions:
runs-on: [linux, "${{ github.event_name == 'push' && 'ubuntu-latest' || 'self-hosted' }}"]
Missing features
Section titled “Missing features”Package repository authorization
Section titled “Package repository authorization”GITEA_TOKEN cannot publish to the package registry of its repository, e.g. to push OCI images.
Use a personal access token instead, see this issue.
Problem Matchers
Section titled “Problem Matchers”Problem matchers are ignored.
Create an error annotation
Section titled “Create an error annotation”Error annotations are ignored.
Expressions
Section titled “Expressions”Expressions support the standard GitHub functions and contexts.
Missing UI features
Section titled “Missing UI features”Pre and Post steps
Section titled “Pre and Post steps”Pre and post steps have no section of their own in the job log.
Services steps
Section titled “Services steps”Service steps have no section of their own in the job log.
Different behavior
Section titled “Different behavior”Job token permissions (permissions)
Section titled “Job token permissions (permissions)”permissions and jobs.<job_id>.permissions control the GITEA_TOKEN permissions, clamped by the repository and owner settings and further restricted for fork pull requests and cross-repository access.
GitHub-only scopes like statuses, checks, deployments, id-token, security-events and pages are not supported, while Gitea adds code, releases, wiki and projects.
See Actions job token permissions.
Downloading actions
Section titled “Downloading actions”Actions without a host, like uses: actions/checkout@v4, are downloaded from https://github.com, or from your own instance when [actions].DEFAULT_ACTIONS_URL is self.
See the Configuration Cheat Sheet.
For other sources, see Absolute action URLs, Action prefixes and Workflow-relative actions.
Context availability
Section titled “Context availability”Context availability is not checked, so contexts like env work in more places.