Merge branch 'main' into audit

2026-11-12 12:54:12 +00:00 · 2026-09-19 00:12:43 +00:00 · 2026-09-19 00:04:45 +00:00 · 2026-09-18 03:37:34 +00:00 · 2026-09-18 03:14:54 +02:00 · 2026-09-17 20:22:15 +00:00
1890 changed files with 8440 additions and 126343 deletions
@@ -8,7 +8,7 @@ on:

 jobs:
  build-docs:
-    runs-on: ubuntu-26.04
+    runs-on: ubuntu-24.04
    env:
      NODE_OPTIONS: --max-old-space-size=8192
      # search only appears once the credentials are set, the build falls back
@@ -18,14 +18,14 @@ jobs:
      PUBLIC_DOCSEARCH_INDEX_NAME: ${{ secrets.DOCSEARCH_INDEX_NAME }}
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-      - uses: pnpm/action-setup@73e46992e05b19abd31f2f3c20e0e7370d762115 # v6
-      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7
+      - uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6
+      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
        with:
-          node-version: 26
+          node-version: 24
          cache: pnpm
      - name: prepare awesome list
        run: |
-          make prepare-awesome-latest prepare-awesome\#27 prepare-awesome\#26 prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22 prepare-awesome-v28
+          make prepare-awesome-latest prepare-awesome\#27 prepare-awesome\#26 prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22
      - name: Install dependencies
        run: pnpm install --frozen-lockfile

@@ -15,14 +15,14 @@ jobs:
      NODE_OPTIONS: --max-old-space-size=8192
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-      - uses: pnpm/action-setup@73e46992e05b19abd31f2f3c20e0e7370d762115 # v6
-      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7
+      - uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6
+      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
        with:
-          node-version: 26
+          node-version: 24
          cache: pnpm
      - name: prepare awesome list
        run: |
-          make prepare-awesome-latest prepare-awesome\#27 prepare-awesome\#26 prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22 prepare-awesome-v28
+          make prepare-awesome-latest prepare-awesome\#27 prepare-awesome\#26 prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22

      - name: install dependencies
        run: pnpm install --frozen-lockfile
@@ -45,7 +45,7 @@ jobs:
          # pull requests from forks do not get the secrets, the build above is
          # then the only check and the preview is silently skipped
          if [ -z "${CLOUDFLARE_API_TOKEN:-}" ] || [ -z "${CLOUDFLARE_ACCOUNT_ID:-}" ]; then
-            echo "::notice::no Cloudflare credentials available (pull request from a fork?), skipping the preview deployment"
+            echo "no Cloudflare credentials available, skipping the preview deployment"
            exit 0
          fi

@@ -2,7 +2,7 @@ name: update api spec files

 on:
  schedule:
-    - cron: '0 3 * * 1' # every Monday at 03:00
+    - cron:  '0 */12 * * *' # every 12 hours on the hour
  workflow_dispatch:

 env:
@@ -6,6 +6,7 @@ sites/*/dist
 sites/*/.astro
 sites/*/.cache
 build/
+.docusaurus/

 # Misc
 .DS_Store
@@ -12,30 +12,20 @@ create_dir:
 clone_awesome: create_dir
 	git clone --branch=$(GITEA_AWESOME_BRANCH) $(GITEA_AWESOME_REMOTE) .tmp/upstream-awesome || true

-# the contributing guide moved to the gitea repository, the readme of
-# awesome-gitea still links to it with a relative path
-AWESOME_CONTRIBUTING_URL := https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md
-FIX_AWESOME_LINKS := sed 's|](contributing.md)|]($(AWESOME_CONTRIBUTING_URL))|'
-
 .PHONY: prepare-awesome-latest
 prepare-awesome-latest: clone_awesome
-	$(FIX_AWESOME_LINKS) .tmp/upstream-awesome/README.md > docs/awesome.md
+	cp .tmp/upstream-awesome/README.md docs/awesome.md

 .PHONY: prepare-awesome\#%
 prepare-awesome\#%:
-	$(FIX_AWESOME_LINKS) .tmp/upstream-awesome/README.md > versioned_docs/version-1.$*/awesome.md
-
-# versions numbered without the 1. prefix, like 28
-.PHONY: prepare-awesome-v%
-prepare-awesome-v%:
-	$(FIX_AWESOME_LINKS) .tmp/upstream-awesome/README.md > versioned_docs/version-$*/awesome.md
+	cp .tmp/upstream-awesome/README.md  versioned_docs/version-1.$*/awesome.md

 .PHONY: install
 install:
 	pnpm install

 .PHONY: prepare-docs
-prepare-docs: install prepare-awesome-latest prepare-awesome\#22 prepare-awesome\#23 prepare-awesome\#24 prepare-awesome\#25 prepare-awesome\#26 prepare-awesome\#27 prepare-awesome-v28
+prepare-docs: install prepare-awesome-latest prepare-awesome\#22 prepare-awesome\#23 prepare-awesome\#24 prepare-awesome\#25 prepare-awesome\#26 prepare-awesome\#27

 .PHONY: build
 build:
@@ -92,7 +82,7 @@ update-runner-docs:
 update-runner-docs-released:
 	./update_runner_docs.sh --released

-# freezes the current docs, runner or cli tree as a new version, see
+# freezes the current docs or runner tree as a new version, see
 # scripts/cut-version.mjs
 .PHONY: cut-version
 cut-version:
@@ -3,14 +3,13 @@
 The sources of [docs.gitea.com](https://docs.gitea.com), built with
 [Astro](https://astro.build) and [Starlight](https://starlight.astro.build).

-The site covers four products, all served from this repository:
+The site covers three products, all served from this repository:

 | Product | Content | Versions | Languages |
 | --- | --- | --- | --- |
-| Docs | `docs/`, `versioned_docs/`, `i18n/` | next, 28, 1.27 … 1.22 | English, 简体中文, 繁體中文 |
-| API | `static/swagger-*.json`, `static/openapi3-*.json` | next, 28, 1.27 … 1.22 | English |
-| Runner | `runner-docs/`, `runner-docs_versioned_docs/` | develop, 5 … 0 | English |
-| CLI | `cli-docs/`, `cli-docs_versioned_docs/` | develop | English |
+| Docs | `docs/`, `versioned_docs/`, `i18n/` | next, 1.27 … 1.22 | English, 简体中文, 繁體中文 |
+| API | `static/swagger-*.json`, `static/openapi3-*.json` | next, 1.27 … 1.22 | English |
+| Runner | `runner-docs/`, `runner-docs_versioned_docs/` | develop, 3 … 0 | English |

 The enterprise documentation is built and deployed from its own repository and
 reached through `/enterprise/`, which a Cloudflare worker maintained elsewhere
@@ -53,8 +52,7 @@ group from the `_category_.json` of its directory.

 ```shell
 make cut-version PRODUCT=docs VERSION=1.28
-make cut-version PRODUCT=runner VERSION=6
-make cut-version PRODUCT=cli VERSION=0.1
+make cut-version PRODUCT=runner VERSION=4
 ```

 This freezes the current tree, its translations and its sidebar. The label of
@@ -81,7 +79,7 @@ make update-api-docs-latest  # refresh only the documents of gitea main
 ```

 The documents of gitea main are refreshed automatically: the `update api spec
-files` workflow runs weekly and opens a pull request whenever gitea main
+files` workflow runs every 12 hours and opens a pull request whenever gitea main
 changed. Released versions are updated by hand when a new gitea version is
 documented.

@@ -90,8 +88,8 @@ documented.
 | Version | Content | URL |
 | --- | --- | --- |
 | develop | `runner-docs/` | `/runner/develop/` |
-| current series | `runner-docs_versioned_docs/version-5/` | `/runner/` |
-| older series | `runner-docs_versioned_docs/version-4/` | `/runner/4/` |
+| current series | `runner-docs_versioned_docs/version-3/` | `/runner/` |
+| older series | `runner-docs_versioned_docs/version-2/` | `/runner/2/` |

 A version directory covers a whole release series (`version-3` documents every
 `3.x` release), so a patch release only needs a content update, not a new
@@ -103,8 +101,7 @@ Its sidebar is written by hand: `runner-sidebars.js` for develop, and
 version.

 The pages under `reference/` are generated from the runner sources — the command
-line reference from `--help`, the example configuration from `config generate`
-(`generate-config` before 3.1):
+line reference from `--help`, the example configuration from `generate-config`:

 ```shell
 make update-runner-docs           # develop docs, from the main branch of gitea/runner
@@ -117,16 +114,6 @@ workflow runs weekly and opens a pull request whenever the runner's CLI or
 example configuration changed. Generating them needs Go, since the script builds
 the runner binary.

-## CLI docs
-
-The documentation of `gt`, the Gitea CLI from
-[gitea/cli](https://gitea.com/gitea/cli), is laid out like the runner docs, with
-its sidebar in `cli-sidebars.js`. No series is documented yet, so `cli-docs/` is
-served at `/cli/`. Once a release exists, cut its series and list it in
-`cliSeries` in `packages/content-loader/src/products.ts`, which moves the develop
-docs to `/cli/develop/`. The guides leave the flags of each command to
-`gt <command> --help`.
-
 ## Deployment

 `main` is built and published by the `Build and Publish Docs site` workflow, to
@@ -1,55 +0,0 @@
---
-sidebar_position: 3
---
-
-# Logging in
-
-On a terminal, `gt auth login` asks for the instance and how to log in. gt never asks for
-your password.
-
-## OAuth in a browser
-
-```bash
-gt auth login --host https://gitea.example.com --oauth
-```
-
-gt opens the instance's authorization page, so single sign-on and two-factor
-authentication work as on the web. The browser has to run on the same machine as gt.
-`--scopes` limits the token to fewer [scopes](/development/oauth2-provider#scopes); gt
-refreshes OAuth tokens on its own.
-
-## Access token
-
-Create a token under **Settings > Applications** on the instance and pass it on stdin:
-
-```bash
-gt auth login --host https://gitea.example.com --with-token < token.txt
-```
-
-The token needs `read:user`, and the scopes of what you do with gt, such as
-`write:repository` and `write:issue` for working on pull requests.
-
-## SSH key
-
-gt can sign its requests with an SSH key registered for your account instead of using a
-token:
-
-```bash
-gt auth login --host https://gitea.example.com --ssh-key ~/.ssh/id_ed25519
-```
-
-## Accounts
-
-Tokens go to the system keyring, or with `--credential-store file` to gt's configuration
-directory on machines without one. Run `gt auth login` once per instance and account.
-gt picks the instance from the repository's remote or `--host`, and the account with
-`gt auth switch` or `--user`. `gt auth status` lists your accounts and `gt auth logout`
-removes one.
-
-For instances behind an access proxy, `--header` and `--client-cert` add headers and a
-client certificate.
-
-## Git over HTTPS
-
-`gt auth setup-git` lets `git push` and `git fetch` over HTTPS use gt's login. gt's own
-clone and checkout commands need no setup.
@@ -1,40 +0,0 @@
---
-sidebar_position: 4
---
-
-# Using gt in CI
-
-Give gt a token and an instance through the environment, and turn prompts off:
-
-| Variable | Description |
-| --- | --- |
-| `GITEA_TOKEN` | Access token; gt never stores it |
-| `GITEA_CLI_HOST` or `GITEA_INSTANCE_URL` | URL of the instance |
-| `GITEA_CLI_REPO` | Repository, like `--repo` |
-
-`--no-input` makes a command fail instead of prompting, and `--yes` confirms changes in
-advance.
-
-## Gitea Actions
-
-Gitea does not allow secret names that start with `GITEA_`, so store the token as, for
-example, `GT_TOKEN`:
-
-```yaml
-on:
-  push:
-    branches: [main]
-
-jobs:
-  staging:
-    runs-on: ubuntu-latest
-    env:
-      GITEA_TOKEN: ${{ secrets.GT_TOKEN }}
-      GITEA_CLI_HOST: ${{ gitea.server_url }}
-      GITEA_CLI_REPO: ${{ gitea.repository }}
-    steps:
-      - run: curl -fsSL https://gitea.com/gitea/cli/raw/branch/main/scripts/install.sh | sh
-      - run: gt workflow run deploy.yml --ref main --field env=staging --no-input
-```
-
-`gt run watch` and `gt pr checks --watch` wait for runs and checks and fail when one fails.
@@ -1,38 +0,0 @@
---
-sidebar_position: 1
-slug: /
---
-
-# Gitea CLI
-
-[gt](https://gitea.com/gitea/cli) is the official command line client for Gitea. It works
-with repositories, issues, pull requests, releases, Actions and the other resources of a
-Gitea instance, from a terminal or a script.
-
-:::info Development version
-These pages describe builds from the `main` branch, published as `nightly` binaries and images.
-:::
-
-gt needs Gitea 28 or later, and Git for the commands that clone, check out or push.
-
-## Getting started
-
-1. [Install gt](installation.md).
-2. [Log in](authentication.md):
-
-   ```bash
-   gt auth login
-   ```
-
-3. Run commands in a clone of a repository on that instance, or select one with `--repo`:
-
-   ```bash
-   gt issue list --label bug
-   gt pr checkout 13
-   gt issue view 42 --repo gitea.com/gitea/cli
-   ```
-
-`gt doctor` checks your setup and suggests a fix for each problem it finds.
-
-`gt <command> --help` lists the flags of a command, and `gt help environment` the global
-flags and environment variables.
@@ -1,37 +0,0 @@
---
-sidebar_position: 2
---
-
-# Installation
-
-gt is a single binary for Linux, macOS, Windows and FreeBSD.
-
-## Install script
-
-The install script downloads gt from [dl.gitea.com](https://dl.gitea.com/gitea-cli/),
-verifies its checksum and installs it.
-
-```bash
-# Linux, macOS, FreeBSD
-curl -fsSL https://gitea.com/gitea/cli/raw/branch/main/scripts/install.sh | sh
-```
-
-```powershell
-# Windows
-irm https://gitea.com/gitea/cli/raw/branch/main/scripts/install.ps1 | iex
-```
-
-Set `GITEA_CLI_VERSION` to install a specific version, or `nightly` for the latest build
-of `main`.
-
-## Other ways
-
- **Binaries:** download them from [dl.gitea.com/gitea-cli](https://dl.gitea.com/gitea-cli/).
- **Docker:** the [`gitea/gitea-cli`](https://hub.docker.com/r/gitea/gitea-cli) image runs
-  `gt` as its entry point.
- **Go:** `go install gitea.dev/cli/cmd/gt@latest`
-
-## Shell completion and man pages
-
-`gt completion <shell>` prints the completion script for bash, zsh, fish or PowerShell;
-`gt completion <shell> --help` shows how to load it. `gt man` prints the manual.
@@ -1,22 +0,0 @@
---
-sidebar_position: 5
---
-
-# Output and scripting
-
-Scripts should read JSON: the text output is meant for people and may change.
-
-```bash
-gt pr view 123 --json number,title,state
-gt issue list --json number,title --jq '.[] | "\(.number)\t\(.title)"'
-```
-
-`--json` prints all fields or the ones you list; the **JSON FIELDS** section of a command's
-`--help` names them. `--jq` filters the result without needing jq installed. Piped lists
-print as tab-separated values.
-
-gt exits with 0 on success, 1 when a command fails, 2 on a usage error and 4 when
-authentication is missing or rejected; `gt help exit-codes` lists all codes.
-
-`gt api` calls any API endpoint with gt's login, and `gt alias set` defines shortcuts for
-commands you use often.
@@ -1 +0,0 @@
-[]
@@ -1,16 +0,0 @@
-// Sidebar of the gt (Gitea CLI) documentation (develop version).
-// Released versions carry their own copy in
-// cli-docs_versioned_sidebars/version-<version>-sidebars.json.
-module.exports = {
-  cli: [
-    {
-      type: 'doc',
-      id: 'index',
-      label: 'What is gt?',
-    },
-    'installation',
-    'authentication',
-    'ci',
-    'scripting',
-  ],
-};
@@ -2,8 +2,8 @@
 # is copied into the build output by the publish workflow, so that it is not
 # uploaded to S3/CloudFront where it would be publicly readable at /_headers.
 #
-# The build emits a single content hashed asset directory shared by every
-# language, so no per locale rules are needed.
+# Unlike the docusaurus build, astro emits a single content hashed asset
+# directory shared by every language, so no per locale rules are needed.

 # Content hashed build output (js, css, fonts). The file name changes with the
 # content, so these can be cached forever.
@@ -1,19 +1,17 @@
 # Redirects for legacy URLs and routes the site no longer serves directly.

-# The api reference, the runner and the cli docs are separate products,
-# published in english only, so they have no localized copy.
+# The api reference and the runner docs are separate products, published in
+# english only. Docusaurus served an empty localized copy of them.
 /zh-cn/api/* /api/:splat 301
 /zh-tw/api/* /api/:splat 301
 /zh-cn/runner/* /runner/:splat 301
 /zh-tw/runner/* /runner/:splat 301
-/zh-cn/cli/* /cli/:splat 301
-/zh-tw/cli/* /cli/:splat 301

 # The version served at the root of a product is also reachable under its
 # number, which is what the release notes and old links use.
-/api/28/* /api/:splat 301
+/api/1.27/* /api/:splat 301
 /runner/3/* /runner/:splat 301
-/28/* /:splat 301
+/1.27/* /:splat 301

 # The local search plugin had a results page of its own, algolia docsearch is a
 # modal opened from any page.
@@ -7,7 +7,6 @@
    "https://docs.gitea.com/zh-cn/",
    "https://docs.gitea.com/zh-tw/",
    "https://docs.gitea.com/runner/",
-    "https://docs.gitea.com/cli/",
    "https://docs.gitea.com/api/",
    "https://docs.gitea.com/enterprise/"
  ],
@@ -16,8 +15,7 @@
    "https://docs.gitea.com/1.2*/**",
    "https://docs.gitea.com/*/1.2*/**",
    "https://docs.gitea.com/api/1.2*/**",
-    "https://docs.gitea.com/runner/[0-9]/**",
-    "https://docs.gitea.com/cli/[0-9]*/**"
+    "https://docs.gitea.com/runner/[0-9]/**"
  ],
  "selectors": {
    "lvl0": { "selector": "//nav[contains(@aria-labelledby,'starlight__sidebar')]//a[@aria-current='page']/ancestor::details//summary//span", "type": "xpath", "global": true, "default_value": "Documentation" },
@@ -94,16 +94,16 @@ Most web and API requests pick up the signed-in user automatically.

 Other entry points record a system actor:

- `gitea:cli` for `gitea admin` commands and the `system:startup` and
+- `(gitea-cli)` for `gitea admin` commands and the `system:startup` and
  `system:shutdown` events
- `gitea:auth-source` for authentication-source syncs and for users an
+- `(gitea-auth-source)` for authentication-source syncs and for users an
  authentication source creates or updates at sign-in
 - `gitea-actions` for Gitea Actions tasks
- `gitea:deploy-key` for pushes with a deploy key
+- `(deploy-key)` for pushes with a deploy key
 - `(Cron)` for scheduled cron tasks
 - `Unknown` when no actor can be resolved

-Events of the `gitea:cli` actor use origin `cli`. Cron tasks, git hooks and
+Events of the `(gitea-cli)` actor use origin `cli`. Cron tasks, git hooks and
 other background work use origin `system`.

 ## What is recorded
@@ -337,13 +337,9 @@ The default login user email is `X-WEBAUTH-EMAIL`, you can change it via changin

 If set `ENABLE_REVERSE_PROXY_FULL_NAME=true`, a user full name expected in `X-WEBAUTH-FULLNAME` will be assigned to the user when auto creating the user. You can also change the header name with `REVERSE_PROXY_AUTHENTICATION_FULL_NAME`.

-It applies to the web interface, Git over HTTP, Git LFS and the package registry.
+You can also limit the reverse proxy's IP address range with `REVERSE_PROXY_TRUSTED_PROXIES` which default value is `127.0.0.0/8,::1/128`. By `REVERSE_PROXY_LIMIT`, you can limit trusted proxies level.

-:::warning
-Gitea trusts these headers on every request it receives. Make sure Gitea is only reachable through your authenticating proxy, and that the proxy sets or removes these headers on every request, including on paths you exempt from authentication, for example for Git or package clients. `REVERSE_PROXY_TRUSTED_PROXIES` does not restrict them.
-:::
-
-To also accept them on the REST API under `/api/v1`, enable:
+You can enable the this authentication method for the API with

 ```ini
 [service]
@@ -83,7 +83,7 @@ cd gitea-dump-1610949662
 mv app.ini /etc/gitea/conf/app.ini
 mv data/* /var/lib/gitea/data/
 mv log/* /var/lib/gitea/log/
-mv repos/* /var/lib/gitea/data/gitea-repositories/
+mv repos/* /var/lib/gitea/data/repositories/
 chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea

 # mysql
@@ -130,8 +130,8 @@ In addition, there is _`StaticRootPath`_ which can be set as a built-in at build
   HTTP protocol.
 - `USE_COMPAT_SSH_URI`: **false**: Force ssh:// clone url instead of scp-style uri when
   default SSH port is used.
- `GO_GET_CLONE_URL_PROTOCOL`: **_empty_**: Scheme of the returned URL for the "go get" response.
-   Default is "https" if DISABLE_HTTP_GIT=false or SSH is disabled, otherwise "ssh".
+- `GO_GET_CLONE_URL_PROTOCOL`: **https**: Value for the "go get" request returns the repository url as https or ssh
+   default is https.
 - `ACCESS_CONTROL_ALLOW_ORIGIN`: **_empty_**: Value for Access-Control-Allow-Origin header,
   default is not to present.

@@ -179,7 +179,7 @@ In addition, there is _`StaticRootPath`_ which can be set as a built-in at build
 - `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES`: **false**: In default squash-merge messages include the commit message of all commits comprising the pull request.
 - `ADD_CO_COMMITTER_TRAILERS`: **true**: Add co-authored-by and co-committed-by trailers to merge commit messages if committer does not match author.
 - `RETARGET_CHILDREN_ON_MERGE`: **true**: Retarget child pull requests to the parent pull request branch target on merge of parent pull request. It only works on merged PRs where the head and base branch target the same repo.
- `DEFAULT_DELETE_BRANCH_AFTER_MERGE`: **true**: Set the default value for "Delete pull request branch after merge by default" for new repositories.
+- `DEFAULT_DELETE_BRANCH_AFTER_MERGE`: **false**: Set the default value for "Delete pull request branch after merge by default" for new repositories.
 - `DEFAULT_TITLE_SOURCE`: **auto**: Default source for the pull request title when opening a new PR. Valid options:
  - `first-commit`: Uses the oldest commit's summary as the title. If there are multiple commits, still uses the first commit's message.
  - `auto`: Uses the commit's summary when the PR contains a single commit; when there are multiple commits, converts the branch name into a human-readable title by normalizing separators and casing.
@@ -270,10 +270,9 @@ The following configuration set `Content-Type: application/vnd.android.package-a
 - `FOLDER_ICON_THEME`: **basic**: The icon theme for folders (basic/material).
 - `MAX_DISPLAY_FILE_SIZE`: **8388608**: Max size of files to be displayed (default is 8MiB)
 - `AMBIGUOUS_UNICODE_DETECTION`: **true**: Detect ambiguous unicode characters in file contents and show warnings on the UI
- `REACTIONS`: All available reactions users can choose on issues, pull requests and comments.
+- `REACTIONS`: All available reactions users can choose on issues/prs and comments
    Values can be emoji alias (:smile:) or a unicode emoji.
    For custom reactions, add a tightly cropped square image to public/assets/img/emoji/reaction_name.png
- `RELEASE_REACTIONS`: **+1, laugh, hooray, heart, rocket, eyes**: Reactions available for releases, in the same format as `REACTIONS`.
 - `REACTION_MAX_USER_NUM`: **10**: Change the number of users that are displayed in reactions tooltip (triggered by mouse hover).
 - `CUSTOM_EMOJIS`: **gitea, codeberg, gitlab, git, github, gogs**: Additional Emojis not defined in the utf8 standard.
    By default, we support Gitea (:gitea:), to add more copy them to public/assets/img/emoji/emoji_name.png and
@@ -349,7 +348,8 @@ The following configuration set `Content-Type: application/vnd.android.package-a
 - `PROXY_PROTOCOL_TLS_BRIDGING`: **false**: When protocol is https, expect PROXY protocol headers after TLS negotiation.
 - `PROXY_PROTOCOL_HEADER_TIMEOUT`: **5s**: Timeout to wait for PROXY protocol header (set to 0 to have no timeout)
 - `PROXY_PROTOCOL_ACCEPT_UNKNOWN`: **false**: Accept PROXY protocol headers with Unknown type.
- `ROOT_URL`: **`{PROTOCOL}://localhost:{HTTP_PORT}/`**:
+- `DOMAIN`: **localhost**: Domain name of this server.
+- `ROOT_URL`: **`{PROTOCOL}://{DOMAIN}:{HTTP_PORT}/`**:
   Overwrite the automatically generated public URL.
   This is useful if the internal and the external URL don't match (e.g. behind a reverse proxy).
 - `PUBLIC_URL_DETECTION`: **`auto`**: Controls how to generate the public URL. Most instances should use the "auto" behavior,
@@ -404,7 +404,7 @@ The following configuration set `Content-Type: application/vnd.android.package-a
  If it is set to `(DOER_USERNAME)`, it will use current signed-in user's username.
  This option is only for some advanced users who have configured their SSH reverse-proxy and need to use different usernames for git SSH clone.
  Most users should just leave it blank and/or modify the `BUILTIN_SSH_SERVER_USER`.
- `SSH_DOMAIN`: **_empty_**: Domain name to be exposed in clone URL, defaults to the domain part of ROOT_URL
+- `SSH_DOMAIN`: **`{DOMAIN}`**: Domain name of this server, used for displayed clone URL.
 - `SSH_PORT`: **22**: SSH port displayed in clone URL. If you need a different "SSH clone port" from the real "SSH listen port", set the SSH_LISTEN_PORT separately.
 - `SSH_LISTEN_HOST`: **0.0.0.0**: Listen address for the built-in SSH server.
 - `SSH_LISTEN_PORT`: **`{SSH_PORT}`**: Port for the built-in SSH server.
@@ -420,7 +420,7 @@ The following configuration set `Content-Type: application/vnd.android.package-a
 - `SSH_SERVER_CIPHERS`: **`chacha20-poly1305@openssh.com`, `aes128-ctr`, `aes192-ctr`, `aes256-ctr`, `aes128-gcm@openssh.com`, `aes256-gcm@openssh.com`**: For the built-in SSH server, choose the ciphers to support for SSH connections, for system SSH this setting has no effect.
 - `SSH_SERVER_KEY_EXCHANGES`: **curve25519-sha256, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, diffie-hellman-group14-sha256, diffie-hellman-group14-sha1**: For the built-in SSH server, choose the key exchange algorithms to support for SSH connections, for system SSH this setting has no effect.
 - `SSH_SERVER_MACS`: **`hmac-sha2-256-etm@openssh.com`, `hmac-sha2-256`, `hmac-sha1`**: For the built-in SSH server, choose the MACs to support for SSH connections, for system SSH this setting has no effect
- `SSH_SERVER_HOST_KEYS`: **ssh/gitea.rsa, ssh/gitea.ed25519, ssh/gitea.ecdsa, ssh/gogs.rsa**: For the built-in SSH server, choose the keypairs to offer as the host key. The private key should be at `SSH_SERVER_HOST_KEY` and the public `SSH_SERVER_HOST_KEY.pub`. Relative paths are made absolute relative to the `APP_DATA_PATH`. If none of the keys exist, a 4096 bit RSA, a 256 bit ECDSA and an ED25519 key will be created for you.
+- `SSH_SERVER_HOST_KEYS`: **ssh/gitea.rsa, ssh/gogs.rsa**: For the built-in SSH server, choose the keypairs to offer as the host key. The private key should be at `SSH_SERVER_HOST_KEY` and the public `SSH_SERVER_HOST_KEY.pub`. Relative paths are made absolute relative to the `APP_DATA_PATH`. If no key exists a 4096 bit RSA key will be created for you.
 - `SSH_KEY_TEST_PATH`: **/tmp**: Directory to create temporary files in when testing public keys using ssh-keygen, default is the system temporary directory.
 - `SSH_KEYGEN_PATH`: **_empty_**: Use `ssh-keygen` to parse public SSH keys. The value is passed to the shell. By default, Gitea does the parsing itself.
 - `SSH_EXPOSE_ANONYMOUS`: **false**: Enable exposure of SSH clone URL to anonymous visitors, default is false.
@@ -587,7 +587,8 @@ And the following unique queues:
 - `SECRET_KEY`: **\<random at every install\>**: Global secret key. This key is VERY IMPORTANT, if you lost it, the data encrypted by it (like 2FA secret) can't be decrypted anymore.
 - `SECRET_KEY_URI`: **_empty_**: Instead of defining SECRET_KEY, this option can be used to use the key stored in a file (example value: `file:/etc/gitea/secret_key`). It shouldn't be lost like SECRET_KEY.
 - `LOGIN_REMEMBER_DAYS`: **31**: How long to remember that a user is logged in before requiring relogin (in days).
- `COOKIE_REMEMBER_NAME`: **gitea\_remember**: Name of cookie used to store authentication information.
+- `COOKIE_REMEMBER_NAME`: **gitea\_incredible**: Name of cookie used to store authentication
+   information.
 - `REVERSE_PROXY_LOGOUT_REDIRECT`: **_empty_**: URL or relative path to redirect users to after logout when authentication is handled by a reverse proxy or SSO. For example: `/my-sso/logout?return=/my-sso/home`.
 - `REVERSE_PROXY_AUTHENTICATION_USER`: **X-WEBAUTH-USER**: Header name for reverse proxy
   authentication.
@@ -595,8 +596,7 @@ And the following unique queues:
   authentication provided email.
 - `REVERSE_PROXY_AUTHENTICATION_FULL_NAME`: **X-WEBAUTH-FULLNAME**: Header name for reverse proxy
   authentication provided full name.
- `REVERSE_PROXY_LIMIT`: **1**: Interpret the X-Real-IP, X-Forwarded-For or Forwarded header, in that order, and set this as the remote IP for the request.
-   The client port is taken from the header value or, with X-Real-IP, from X-Real-Port.
+- `REVERSE_PROXY_LIMIT`: **1**: Interpret X-Forwarded-For header or the X-Real-IP header and set this as the remote IP for the request.
   Number of trusted proxy count. Set to zero to not use these headers.
 - `REVERSE_PROXY_TRUSTED_PROXIES`: **127.0.0.0/8,::1/128**: List of IP addresses and networks separated by comma of trusted proxy servers. Use `*` to trust all.
 - `X_FRAME_OPTIONS`: **SAMEORIGIN**: Set the `X-Frame-Options` header value for all HTTP responses. Set to `unset` to not send the header. Previously located in `[cors]`.
@@ -647,25 +647,14 @@ And the following unique queues:
 - `SUCCESSFUL_TOKENS_CACHE_SIZE`: **20**: Cache successful token hashes. API tokens are stored in the DB as pbkdf2 hashes however, this means that there is a potentially significant hashing load when there are multiple API operations. This cache will store the successfully hashed tokens in a LRU cache as a balance between performance and security.
 - `DISABLE_QUERY_AUTH_TOKEN`: **false**: Reject API tokens sent in URL query string (Accept Header-based API tokens only). This setting will default to `true` in Gitea 1.23 and be deprecated in Gitea 1.24.
 - `TWO_FACTOR_AUTH`: **_empty_**: set to enforced to enforce two factor authentication. Only available in Gitea 1.24 and later.
- `EGRESS_MODE`: **lax**: Egress mode toggles between strictness of outgoing requests:
-  - `lax` non-public targets (private, loopback, link-local, CGNAT and special-use ranges) to be allowed, it allows all public ones
-  - `strict` requires an explicit allow of all addresses
- `ALLOWED_HOST_LIST`: **_empty_**: Webhook and oauth2 clients can only call allowed hosts for security reasons. Comma separated list, eg: `192.168.1.0/24:3000`, `[2001:db8::/32]:9090`, `*.mydomain.com:[80|443]`
+- `ALLOWED_HOST_LIST`: **external**: Webhook and oauth2 clients can only call allowed hosts for security reasons. Comma separated list.
  - Built-in networks:
    - `loopback`: 127.0.0.0/8 for IPv4 and ::1/128 for IPv6, localhost is included.
-    - `private`: RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), RFC 4193 (FC00::/7) and RFC 6598 CGNAT (100.64.0.0/10). Also called LAN/Intranet.
-  - CIDR list: `1.2.3.0/8`, `2001:db8::/32`, and with a port `[2001:db8::/32]:9090` (IPv6 addresses and CIDRs need brackets when a port is given)
-  - Host matching: `example.com` matches the host and any subdomain, dot-anchored so `notexample.com` never matches. `*.example.com` and `.example.com` match only subdomains, the apex itself is excluded. IDN names must be given as punycode.
-  - All addresses can have ports specified. Accepted port specs:
-    - a single port: `192.168.1.0/24:3000`
-    - a range, both bounds inclusive: `*.mydomain.com:3000-3010`
-    - a bracketed set of ports and ranges, `|` separated: `*.mydomain.com:[80|443|3000-3010]`
-    - all ports: `*.mydomain.com:*`
-  - A portless entry covers all ports in `lax` mode, only 80 and 443 in `strict` mode
-  - Port specs apply only where the list is consulted: in `lax` mode that is non-public targets alone, public targets are allowed on every port whatever the list says. In `strict` mode every target is checked, so ports restrict public hosts too.
-  - Non-public targets need an IP or built-in entry, a host name entry alone never covers them.
-  - Reserved addresses (the IPv4-embedding NAT64, Teredo and 6to4 ranges, this-network, multicast and broadcast) are denied whatever the list says. To reach them configure an HTTP proxy
-  - This list is enforced on direct connections only. When an HTTP proxy is configured, restricting the proxied target is the proxy server's responsibility.
+    - `private`: RFC 1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and RFC 4193 (FC00::/7). Also called LAN/Intranet.
+    - `external`: A valid non-private unicast IP, you can access all hosts on public internet.
+    - `*`: All hosts are allowed.
+  - CIDR list: `1.2.3.0/8` for IPv4 and `2001:db8::/32` for IPv6
+  - Wildcard hosts: `*.mydomain.com`, `192.168.100.*`

 ## Audit (`audit`)

@@ -681,8 +670,8 @@ And the following unique queues:

 ## OpenID (`openid`)

- `ENABLE_OPENID_SIGNIN`: **false**: Allow authentication in via OpenID.
- `ENABLE_OPENID_SIGNUP`: **false**: Allow registering via OpenID.
+- `ENABLE_OPENID_SIGNIN`: **true**: Allow authentication in via OpenID.
+- `ENABLE_OPENID_SIGNUP`: **! DISABLE\_REGISTRATION**: Allow registering via OpenID.
 - `WHITELISTED_URIS`: **_empty_**: If non-empty, list of POSIX regex patterns matching
   OpenID URI's to permit.
 - `BLACKLISTED_URIS`: **_empty_**: If non-empty, list of POSIX regex patterns matching
@@ -717,7 +706,7 @@ And the following unique queues:
   Requires `Mailer` to be enabled.
 - `REGISTER_MANUAL_CONFIRM`: **false**: Enable this to manually confirm new registrations.
   Requires `REGISTER_EMAIL_CONFIRM` to be disabled.
- `DISABLE_REGISTRATION`: **true**: Disable registration, after which only admin can create
+- `DISABLE_REGISTRATION`: **false**: Disable registration, after which only admin can create
   accounts for users.
 - `REQUIRE_EXTERNAL_REGISTRATION_PASSWORD`: **false**: Enable this to force externally created
   accounts (via GitHub, OpenID Connect, etc) to create a password.
@@ -741,8 +730,8 @@ And the following unique queues:
   If you set it to false, maybe it also needs to set `ENABLE_BASIC_AUTHENTICATION` to false to
   completely disable password-based authentication.
 - `ENABLE_PASSKEY_AUTHENTICATION`: **true**: Allow users to sign-in with a passkey
- `ENABLE_REVERSE_PROXY_AUTHENTICATION`: **false**: Enable reverse proxy authentication for the web interface, Git over HTTP, Git LFS and the package registry. Gitea must only be reachable through the proxy, see [Reverse Proxy](authentication.md#reverse-proxy).
- `ENABLE_REVERSE_PROXY_AUTHENTICATION_API`: **false**: Enable reverse proxy authentication for the REST API under `/api/v1`.
+- `ENABLE_REVERSE_PROXY_AUTHENTICATION`: **false**: Enable this to allow reverse proxy authentication for web requests
+- `ENABLE_REVERSE_PROXY_AUTHENTICATION_API`: **false**: Enable this to allow reverse proxy authentication for API requests, the reverse proxy is responsible for ensuring that no CSRF is possible.
 - `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION`: **false**: Enable this to allow auto-registration
   for reverse authentication.
 - `ENABLE_REVERSE_PROXY_EMAIL`: **false**: Enable this to allow to auto-registration with a
@@ -776,7 +765,7 @@ And the following unique queues:
 - `DEFAULT_ALLOW_ONLY_CONTRIBUTORS_TO_TRACK_TIME`: **true**: Only allow users with write permissions to track time.
 - `EMAIL_DOMAIN_ALLOWLIST`: **_empty_**: If non-empty, comma separated list of domain names that can only be used to register on this instance, wildcard is supported.
 - `EMAIL_DOMAIN_BLOCKLIST`: **_empty_**: If non-empty, comma separated list of domain names that cannot be used to register on this instance, wildcard is supported.
- `SHOW_REGISTRATION_BUTTON`: **false**: Show Registration button, defaults to true only if both DISABLE_REGISTRATION and ALLOW_ONLY_EXTERNAL_REGISTRATION are false
+- `SHOW_REGISTRATION_BUTTON`: **! DISABLE\_REGISTRATION**: Show Registration Button
 - `SHOW_MILESTONES_DASHBOARD_PAGE`: **true** Enable this to show the milestones dashboard page - a view of all the user's milestones
 - `AUTO_WATCH_NEW_REPOS`: **true**: Enable this to let all organisation users watch new repos when they are created
 - `AUTO_WATCH_ON_CHANGES`: **false**: Enable this to make users watch a repository after their first commit to it
@@ -786,7 +775,8 @@ And the following unique queues:
 - `DEFAULT_ORG_MEMBER_VISIBLE`: **false** True will make the membership of the users visible when added to the organisation.
 - `ALLOW_ONLY_INTERNAL_REGISTRATION`: **false** Set to true to force registration only via Gitea.
 - `ALLOW_ONLY_EXTERNAL_REGISTRATION`: **false** Set to true to force registration only using third-party services.
- `NO_REPLY_ADDRESS`: **_empty_**: Value for the domain part of the user's email address in the git log if user has set KeepEmailPrivate to true. The user's email will be replaced with a concatenation of the user name in lower case, "@" and NO_REPLY_ADDRESS. Default value is "noreply." + the domain part of ROOT_URL
+- `NO_REPLY_ADDRESS`: **noreply.DOMAIN** Value for the domain part of the user's email address in the Git log if user has set KeepEmailPrivate to true. DOMAIN resolves to the value in server.DOMAIN.
+  The user's email will be replaced with a concatenation of the user name in lower case, "@" and NO_REPLY_ADDRESS.
 - `USER_DELETE_WITH_COMMENTS_MAX_TIME`: **0** Minimum amount of time a user must exist before comments are kept when the user is deleted.
 - `VALID_SITE_URL_SCHEMES`: **http, https**: Valid site url schemes for user profiles

@@ -819,11 +809,9 @@ Define allowed algorithms and their minimum key length (use -1 to disable a type
 - `DELIVER_TIMEOUT`: **5**: Delivery timeout (sec) for shooting webhooks.
 - `SKIP_TLS_VERIFY`: **false**: Allow insecure certification.
 - `PAGING_NUM`: **10**: Number of webhook history events that are shown in one page.
- `PROXY_URL`: **_empty_**: Proxy server URL, support http://, https://, socks5://, blank will follow environment http_proxy/https_proxy. If not given, will use global proxy setting.
+- `PROXY_URL`: **_empty_**: Proxy server URL, support http://, https//, socks://, blank will follow environment http_proxy/https_proxy. If not given, will use global proxy setting.
 - `PROXY_HOSTS`: **_empty_`**: Comma separated list of host names requiring proxy. Glob patterns (*) are accepted; use ** to match all hosts. If not given, will use global proxy setting.

-When a proxy is configured, Gitea does not enforce `[security]` `ALLOWED_HOST_LIST` on the proxied target, the proxy server is expected to restrict it.
-
 ## Mailer (`mailer`)

 :::warning
@@ -898,27 +886,27 @@ In-Reply-To =

 ## Cache (`cache`)

- `ADAPTER`: **memory**: Either `memory`, `redis`, `memcache`, or `twoqueue`.
- `INTERVAL`: **60**: For `memory` and `twoqueue`, GC interval in seconds.
- `HOST`: **_empty_**: For `redis` and `memcache`, connection host address. For `twoqueue` sets configuration for the queue. If left empty while `ADAPTER` is `redis`, it falls back to [redis/CONN_STR](#redis-redis) when that is set.
+- `ADAPTER`: **memory**: Cache engine adapter, either `memory`, `redis`, `twoqueue` or `memcache`. (`twoqueue` represents a size limited LRU cache.)
+- `INTERVAL`: **60**: Garbage Collection interval (sec), for memory and twoqueue cache only.
+- `HOST`: **_empty_**: Connection string for `redis` and `memcache`. For `twoqueue` sets configuration for the queue. If left empty while `ADAPTER` is `redis`, it falls back to [redis/CONN_STR](#redis-redis) when that is set.
  - Redis: `redis://:[email protected]:6379/0?pool_size=100&idle_timeout=180s` (See [queue/CONN_STR](#queue-queue-and-queue) for information on additional supported connection types)
    - For a Redis cluster: `redis+cluster://:[email protected]:6379/0?pool_size=100&idle_timeout=180s`
    - For a Redis sentinel: `redis+sentinel://:macaron@sentinel0:26379,sentinel1:26379,sentinel2:26379/0?pool_size=100&idle_timeout=180s&master_name=mymaster`
-  - Memcache: `127.0.0.1:11211`
+  - Memcache: `127.0.0.1:9090;127.0.0.1:9091`
  - TwoQueue LRU cache: `{"size":50000,"recent_ratio":0.25,"ghost_ratio":0.5}` or `50000` representing the maximum number of objects stored in the cache.
- `ITEM_TTL`: **16h**: Time to keep items in cache if not used. Setting it to -1 disables caching.
+- `ITEM_TTL`: **16h**: Time to keep items in cache if not used, Setting it to -1 disables caching.

 ## Cache - LastCommitCache settings (`cache.last_commit`)

- `ITEM_TTL`: **8760h**: Time to keep items in cache if not used. Setting it to -1 disables caching.
+- `ITEM_TTL`: **8760h**: Time to keep items in cache if not used, Setting it to -1 disables caching.
 - `COMMITS_COUNT`: **1000**: Only enable the cache when repository's commits count great than.

 ## Session (`session`)

- `PROVIDER`: **file**: Either "memory", "file", "redis" or "db", default is "file". "db" will reuse the configuration in `[database]`
+- `PROVIDER`: **memory**: Session engine provider \[memory, file, redis, db, mysql, couchbase, memcache, postgres\]. Setting `db` will reuse the configuration in `[database]`
 - `PROVIDER_CONFIG`: **data/sessions**: For file, the root path; for db, empty (database config will be used); for others, the connection string. Relative paths will be made absolute against _`AppWorkPath`_. For the `redis` provider, if left empty it falls back to [redis/CONN_STR](#redis-redis) when that is set.
 - `COOKIE_SECURE`:**_empty_**: `true` or `false`. Enable this to force using HTTPS for all session access. If not set, it defaults to `true` if the ROOT_URL is an HTTPS URL.
- `COOKIE_NAME`: **gitea\_session**: Session cookie name
+- `COOKIE_NAME`: **i\_like\_gitea**: The name of the cookie used for the session ID.
 - `GC_INTERVAL_TIME`: **86400**: GC interval in seconds.
 - `SESSION_LIFE_TIME`: **86400**: Session life time in seconds, default is 86400 (1 day)
 - `DOMAIN`: **_empty_**: Sets the cookie Domain
@@ -945,7 +933,7 @@ In-Reply-To =
  - none = no avatar will be displayed
  - random = random avatar will be generated
  - image = default image will be used (which is set in `REPOSITORY_AVATAR_FALLBACK_IMAGE`)
- `REPOSITORY_AVATAR_FALLBACK_IMAGE`: **_empty_**: Image used as default repository avatar (if `REPOSITORY_AVATAR_FALLBACK` is set to image and none was uploaded). The value is used as-is, without prepending the sub-path of `ROOT_URL`. Empty uses Gitea's builtin repository avatar.
+- `REPOSITORY_AVATAR_FALLBACK_IMAGE`: **/img/repo_default.png**: Image used as default repository avatar (if `REPOSITORY_AVATAR_FALLBACK` is set to image and none was uploaded)

 ## Project (`project`)

@@ -1329,6 +1317,7 @@ These options are written into the gitconfig file under `[git] HOME_PATH` when G

 - `diff.algorithm`: **histogram**
 - `core.logAllRefUpdates`: **true**
+- `gc.reflogExpire`: **90**

 ## Metrics (`metrics`)

@@ -1356,7 +1345,7 @@ These options are written into the gitconfig file under `[git] HOME_PATH` when G
 - `JWT_SECRET_URI`: **_empty_**: Instead of defining JWT_SECRET in the configuration, this configuration option can be used to give Gitea a path to a file that contains the secret (example value: `file:/etc/gitea/oauth2_jwt_secret`)
 - `JWT_SIGNING_PRIVATE_KEY_FILE`: **jwt/private.pem**: Private key file path used to sign OAuth2 tokens. The path is relative to `APP_DATA_PATH`. This setting is only needed if `JWT_SIGNING_ALGORITHM` is set to `RS256`, `RS384`, `RS512`, `ES256`, `ES384` or `ES512`. The file must contain a RSA or ECDSA private key in the PKCS8 format. If no key exists a 4096 bit key will be created for you.
 - `MAX_TOKEN_LENGTH`: **32767**: Maximum length of token/cookie to accept from OAuth2 provider
- `DEFAULT_APPLICATIONS`: **git-credential-oauth, git-credential-manager, gitea-cli, gitea-app, gitea-vscode**: Pre-register OAuth applications for some services on startup. See the [OAuth2 documentation](/development/oauth2-provider.md) for the list of available options. `tea` is accepted as an alias of `gitea-cli`.
+- `DEFAULT_APPLICATIONS`: **git-credential-oauth, git-credential-manager, tea, gitea-app**: Pre-register OAuth applications for some services on startup. See the [OAuth2 documentation](/development/oauth2-provider.md) for the list of available options.
 - `CUSTOM_SCHEMES`: **_empty_**: By default, OAuth2 applications can only use "http" and "https" as their redirect URI schemes.
  If you need to use other schemes (e.g. for desktop applications), you can specify them here as a comma-separated list.
  For example: set "my-scheme, com.example.app" to support "my-scheme://..." and "com.example.app://..." redirect URIs.
@@ -1440,13 +1429,11 @@ in this mapping or the filetype using heuristics.

 - `MAX_ATTEMPTS`: **3**: Max attempts per http/https request on migrations.
 - `RETRY_BACKOFF`: **3**: Backoff time per http/https request retry (seconds)
- `EGRESS_MODE`: **lax**: Mode toggles between strictness of scanning outgoing requests, same format as `EGRESS_MODE` in [`security`](#security-security).
- `ALLOWED_HOST_LIST`: **_empty_**: Hosts migrations and mirrors may call, same format as `ALLOWED_HOST_LIST` in [`security`](#security-security). Private, loopback and link-local addresses need a builtin or CIDR entry. When unset, the deprecated `ALLOWED_DOMAINS` entries apply on every port with `strict` as the default mode, and the deprecated `ALLOW_LOCALNETWORKS` adds `private, loopback`.
- `BLOCKED_HOST_LIST`: **_empty_**: Hosts migrations and mirrors may never call, portless entries cover all ports.
+- `ALLOWED_DOMAINS`: **_empty_**: Domains allowlist for migrating repositories, default is blank. It means external hosts will be allowed. Multiple domains could be separated by commas. Wildcard is supported: `github.com, *.github.com`.
+- `BLOCKED_DOMAINS`: **_empty_**: Domains blocklist for migrating repositories, default is blank. Multiple domains could be separated by commas. When `ALLOWED_DOMAINS` is not blank, this option has a higher priority to deny domains. Wildcard is supported.
+- `ALLOW_LOCALNETWORKS`: **false**: Allow private addresses defined by RFC 1918, RFC 1122, RFC 4632 and RFC 4291. If a domain is allowed by `ALLOWED_DOMAINS`, this option will be ignored.
 - `SKIP_TLS_VERIFY`: **false**: Allow skip tls verify

-These lists are enforced on direct connections only. When a proxy is configured (`[proxy]`, `[git.config]` `http.proxy` or the environment), restricting the proxied target is the proxy server's responsibility.
-
 ## Federation (`federation`)

 - `ENABLED`: **false**: Enable/Disable federation capabilities
@@ -1468,7 +1455,6 @@ These lists are enforced on direct connections only. When a proxy is configured
 - `CHUNKED_UPLOAD_PATH`: **tmp/package-upload**: Path for chunked uploads. Defaults to `APP_DATA_PATH` + `tmp/package-upload`
 - `LIMIT_TOTAL_OWNER_COUNT`: **-1**: Maximum count of package versions a single owner can have (`-1` means no limits)
 - `LIMIT_TOTAL_OWNER_SIZE`: **-1**: Maximum size of packages a single owner can use (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)
- `MAX_DECOMPRESSION_RATIO`: **200**: Maximum inflation ratio while reading an upload's metadata from an archive
 - `LIMIT_SIZE_ALPINE`: **-1**: Maximum size of an Alpine upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)
 - `LIMIT_SIZE_CARGO`: **-1**: Maximum size of a Cargo upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)
 - `LIMIT_SIZE_CHEF`: **-1**: Maximum size of a Chef upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)
@@ -1489,9 +1475,8 @@ These lists are enforced on direct connections only. When a proxy is configured
 - `LIMIT_SIZE_RPM`: **-1**: Maximum size of a RPM upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)
 - `LIMIT_SIZE_RUBYGEMS`: **-1**: Maximum size of a RubyGems upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)
 - `LIMIT_SIZE_SWIFT`: **-1**: Maximum size of a Swift upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)
- `LIMIT_SIZE_TERRAFORM_MODULE`: **-1**: Maximum size of a Terraform module archive upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`). Archives are additionally capped at 32 MiB decompressed.
- `LIMIT_SIZE_TERRAFORM_STATE`: **-1**: Maximum size of a Terraform state upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)
 - `LIMIT_SIZE_VAGRANT`: **-1**: Maximum size of a Vagrant upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)
+- `LIMIT_SIZE_TERRAFORM_STATE``: **-1**: Maximum size of a Terraform state upload (`-1` means no limits, format `1000`, `1 MB`, `1 GiB`)

 ## Mirror (`mirror`)

@@ -1683,16 +1668,14 @@ is `data/repo-archive` and the default of `MINIO_BASE_PATH` is `repo-archive/`.
 ## Proxy (`proxy`)

 - `PROXY_ENABLED`: **false**: Enable the proxy if true, all requests to external via HTTP will be affected, if false, no proxy will be used even environment http_proxy/https_proxy
- `PROXY_URL`: **_empty_**: Proxy server URL, support http://, https://, socks5://, blank will follow environment http_proxy/https_proxy
+- `PROXY_URL`: **_empty_**: Proxy server URL, support http://, https//, socks://, blank will follow environment http_proxy/https_proxy
 - `PROXY_HOSTS`: **_empty_**: Comma separated list of host names requiring proxy. Glob patterns (*) are accepted; use ** to match all hosts.

-When a proxy is configured, Gitea does not enforce the egress lists (`[security]`, `[migrations]`) on the proxied target, the proxy server is expected to restrict it.
-
 i.e.

 ```ini
 PROXY_ENABLED = true
-PROXY_URL = socks5://127.0.0.1:1080
+PROXY_URL = socks://127.0.0.1:1080
 PROXY_HOSTS = *.github.com
 ```

@@ -1710,8 +1693,7 @@ PROXY_HOSTS = *.github.com
  But it will save storage space and network bandwidth, so it's still recommended to use compression.
 - `ARTIFACT_RETENTION_DAYS`: **90**: Days to keep artifacts. Old artifacts will be deleted after this period. 0 means keep forever.
  Changes only apply to newly uploaded artifacts, existing ones keep the expiry stored when they were uploaded.
-  Workflows can request a shorter retention period, down to 1 day.
- `ARTIFACT_PREVIEW_MAX_SIZE`: **10485760**: Maximum total artifact size in bytes that can be browsed or previewed in the web UI. Set to `0` to disable artifact previews or `-1` for no limit. Individual files are also limited by [`MAX_DISPLAY_FILE_SIZE`](#ui-ui).
+  Artifacts could have their own retention periods by setting the `retention-days` option in `actions/upload-artifact` step.
 - `RUN_RETENTION_DAYS`: **400**: Days to keep completed runs. Old runs and everything under them will be deleted after this period. 0 means keep forever.
 - `ZOMBIE_TASK_TIMEOUT`: **10m**: Timeout to stop the task which have running status, but haven't been updated for a long time
 - `ENDLESS_TASK_TIMEOUT`: **3h**: Timeout to stop the tasks which have running status and continuous updates, but don't end for a long time
@@ -1721,9 +1703,18 @@ PROXY_HOSTS = *.github.com
 - `SCOPED_WORKFLOW_DIRS`: **.gitea/scoped_workflows**: Comma-separated list of directories holding [scoped workflows](usage/actions/scoped-workflows.md) (workflows defined in a central source repository that run on other repositories). Must not overlap with `WORKFLOW_DIRS`. Leave empty so no directory is scanned for scoped workflows; none are found or run.
 - `MAX_RERUN_ATTEMPTS`: **50**: Maximum number of attempts a single workflow run can have (initial run + reruns). Defaults value is 50. Set any positive value that fits your workflow needs.

-`DEFAULT_ACTIONS_URL` sets where runners download actions without a host.
-With `github`, `uses: actions/checkout@v4` resolves to `https://github.com/actions/checkout@v4`, with `self` to `<ROOT_URL>/actions/checkout@v4`.
-`self` requires mirroring every action you use to your instance, so prefer naming the host per action instead: `uses: self:owner/repo@ref` for your instance, or a full URL like `uses: https://gitea.com/actions/checkout@v4` for any other host.
+`DEFAULT_ACTIONS_URL` indicates where the Gitea Actions runners should find the actions with relative path.
+For example, `uses: actions/checkout@v4` means `https://github.com/actions/checkout@v4` since the value of `DEFAULT_ACTIONS_URL` is `github`.
+And it can be changed to `self` to make it `root_url_of_your_gitea/actions/checkout@v4`.
+
+Please note that using `self` is not recommended for most cases, as it could make names globally ambiguous.
+Additionally, it requires you to mirror all the actions you need to your Gitea instance, which may not be worth it.
+Therefore, please use `self` only if you understand what you are doing.
+
+In earlier versions (`<= 1.19`), `DEFAULT_ACTIONS_URL` could be set to any custom URLs like `https://gitea.com` or `http://your-git-server,https://gitea.com`, and the default value was `https://gitea.com`.
+However, later updates removed those options, and now the only options are `github` and `self`, with the default value being `github`.
+However, if you want to use actions from other git server, you can use a complete URL in `uses` field, it's supported by Gitea (but not GitHub).
+Like `uses: https://gitea.com/actions/checkout@v4` or `uses: http://your-git-server/actions/checkout@v4`.

 ## Other (`other`)

@@ -16,7 +16,6 @@ aliases:
 4. Make sure `Host` and `X-Forwarded-Proto` headers are correctly passed to Gitea to make Gitea see the real URL being visited.
 5. Make sure your webserver has a certificate, including all intermediate and RootCA certificates, for `git clone` and `git pull` to work.
 6. Gitea uses a WebSocket connection at `/-/ws` for real-time updates like the notification counter. Make sure the reverse-proxy talks HTTP/1.1 and forwards the `Upgrade` and `Connection` headers, see the examples below. Without it, Gitea falls back to periodic polling.
-7. Make sure the reverse-proxy sets the `X-Real-IP` header, otherwise Gitea uses a client-sent value. For example `header_up X-Real-IP {remote_host}` in Caddy's `reverse_proxy`, `RequestHeader set X-Real-IP "expr=%{REMOTE_ADDR}"` in Apache or `http-request set-header X-Real-IP %[src]` in HAProxy. To log the client port, also set `X-Real-Port`, for example `proxy_set_header X-Real-Port $remote_port;` in nginx.

 ### Use a sub-path

@@ -73,7 +73,6 @@ By default, this creates a token with very limited permissions. To complete your

 - `activitypub`
 - `admin`
- `commitstatus` (included in `repository`)
 - `issue`
 - `misc`
 - `notification`
@@ -111,9 +111,6 @@ Gitea token scopes are as follows:
 | **admin** | `/admin/*` API routes: Site-wide administrative operations (hidden for non-admin accounts).                                                          |
 | &nbsp;&nbsp;&nbsp; **read:admin** | Grants read access for admin operations, such as getting cron jobs or registered user emails.                                                        |
 | &nbsp;&nbsp;&nbsp; **write:admin** | Grants read/write/delete access for admin operations, such as running cron jobs or updating user accounts.                                           |
-| **commitstatus** | `/repos/{owner}/{repo}/statuses/{sha}` and `/repos/{owner}/{repo}/commits/{ref}/status(es)` API routes: Commit status operations.                        |
-| &nbsp;&nbsp;&nbsp; **read:commitstatus** | Grants read access to commit statuses. Included in `read:repository`.                                                                                |
-| &nbsp;&nbsp;&nbsp; **write:commitstatus** | Grants read/write access to commit statuses, such as reporting CI results. Included in `write:repository`.                                           |
 | **issue** | `issues/*`, `labels/*`, `milestones/*` API routes: Issue-related operations.                                                                         |
 | &nbsp;&nbsp;&nbsp; **read:issue** | Grants read access for issues operations, such as getting issue comments, issue attachments, and milestones.                                         |
 | &nbsp;&nbsp;&nbsp; **write:issue** | Grants read/write/delete access for issues operations, such as posting or editing an issue comment or attachment, and updating milestones.           |
@@ -144,9 +141,7 @@ Gitea creates OAuth applications for the following services by default on startu
 |-----------|-----------|---------|
 |[git-credential-oauth](https://github.com/hickford/git-credential-oauth)|Git credential helper|`a4792ccc-144e-407e-86c9-5e7d8d9c3269`|
 |[Git Credential Manager](https://github.com/git-ecosystem/git-credential-manager)|Git credential helper|`e90ee53c-94e2-48ac-9358-a874fb9e0662`|
-|[Gitea CLI](https://gitea.com/gitea/cli)|Gitea CLI|`d57cb8c4-630c-4168-8324-ec79935e18d4`|
-|Gitea App|Official Gitea mobile app|`b757811a-05c8-4c76-8d74-a5ee3d2073f2`|
-|[gitea-vscode](https://gitea.com/gitea/gitea-vscode)|VS Code extension|`75a9ec3e-42b5-40cb-9144-9ea96ecd56a6`|
+|[tea](https://gitea.com/gitea/tea)|tea|`d57cb8c4-630c-4168-8324-ec79935e18d4`|

 To prevent unexpected behavior, they are being displayed as locked in the UI and their creation can instead be controlled by the `DEFAULT_APPLICATIONS` parameter in `app.ini`.

@@ -8,7 +8,7 @@ aliases:

 # Database Preparation

-You need a database to use Gitea. Gitea supports PostgreSQL (>= 12), MySQL (>= 8.0), MariaDB (>= 10.4), SQLite (builtin), and MSSQL (>= 2012 SP4). This page will guide into preparing database. PostgreSQL, MySQL and MSSQL are covered here. If you plan to use SQLite, you can ignore this chapter.
+You need a database to use Gitea. Gitea supports PostgreSQL (>= 12), MySQL (>= 8.0), MariaDB (>= 10.4), SQLite (builtin), and MSSQL (>= 2012 SP4). This page will guide into preparing database. Only PostgreSQL and MySQL will be covered here since those database engines are widely-used in production. If you plan to use SQLite, you can ignore this chapter.

 :::warning
 Converting one database type to another is not a well-tested process and you may experience issues. It is better to choose the final database type at the type of the first installation. Be aware that SQLite does not scale; if you expect your instance to grow at a later time, you should choose another database type.
@@ -177,28 +177,6 @@ All steps below requires that the database engine of your choice is installed on

    You should be prompted to enter password for the database user, and connected to the database.

-## MSSQL
-
-1. As an administrator, create the login, a database with case-sensitive collation, and its user. Replace the password `'gitea'` with a secure one:
-
-    ```sql
-    CREATE LOGIN gitea WITH PASSWORD = 'gitea';
-    CREATE DATABASE giteadb COLLATE Latin1_General_CS_AS;
-    GO
-    USE giteadb;
-    CREATE USER gitea FOR LOGIN gitea;
-    ALTER ROLE db_owner ADD MEMBER gitea;
-    GO
-    ```
-
-    Upgrades change the database schema, so the user needs `db_owner`, or `db_ddladmin`, `db_datareader` and `db_datawriter`. With the latter, also run `ALTER DATABASE giteadb SET READ_COMMITTED_SNAPSHOT ON;` as administrator.
-
-2. On your Gitea server, test the connection to the database:
-
-    ```sh
-    sqlcmd -S 203.0.113.3 -U gitea -d giteadb
-    ```
-
 ## Database Connection over TLS

 If the communication between Gitea and your database instance is performed through a private network, or if Gitea and the database are running on the same server, this section can be omitted since the security between Gitea and the database instance is not critically exposed. If instead the database instance is on a public network, use TLS to encrypt the connection to the database, as it is possible for third-parties to intercept the traffic data.
@@ -23,7 +23,7 @@ version is @minNodeVersion@ and the latest LTS version is recommended.
 :::note
 Go version @minGoVersion@ or higher is required. However, it is recommended to
 obtain the same version as our continuous integration, see the advice given in
-[Hacking on Gitea](https://github.com/go-gitea/gitea/blob/main/docs/build-setup.md)
+[Hacking on Gitea](development/hacking-on-gitea.md)
 :::

 ## Download
@@ -73,7 +73,7 @@ To build from source, the following programs must be present on the system:

 - `go` @minGoVersion@ or higher, see [here](https://go.dev/dl/)
 - `node` @minNodeVersion@ or higher with `npm`, see [here](https://nodejs.org/en/download/)
- `make`, see [here](https://github.com/go-gitea/gitea/blob/main/docs/build-setup.md#make)
+- `make`, see [here](development/hacking-on-gitea.md#installing-make)

 Various [make tasks](https://github.com/go-gitea/gitea/blob/main/Makefile)
 are provided to keep the build process as simple as possible.
@@ -0,0 +1,49 @@
+---
+date: "2016-12-01T16:00:00+02:00"
+slug: "install-on-cloud-provider"
+sidebar_position: 90
+aliases:
+  - /en-us/install-on-cloud-provider
+---
+
+# Installation on Cloud Provider
+
+## Cloudron
+
+Gitea is available as a 1-click install on [Cloudron](https://cloudron.io).
+Cloudron makes it easy to run apps like Gitea on your server and keep them up-to-date and secure.
+
+[![Install](/cloudron.svg)](https://cloudron.io/button.html?app=io.gitea.cloudronapp)
+
+The Gitea package is maintained [here](https://git.cloudron.io/cloudron/gitea-app).
+
+There is a [demo instance](https://my.demo.cloudron.io) (username: cloudron password: cloudron) where
+you can experiment with running Gitea.
+
+## Linode
+
+[Linode](https://www.linode.com/) has Gitea as an app in their marketplace.
+
+To deploy Gitea to Linode, have a look at the [Linode Marketplace](https://www.linode.com/marketplace/apps/linode/gitea/).
+
+## alwaysdata
+
+[alwaysdata](https://www.alwaysdata.com/) has Gitea as an app in their marketplace.
+
+To deploy Gitea to alwaysdata, have a look at the [alwaysdata Marketplace](https://www.alwaysdata.com/en/marketplace/gitea/).
+
+## Exoscale
+
+[Exoscale](https://www.exoscale.com/) provides Gitea managed by [Glasskube](https://glasskube.eu/) in their marketplace.
+
+Exoscale is a European cloud service provider.
+
+The package is maintained and update via the open source [Glasskube Kubernetes Operator](https://github.com/glasskube/operator).
+
+To deploy Gitea to Exoscale, have a look at the [Exoscale Marketplace](https://www.exoscale.com/marketplace/listing/glasskube-gitea/).
+
+## Sealos
+
+Gitea is available as a one-click deployment on [Sealos](https://sealos.io/products/app-store/gitea).
+
+The community-maintained template source is available [here](https://github.com/labring-actions/templates/tree/kb-0.9/template/gitea).
@@ -66,7 +66,7 @@ server-1  | 2026-03-11T12:57:50.796198843Z /var/lib/gitea/git is not writable
 server-1  | 2026-03-11T12:57:50.796235667Z docker setup failed
 ```

-For a stable release you could use `:latest-rootless`, `:1-rootless` or specify a certain release like `:@dockerVersion@-rootless`, but if you'd like to use the latest development version then `:main-nightly-rootless` would be an appropriate tag. If you'd like to run the latest commit from a release branch you can use the `:1.x-nightly-rootless` tag, where x is the minor version of Gitea. (e.g. `:1.27-nightly-rootless`)
+For a stable release you could use `:latest-rootless`, `:1-rootless` or specify a certain release like `:@dockerVersion@-rootless`, but if you'd like to use the latest development version then `:nightly-rootless` would be an appropriate tag. If you'd like to run the latest commit from a release branch you can use the `:1.x-nightly-rootless` tag, where x is the minor version of Gitea. (e.g. `:1.16-nightly-rootless`)

 ## Named volumes

@@ -30,7 +30,7 @@ image as a service. Since there is no database available, one can be initialized
 Create a directory like `gitea` and paste the following content into a file named `docker-compose.yml`.
 Note that the volume should be owned by the user/group with the UID/GID specified in the config file.
 If you don't give the volume correct permissions, the container may not start.
-For a stable release you can use `:latest`, `:1` or specify a certain release like `:@dockerVersion@`, but if you'd like to use the latest development version of Gitea then you could use the `:main-nightly` tag. If you'd like to run the latest commit from a release branch you can use the `:1.x-nightly` tag, where x is the minor version of Gitea. (e.g. `:1.27-nightly`)
+For a stable release you can use `:latest`, `:1` or specify a certain release like `:@dockerVersion@`, but if you'd like to use the latest development version of Gitea then you could use the `:nightly` tag. If you'd like to run the latest commit from a release branch you can use the `:1.x-nightly` tag, where x is the minor version of Gitea. (e.g. `:1.16-nightly`)

 ```yaml
 networks:
@@ -191,7 +191,7 @@ services:
 +    networks:
 +      - gitea
 +    volumes:
-+      - ./postgres:/var/lib/postgresql
+      - ./postgres:/var/lib/postgresql/data
 ```

 ## Named volumes
@@ -10,13 +10,13 @@ aliases:

 # Protected branches

-Protected branches prevent unwanted changes by enforcing push, deletion, and merge policies on selected branches. The rules are enforced for every Git protocol (HTTP(S), SSH), the web editor, the API, and background jobs such as auto-merge. Only repository owners and administrators can manage the rules, and the Branches page is read-only while a repository is archived.
+Protected branches prevent unwanted changes by enforcing push and merge policies on selected branches. The rules are enforced for every Git protocol (HTTP(S), SSH), the web editor, the API, and background jobs such as auto-merge. Only repository owners and administrators can manage the rules, and the Branches page is read-only while a repository is archived.

 ## Creating or editing a rule

 1. Open the repository and select **Settings → Branches** (repository admin permission required).
 2. Select **Add new rule** or **Edit** next to an existing rule.
-3. Fill in the **Protected branch name pattern** and optional file patterns, then configure the push, deletion, merge, and review options described below.
+3. Fill in the **Protected branch name pattern** and optional file patterns, then configure the push, merge, and review options described below.
 4. Select **Save rule**.

 The rule immediately applies to all matching branches, even if the branches are created in the future.
@@ -48,9 +48,7 @@ The **Push** section controls direct pushes (including the web editor and API).

 - **Disable push** makes the branch read-only. Any attempt to push directly fails, and changes must be merged through pull requests.
 - **Enable push** allows anyone with [write access](./permissions.md) to push (force pushes are still blocked unless explicitly allowed).
- **Allowlist restricted push** requires being on the allowlist. Choose users and, for organization-owned repositories, teams.
-
-The user allowlists for push, force-push and deletion can include the **Gitea Actions** and **Deploy Key** system users. They still require write access; **Deploy Key** also covers deploy tokens.
+- **Allowlist restricted push** requires being on the allowlist. Choose users and, for organization-owned repositories, teams. Deploy keys that already have write access can also be allowlisted.

 When a push is blocked, the server-side hook rejects the update with an explanation.

@@ -60,17 +58,7 @@ Force pushes have their own set of options:

 - **Disable force push** completely forbids rewriting history on the branch.
 - **Enable force push** allows anyone who can push to also force push.
- **Allowlist restricted force push** limits force pushes to a separate allowlist of users or teams **and** requires regular push access.
-
-## Branch deletion
-
-The **Branch Deletion** section controls whether matching protected branches can be deleted:
-
- **Disable branch deletion** prevents deletion. This is the default.
- **Enable branch deletion** allows anyone who can push to delete the branch.
- **Allowlist restricted branch deletion** limits deletion to a separate allowlist of users or teams **and** requires regular push access.
-
-These rules apply to Git (`git push --delete`), the API, the web interface and post-merge cleanup. The default branch and configured default pull request target branch cannot be deleted.
+- **Allowlist restricted force push** limits force pushes to a separate allowlist (users, teams, and optionally deploy keys) **and** requires the person to already have regular push access.

 ## Pull request merges and approvals

@@ -1,31 +0,0 @@
---
-date: "2026-08-30T00:00:00+02:00"
-slug: "artifacts"
-sidebar_position: 70
---
-
-# Artifacts
-
-Workflow runs can store files such as test results, coverage reports, and build output as artifacts. Artifacts are uploaded by workflows, for example with [`actions/upload-artifact`](https://github.com/actions/upload-artifact), and appear on the run page after the upload completes.
-
-## Previewing artifacts
-
-Select an artifact on the run page to open its file browser and preview in the same tab. The preview identifies the originating run and attempt, and provides links back to that run and to download the complete artifact. Selecting files in the browser updates the preview in the same tab.
-
-Artifact previews:
-
- require sign-in and access to the Actions run to open the preview page
- render text-based files, images (including SVG), and PDFs
- run HTML and JavaScript content in a sandboxed frame
-
-Preview content is loaded through signed URLs that expire after one hour and do not require a session cookie. Reopen the preview page to obtain a fresh URL after it expires.
-
-The file browser lists up to 2,000 files per artifact. Larger artifacts show a notice when the list is truncated.
-
-Unsupported or oversized files can still be downloaded with the complete artifact.
-
-## Instance configuration
-
-Site administrators can limit the total artifact size that can be browsed or previewed with `ARTIFACT_PREVIEW_MAX_SIZE` in the `[actions]` section of `app.ini`. The default is 10 MiB. Set it to `0` to disable previews or `-1` to allow artifacts of any size.
-
-The size of an individual previewed file is also limited by [`MAX_DISPLAY_FILE_SIZE`](../../administration/config-cheat-sheet.md#ui-ui) in the `[ui]` section.
@@ -6,84 +6,104 @@ sidebar_position: 120

 # Compared to GitHub Actions

-Gitea Actions is designed to be compatible with GitHub Actions, with the differences below.
+Even though Gitea Actions is designed to be compatible with GitHub Actions, there are some differences between them.

 ## Additional features

 ### Absolute action URLs

-`uses:` accepts an absolute URL to any git host, e.g. `uses: https://gitea.com/actions/checkout@v4`.
-
-### Action prefixes
-
-`uses:` accepts the `self:` prefix to reference your own Gitea instance, e.g. `uses: self:owner/repo@v1` or `uses: self:owner/repo/.gitea/workflows/build.yml@v1`.
+Gitea Actions supports defining actions via absolute URL, which means that you can use actions from any git repository.
+Like `uses: https://github.com/actions/checkout@v4` or `uses: http://your_gitea.com/owner/repo@branch`.

 ### Actions written in Go

+Gitea Actions supports writing actions in Go.
 See [Creating Go Actions](https://blog.gitea.com/creating-go-actions/).

 ### 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](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule).
+Github Actions doesn't support that. https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule

 ## Unsupported workflows syntax

 ### `jobs.<job_id>.environment`

-[`jobs.<job_id>.environment`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment) is ignored.
+See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idenvironment).
+
+It's ignored by Gitea Actions now.

 ### Complex `runs-on`

-[`runs-on`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on) supports:
+See [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on).

+Gitea Actions 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

 ### 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](https://github.com/go-gitea/gitea/issues/23642#issuecomment-2119876692).
+The `GITEA_TOKEN` for a job running within a repository should be able to publish to the associated package repository (i.e. to upload OCI images). See the "packages" scope for the "default access" in [Automatic token authentication](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication#permissions-for-the-github_token).
+
+This is not implemented in Gitea Actions now. A workaround for Gitea Actions is to use a Personal Access Token (PAT). See this [github issue and comment](https://github.com/go-gitea/gitea/issues/23642#issuecomment-2119876692) for tracking this feature.

 ### Problem Matchers

-[Problem matchers](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md) are ignored.
+Problem Matchers are a way to scan the output of actions for a specified regex pattern and surface that information prominently in the UI.
+See [Problem matchers](https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md).
+
+It's ignored by Gitea Actions now.

 ### Create an error annotation

-[Error annotations](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-creating-an-annotation-for-an-error) are ignored.
+See [Creating an annotation for an error](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#example-creating-an-annotation-for-an-error)
+
+It's ignored by Gitea Actions now.

 ### Expressions

-[Expressions](https://docs.github.com/en/actions/learn-github-actions/expressions) support the standard GitHub functions and contexts.
+For [expressions](https://docs.github.com/en/actions/learn-github-actions/expressions), Gitea Actions supports standard GitHub functions (e.g. `success()`, `failure()`, `always()`, `cancelled()`, `format()`, `toJSON()`) and context variables (like `github`, `matrix`, `vars`, `env`).

 ## Missing UI features

 ### Pre and Post steps

-Pre and post steps have no section of their own in the job log.
+Pre and Post steps don't have their own section in the job log user interface.

 ### Services steps

-Service steps have no section of their own in the job log.
+Services steps don't have their own section in the job log user interface.

 ## Different behavior

 ### 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`, `security-events` and `pages` are not supported, while Gitea adds `code`, `releases`, `wiki` and `projects`. `id-token` works like on GitHub, see [OpenID Connect](openid-connect.md).
+Gitea supports `permissions` and `jobs.<job_id>.permissions` to control the default `GITEA_TOKEN` permissions.
+
+The effective permissions are clamped by the repository/owner settings and are further restricted for fork pull requests and cross-repository access.
+GitHub-only scopes such as `statuses`, `checks`, `deployments`, `id-token`, `security-events`, and `pages` are not supported, while Gitea-specific scopes such as `code`, `releases`, `wiki`, and `projects` are available.
+
 See [Actions job token permissions](token-permissions.md).

 ### 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](../../administration/config-cheat-sheet.md#actions-actions).
-For other sources, see [Absolute action URLs](#absolute-action-urls) and [Action prefixes](#action-prefixes).
+Previously (Pre 1.21.0), `[actions].DEFAULT_ACTIONS_URL` defaulted to `https://gitea.com`.
+We have since restricted this option to only allow two values (`github` and `self`).
+When set to `github`, the new default, Gitea will download non-fully-qualified actions from `https://github.com`.
+For example, if you use `uses: actions/checkout@v4`, it will download the checkout repository from `https://github.com/actions/checkout.git`.
+
+If you want to download an action from another git hoster, you can use an absolute URL, e.g. `uses: https://gitea.com/actions/checkout@v4`.
+
+If your Gitea instance is in an intranet or a restricted area, you can set the URL to `self` to only download actions from your own instance by default.
+Of course, you can still use absolute URLs in workflows.
+
+More details about the `[actions].DEFAULT_ACTIONS_URL` configuration can be found in the [Configuration Cheat Sheet](../../administration/config-cheat-sheet.md#actions-actions)。

 ### Context availability

-[Context availability](https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability) is not checked, so contexts like `env` work in more places.
+Context availability is not checked, so you can use the env context on more places.
+See [Context availability](https://docs.github.com/en/actions/learn-github-actions/contexts#context-availability).
@@ -19,7 +19,7 @@ Additionally, the runner will introduce itself to Gitea and declare what kind of

 Earlier, we mentioned that `runs-on: ubuntu-latest` in a workflow file means that the job will be run on a runner with the `ubuntu-latest` label.
 But how does the runner know to run `ubuntu-latest`? The answer lies in mapping the label to an environment.
-That's why each label of a runner names an environment, like `my_custom_label:docker://centos:7`.
+That's why when you add custom labels during registration, you will need to input some complex content like `my_custom_label:docker://centos:7`.
 This means that the runner can take the job which needs to run on `my_custom_label`, and it will run it via a docker container with the image `centos:7`.

 Docker isn't the only option, though.
@@ -34,6 +34,7 @@ So,
 - `my_custom_label:docker://node:18`: Run jobs labeled with `my_custom_label` using the `node:18` Docker image.
 - `my_custom_label:host`: Run jobs labeled with `my_custom_label` directly on the host.
 - `my_custom_label`: Same as `my_custom_label:host`.
+- `my_custom_label:vm:ubuntu-latest`: (Example only, not implemented) Run jobs labeled with `my_custom_label` using a virtual machine with the `ubuntu-latest` ISO.

 ## Communication protocol

@@ -42,7 +43,7 @@ However, we did not think it was a good idea to have Gitea listen on a new port.
 Instead, we wanted to reuse the HTTP port, which means we needed a protocol that is compatible with HTTP.
 We chose to use gRPC over HTTP.

-The protocol is defined in [actions-proto-def](https://gitea.com/gitea/actions-proto-def), its Go code lives in [actionslib](https://gitea.com/gitea/actionslib).
+We use [actions-proto-def](https://gitea.com/gitea/actions-proto-def) and [actions-proto-go](https://gitea.com/gitea/actions-proto-go) to wire them up.
 More information about gRPC can be found on [its website](https://grpc.io/).

 ## Network architecture
@@ -70,8 +71,7 @@ However, if a job container tries to fetch code from localhost, it will fail bec
 ### Connection 3, runner to internet

 When you use some actions like `actions/checkout@v4`, the runner downloads the scripts, not the job containers.
-By default, it downloads them from [github.com](https://github.com/), which requires internet access.
-With `DEFAULT_ACTIONS_URL` set to `self`, or with `uses: self:owner/repo@ref`, it downloads them from your Gitea instance instead.
+By default, it downloads from [github.com](http://github.com/), so it requires access to the internet. If you configure the `DEFAULT_ACTIONS_URL` to `self`, then it will download from your Gitea instance by default. Then it will not connect to internet when downloading the action itself.
 It also downloads some docker images from Docker Hub by default, which also requires internet access.

 However, internet access is not strictly necessary.
@@ -27,24 +27,50 @@ Still, this is completely optional since both options have the same effect at th

 ## Where will the runner download scripts when using actions such as `actions/checkout@v4`?

-From `https://github.com` by default, or from your own instance when `[actions].DEFAULT_ACTIONS_URL` is `self`, see the [Configuration Cheat Sheet](../../administration/config-cheat-sheet.md#actions-actions).
+There are tens of thousands of [actions scripts](https://github.com/marketplace?type=actions) in GitHub, and when you write `uses: actions/checkout@v4`, it downloads the scripts from [github.com/actions/checkout](http://github.com/actions/checkout) by default.
+But what if you want to use actions from other places such as gitea.com instead of GitHub?

-To use an action from elsewhere, name its host:
+The good news is that you can specify the URL prefix to use actions from anywhere.
+This is an extra syntax in Gitea Actions.
+For example:

- `uses: https://gitea.com/owner/repo@ref`
- `uses: http://your_gitea_instance.com/owner/repo@ref`
- `uses: self:owner/repo@ref` for your own Gitea instance
+- `uses: https://gitea.com/xxx/xxx@xxx`
+- `uses: https://github.com/xxx/xxx@xxx`
+- `uses: http://your_gitea_instance.com/xxx@xxx`
+
+Be careful, the `https://` or `http://` prefix is necessary!
+
+This is one of the differences from GitHub Actions which supports actions scripts only from GitHub.
+But it should allow users much more flexibility in how they run Actions.
+
+Alternatively, if you want your runners to download actions from your own Gitea instance by default, you can configure it by setting `[actions].DEFAULT_ACTIONS_URL`.
+See [Configuration Cheat Sheet](../../administration/config-cheat-sheet.md#actions-actions).

 ## How to limit the permission of the runners?

-Runners only connect to your Gitea instance.
-For each job, a runner gets a `GITEA_TOKEN` limited to the job's repository, see [Actions job token permissions](token-permissions.md).
-To give a job access to more private repositories or external systems, pass it [secrets](usage/actions/secrets.md).
+Runners have no more permissions than simply connecting to your Gitea instance.
+When any runner receives a job to run, it will temporarily gain limited permission to the repository associated with the job.
+If you want to give more permissions to the runner, allowing it to access more private repositories or external systems, you can pass [secrets](usage/actions/secrets.md) to it.
+
+Refined permission control to Actions is a complicated job.
+In the future, we will add more options to Gitea to make it more configurable, such as allowing more write access to repositories or read access to all repositories in the same organization.

 ## Which operating systems are supported by Gitea Runner?

-Official binaries are released for Linux, macOS and Windows.
-Other systems supported by Go and Docker work in theory.
+We released official binaries for Linux, macOS, and Windows.
+While other operating systems are theoretically supported if it is supported by golang and docker(docker mode enabled).
+
+One thing to note is that if you choose to run jobs directly on the host instead of in job containers, the environmental differences between operating systems may cause unexpected failures.
+
+For example, bash is not available on Windows in most cases, while act tries to use bash to run scripts by default.
+Therefore, you need to specify `powershell` as the default shell in your workflow file, see [defaults.run](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun).
+
+
+```yaml
+defaults:
+  run:
+    shell: powershell
+```

 ## How to avoid being hacked?

@@ -73,13 +99,42 @@ It is exciting to be able to reuse them.

 ## What if it runs on multiple labels, such as `runs-on: [label_a, label_b]`?

-The job runs on a runner that has all of the labels, as on [GitHub](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on).
-The runner uses the environment of the first label it has.
+This is valid syntax.
+It means that it should run on runners that have both the `label_a` **and** `label_b` labels, see [Workflow syntax for GitHub Actions](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on).
+Unfortunately, the runner does not work this way until v0.2.11.
+As mentioned, we map labels to environments:
+
+- `ubuntu` → `ubuntu:22.04`
+- `centos` → `centos:8`
+
+But we need to map label groups to environments instead, like so:
+
+- `[ubuntu]` → `ubuntu:22.04`
+- `[with-gpu]` → `linux:with-gpu`
+- `[ubuntu, with-gpu]` → `ubuntu:22.04_with-gpu`
+
+We also need to re-design how tasks are assigned to runners.
+A runner with `ubuntu`, `centos`, or `with-gpu` does not necessarily indicate that it can accept jobs with `[centos, with-gpu]`.
+Therefore, the runner should inform the Gitea instance that it can only accept jobs with `[ubuntu]`, `[centos]`, `[with-gpu]`, and `[ubuntu, with-gpu]`.
+This is not a technical problem, it was just overlooked in the early design.
+See [runtime.go#L65](https://gitea.com/gitea/runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L65).
+
+Currently, the runner attempts to match everyone in the labels and uses the first match it finds.

 ## What is the difference between agent labels and custom labels for a runner?

-Gitea no longer has custom labels.
-A runner declares its labels every time it starts, from its `runner.labels` configuration or the labels given at registration, so change them there and restart the runner.
+![labels](/images/usage/actions/labels.png)
+
+Agent labels are reported to the Gitea instance by the runner during registration.
+Custom labels, on the other hand, are added manually by a Gitea administrator or owners of the organization or repository (depending on the level of the runner).
+
+However, the design here needs improvement, as it currently has some rough edges.
+You can add a custom label such as `centos` to a registered runner, which means the runner will receive jobs with `runs-on: centos`.
+However, the runner may not know which environment to use for this label, resulting in it using a default image or leading to a logical dead end.
+This default may not match user expectations.
+See [runtime.go#L71](https://gitea.com/gitea/runner/src/commit/90b8cc6a7a48f45cc28b5ef9660ebf4061fcb336/runtime/runtime.go#L71).
+
+In the meantime, we suggest that you re-register your runner if you want to change its labels.

 ## Will there be more implementations for Gitea Actions runner?

@@ -122,6 +177,3 @@ For events supported only by GitHub, see GitHub's [documentation](https://docs.g

 Go to the repository's **Settings** > **Actions** > **General** page and add collaborative owners.
 The private repositories of collaborative owners are allowed to access the actions and workflows in the current repository.
-
-To share within the same user or organization, add the private repositories under its **Settings** > **Actions** > **General** > **Cross-Repository Access** instead.
-See [Cross-repository access](token-permissions.md#cross-repository-access).
@@ -1,60 +0,0 @@
---
-date: "2026-08-23T00:00:00+00:00"
-slug: "openid-connect"
-sidebar_position: 40
---
-
-# OpenID Connect
-
-Jobs can request short-lived OpenID Connect (OIDC) tokens to sign in to cloud providers and other services without storing long-lived secrets. The tokens use the GitHub Actions format, so actions like `aws-actions/configure-aws-credentials`, `google-github-actions/auth` and `azure/login` work unchanged.
-
-## Trusting Gitea
-
-Add Gitea as an OIDC identity provider in the service:
-
- Issuer: `<ROOT_URL>/api/actions/oidc`
- Audience: `<ROOT_URL>/<owner>`, unless the workflow requests another one
-
-Then limit which workflows can sign in with a condition on the [`sub` claim](#claims).
-
-Gitea signs the tokens with a key it creates at `<APP_DATA_PATH>/jwt/actions_oidc.pem`. Instances behind a load balancer must share this file.
-
-## Requesting a token
-
-Grant the `id-token` permission to the workflow or job:
-
-```yaml
-permissions:
-  id-token: write
-```
-
-Default permissions never include it, and jobs from fork pull requests never get it. Owners and repositories can disable it with their [maximum token permissions](token-permissions.md#maximum-token-permissions-clamping).
-
-Actions like the ones above request the token themselves. In a script, use `ACTIONS_ID_TOKEN_REQUEST_URL` and `ACTIONS_ID_TOKEN_REQUEST_TOKEN`:
-
-```shell
-curl --fail --silent --show-error \
-  --header "Authorization: Bearer ${ACTIONS_ID_TOKEN_REQUEST_TOKEN}" \
-  "${ACTIONS_ID_TOKEN_REQUEST_URL}&audience=my-service"
-```
-
-The token is in the `value` field of the response and expires after five minutes.
-
-## Claims
-
-The `sub` claim names the owner and repository with their IDs, so a renamed or recreated repository cannot match an existing trust policy:
-
-```text
-repo:<owner>@<owner-id>/<repo>@<repo-id>:ref:<ref>
-repo:<owner>@<owner-id>/<repo>@<repo-id>:pull_request
-```
-
-The `pull_request` event uses the second form, all other events use the first, including `pull_request_target`.
-
-The other claims match GitHub's, like `repository`, `ref`, `sha`, `workflow_ref` and `job_workflow_ref`. The discovery document at `<ROOT_URL>/api/actions/oidc/.well-known/openid-configuration` lists them all.
-
-Differences from GitHub Actions:
-
- There is no `environment` claim.
- Pull request runs use `refs/pull/<index>/head` and its commit, not the merge ref and merge commit.
- `run_number` counts runs per repository, not per workflow.
@@ -40,7 +40,7 @@ However, it is recommended to use Docker to run the jobs, because it is more sec
 Before running a runner, you should first register it to your Gitea instance using the following command:

 ```bash
-gitea-runner register --no-interactive --instance <instance> --token <token>
+./runner register --no-interactive --instance <instance> --token <token>
 ```

 There are two arguments required, `instance` and `token`.
@@ -69,7 +69,7 @@ If this file is missing or corrupted, you can simply remove it and register agai
 Finally, it's time to start the runner:

 ```bash
-gitea-runner daemon
+./runner daemon
 ```

 And you can see the new runner in the management page:
@@ -102,8 +102,8 @@ Only a workflow that runs on an event that posts a commit status (`push`, `pull_

 Scoped workflows can call reusable workflows:

- A **local** reference (`uses: ./...` or `uses: $/...`) resolves against the **source** repository: the repository the calling workflow's content came from, not the consuming repository.
- A **cross-repository** reference (`uses: owner/repo/...@ref` or `uses: self:owner/repo/...@ref`) is resolved with the **consuming repository's** read permission. If it points to a private repository, make sure every consuming repository can read it; otherwise the workflow will fail there.
+- A **local** reference (`uses: ./...`) resolves against the **source** repository: the repository the calling workflow's content came from, not the consuming repository.
+- A **cross-repository** reference (`uses: owner/repo/...@ref`) is resolved with the **consuming repository's** read permission. If it points to a private repository, make sure every consuming repository can read it; otherwise the workflow will fail there.

 A reusable workflow can live under `SCOPED_WORKFLOW_DIRS` (or `WORKFLOW_DIRS`) of the source repository.

@@ -53,14 +53,13 @@ Valid access mode values for each scope are `read`, `write`, and `none`.
 - `wiki`
 - `projects`
 - `packages` (if supported by the target feature)
- `id-token` (`write` allows requesting [OpenID Connect tokens](openid-connect.md), `read` grants nothing)

 If you specify both `contents` and a more granular scope (like `code` or `releases`), the granular scope wins for that unit.

 ### Compatibility notes

 Gitea supports a subset of GitHub Actions permission scopes.
-GitHub-only scopes such as `statuses`, `checks`, `deployments`, `security-events`, and `pages` are not currently supported by Gitea Actions.
+GitHub-only scopes such as `statuses`, `checks`, `deployments`, `id-token`, `security-events`, and `pages` are not currently supported by Gitea Actions.

 Gitea also exposes repository-unit scopes that do not exist as separate scopes in GitHub Actions:

@@ -76,18 +75,15 @@ If neither the workflow nor the job defines `permissions:`, Gitea uses the confi
 - **Permissive**: read and write permissions for most units in the job's repository (backwards-compatible default).
 - **Restricted**: read-only permissions for `code`, `releases`, and `packages` in the job's repository, and no access to other units by default.

-Neither mode includes `id-token`.
-
 ## Maximum token permissions (clamping)

-You can configure a maximum permission per repository unit and for `id-token`.
+You can configure a maximum permission per repository unit.
 The job's effective permissions are computed as:

 `effective = min(requested, maximum)`

 This means workflows can reduce permissions for a job, but cannot exceed your configured maximum.
 If you don't configure a maximum, the maximum defaults to `write` for all scopes.
-Maximums saved before Gitea supported `id-token` deny it until you set it to `write`.

 ## Where to configure

@@ -99,13 +95,9 @@ You can configure defaults and maximums at:

 Note: Repository-level token permission settings are only shown once **Repository Actions** are enabled.

-## Protected branches
-
-Actions job tokens must have code write permission and satisfy [branch protection rules](../access-control/protected-branches.md), including any **Gitea Actions** allowlist requirements.
-
 ## Fork pull requests

-For security reasons, workflows triggered by pull requests from forks are always restricted to read-only permissions for repository contents, regardless of workflow `permissions:` or settings. They also get no OpenID Connect tokens.
+For security reasons, workflows triggered by pull requests from forks are always restricted to read-only permissions for repository contents, regardless of workflow `permissions:` or settings.

 ## Cross-repository access

@@ -9,67 +9,53 @@ sidebar_position: 25
 ## Environment variables

 These environment variables are set automatically in every workflow run and can be accessed directly (e.g. `$CI` in shell scripts).
-A `GITEA_*` name listed with a `GITHUB_*` name holds the same value.

 | Name | Description | Example |
 |---|---|---|
-| `ACT` | Always set to `true`, unless the runner is configured with `runner.set_act_env: false`. | `true` |
 | `CI` | Always set to `true`. | `true` |
-| `GITEA_ACTION`<br/>`GITHUB_ACTION` | The `id` of the current step, or its index when it has none. | `0` |
-| `GITEA_ACTION_PATH`<br/>`GITHUB_ACTION_PATH` | The path where the action is located. Only set in composite actions. | `/var/run/act/actions/***` |
-| `GITEA_ACTION_REF`<br/>`GITHUB_ACTION_REF` | The ref of the action being executed. | `v4` |
-| `GITEA_ACTION_REPOSITORY`<br/>`GITHUB_ACTION_REPOSITORY` | The owner and repository of the action. | `actions/checkout` |
-| `GITEA_ACTIONS`<br/>`GITHUB_ACTIONS` | Always set to `true`. `GITEA_ACTIONS` is useful to distinguish Gitea Actions from other CI systems. | `true` |
-| `GITEA_ACTIONS_RUNNER_VERSION` | The version of the runner executing the workflow. | `v5.2.4` |
-| `GITEA_ACTOR`<br/>`GITHUB_ACTOR` | The username of the user that triggered the workflow. | `alice` |
-| `GITEA_ACTOR_ID`<br/>`GITHUB_ACTOR_ID` | The ID of the user that triggered the workflow. | `1` |
-| `GITEA_API_URL`<br/>`GITHUB_API_URL` | The URL of the REST API. | `https://gitea.example.com/api/v1` |
-| `GITEA_BASE_REF`<br/>`GITHUB_BASE_REF` | The target branch of a pull request. | `main` |
-| `GITEA_DOCKER_WORKSPACE` | The workspace path as the Docker daemon sees it, for bind mounts into containers a job starts, e.g. `${GITEA_DOCKER_WORKSPACE:-.}/data:/app/data` in a compose file. Only set for jobs running in a container. | `/var/lib/docker/volumes/GITEA-ACTIONS-TASK-42-***/_data` |
-| `GITEA_ENV`<br/>`GITHUB_ENV` | Path to the file that sets environment variables for subsequent steps. | `/var/run/act/workflow/envs.txt` |
-| `GITEA_EVENT_NAME`<br/>`GITHUB_EVENT_NAME` | The name of the event that triggered the workflow. | `push` |
-| `GITEA_EVENT_PATH`<br/>`GITHUB_EVENT_PATH` | Path to the file containing the event webhook payload. | `/var/run/act/workflow/event.json` |
-| `GITEA_GRAPHQL_URL`<br/>`GITHUB_GRAPHQL_URL` | Empty in Gitea (GraphQL is not supported). | _(empty)_ |
-| `GITEA_HEAD_REF`<br/>`GITHUB_HEAD_REF` | The source branch of a pull request. | `feature-branch` |
-| `GITEA_JOB`<br/>`GITHUB_JOB` | The `job_id` of the current job. | `build` |
-| `GITEA_OUTPUT`<br/>`GITHUB_OUTPUT` | Path to the file that sets step output parameters. | `/var/run/act/workflow/outputcmd.txt` |
-| `GITEA_PATH`<br/>`GITHUB_PATH` | Path to the file that adds system `PATH` entries for subsequent steps. | `/var/run/act/workflow/pathcmd.txt` |
-| `GITEA_REF`<br/>`GITHUB_REF` | The fully-formed ref that triggered the workflow. | `refs/heads/main` |
-| `GITEA_REF_NAME`<br/>`GITHUB_REF_NAME` | The short ref name. | `main` |
-| `GITEA_REF_PROTECTED`<br/>`GITHUB_REF_PROTECTED` | `true` if branch protections are configured for the ref that triggered the workflow. | `true` |
-| `GITEA_REF_TYPE`<br/>`GITHUB_REF_TYPE` | The type of ref: `branch` or `tag`. | `branch` |
-| `GITEA_REPOSITORY`<br/>`GITHUB_REPOSITORY` | The owner and repository name. | `owner/repo` |
-| `GITEA_REPOSITORY_ID`<br/>`GITHUB_REPOSITORY_ID` | The ID of the repository. | `123` |
-| `GITEA_REPOSITORY_OWNER`<br/>`GITHUB_REPOSITORY_OWNER` | The repository owner's username. | `owner` |
-| `GITEA_REPOSITORY_OWNER_ID`<br/>`GITHUB_REPOSITORY_OWNER_ID` | The ID of the repository owner. | `45` |
-| `GITEA_RETENTION_DAYS`<br/>`GITHUB_RETENTION_DAYS` | The number of days that artifacts are kept, empty when kept forever. | `90` |
-| `GITEA_RUN_ATTEMPT`<br/>`GITHUB_RUN_ATTEMPT` | The attempt number of the workflow run. | `1` |
-| `GITEA_RUN_ID`<br/>`GITHUB_RUN_ID` | A unique number for each workflow run. | `1234` |
-| `GITEA_RUN_NUMBER`<br/>`GITHUB_RUN_NUMBER` | A unique number for each run of a particular workflow. | `42` |
-| `GITEA_SERVER_URL`<br/>`GITHUB_SERVER_URL` | The URL of the Gitea instance. | `https://gitea.example.com` |
-| `GITEA_SHA`<br/>`GITHUB_SHA` | The commit SHA that triggered the workflow. | `a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2` |
-| `GITEA_STATE`<br/>`GITHUB_STATE` | Path to the file that sets step state variables. | `/var/run/act/workflow/statecmd.txt` |
-| `GITEA_STEP_SUMMARY`<br/>`GITHUB_STEP_SUMMARY` | Path to the file for writing job summaries. | `/var/run/act/workflow/step-summary-0.md` |
-| `GITEA_TRIGGERING_ACTOR`<br/>`GITHUB_TRIGGERING_ACTOR` | The username of the user that initiated the workflow run. May differ from `GITEA_ACTOR` on re-runs. | `alice` |
-| `GITEA_WORKFLOW`<br/>`GITHUB_WORKFLOW` | The name of the workflow. | `CI` |
-| `GITEA_WORKFLOW_SHA`<br/>`GITHUB_WORKFLOW_SHA` | The commit SHA of the workflow file. | `a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2` |
-| `GITEA_WORKSPACE`<br/>`GITHUB_WORKSPACE` | The default working directory on the runner. | `/workspace/owner/repo` |
-| `TRACEPARENT` | The W3C trace context of the job's span, so instrumented tools can add spans to the job's trace. Only set when the runner exports traces, see [Monitoring](/runner/monitoring/#opentelemetry). | `00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01` |
-| `TRACESTATE` | Vendor-specific trace data that accompanies `TRACEPARENT`. Only set when the trace carries any. | `rojo=00f067aa0ba902b7` |
+| `GITEA_ACTIONS` | Always set to `true`. Useful to distinguish Gitea Actions from other CI systems. | `true` |
+| `GITEA_ACTIONS_RUNNER_VERSION` | The version of the runner executing the workflow. | `1.0.8` |
+| `GITEA_DOCKER_WORKSPACE` | The workspace path as the Docker daemon sees it, for bind mounts into containers a job starts, e.g. `${GITEA_DOCKER_WORKSPACE:-.}/data:/app/data` in a compose file. Only set for jobs running in a container. | `/var/lib/docker/volumes/GITEA-ACTIONS-TASK-42_***/_data` |
+| `GITEA_ENV`<br/>`GITHUB_ENV` | Path to the file that sets environment variables for subsequent steps. | `/home/runner/work/_temp/_runner_file_commands/set_env_***` |
+| `GITEA_OUTPUT`<br/>`GITHUB_OUTPUT` | Path to the file that sets step output parameters. | `/home/runner/work/_temp/_runner_file_commands/set_output_***` |
+| `GITEA_PATH`<br/>`GITHUB_PATH` | Path to the file that adds system `PATH` entries for subsequent steps. | `/home/runner/work/_temp/_runner_file_commands/add_path_***` |
+| `GITEA_STATE`<br/>`GITHUB_STATE` | Path to the file that sets step state variables. | `/home/runner/work/_temp/_runner_file_commands/save_state_***` |
+| `GITEA_STEP_SUMMARY`<br/>`GITHUB_STEP_SUMMARY` | Path to the file for writing job summaries. | `/home/runner/work/_temp/_runner_file_commands/step_summary_***` |
+| `GITHUB_ACTIONS` | Always set to `true`. | `true` |
+| `GITHUB_ACTION` | The name of the action currently running, or the step `id`. | `__run` |
+| `GITHUB_ACTION_PATH` | The path where the action is located. | `/home/runner/work/_actions/actions/checkout/v4` |
+| `GITHUB_ACTION_REF` | The ref of the action being executed. | `v4` |
+| `GITHUB_ACTION_REPOSITORY` | The owner and repository of the action. | `actions/checkout` |
+| `GITHUB_ACTOR` | The username of the user that triggered the workflow. | `silverwind` |
+| `GITHUB_API_URL` | The URL of the REST API. | `https://gitea.com/api/v1` |
+| `GITHUB_BASE_REF` | The target branch of a pull request. | `main` |
+| `GITHUB_EVENT_NAME` | The name of the event that triggered the workflow. | `push` |
+| `GITHUB_EVENT_PATH` | Path to the file containing the event webhook payload. | `/home/runner/work/_temp/_github_workflow/event.json` |
+| `GITHUB_GRAPHQL_URL` | Empty in Gitea (GraphQL is not supported). | _(empty)_ |
+| `GITHUB_HEAD_REF` | The source branch of a pull request. | `feature-branch` |
+| `GITHUB_JOB` | The `job_id` of the current job. | `build` |
+| `GITHUB_REF` | The fully-formed ref that triggered the workflow. | `refs/heads/main` |
+| `GITHUB_REF_NAME` | The short ref name. | `main` |
+| `GITHUB_REF_TYPE` | The type of ref: `branch` or `tag`. | `branch` |
+| `GITHUB_REPOSITORY` | The owner and repository name. | `gitea/docs` |
+| `GITHUB_REPOSITORY_OWNER` | The repository owner's username. | `gitea` |
+| `GITHUB_RETENTION_DAYS` | The number of days that workflow run logs and artifacts are kept. | `90` |
+| `GITHUB_RUN_ATTEMPT` | The attempt number of the workflow run. | `1` |
+| `GITHUB_RUN_ID` | A unique number for each workflow run. | `1234` |
+| `GITHUB_RUN_NUMBER` | A unique number for each run of a particular workflow. | `42` |
+| `GITHUB_SERVER_URL` | The URL of the Gitea instance. | `https://gitea.com` |
+| `GITHUB_SHA` | The commit SHA that triggered the workflow. | `a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2` |
+| `GITHUB_WORKFLOW` | The name of the workflow. | `CI` |
+| `GITHUB_WORKSPACE` | The default working directory on the runner. | `/workspace/gitea/docs` |

 ### Runner environment variables

 | Name | Description | Example |
 |---|---|---|
-| `ImageOS` | The OS and release of the job's image, read by `setup-*` actions. | `ubuntu24` |
 | `RUNNER_ARCH` | The architecture of the runner. | `X64` |
-| `RUNNER_DEBUG` | Set to `1` when the `ACTIONS_STEP_DEBUG` secret is `true`, unset otherwise. | `1` |
-| `RUNNER_ENVIRONMENT` | Always set to `self-hosted`. | `self-hosted` |
-| `RUNNER_NAME` | The name of the runner executing the job. | `my-runner` |
 | `RUNNER_OS` | The operating system of the runner. | `Linux` |
 | `RUNNER_TEMP` | Path to a temporary directory on the runner. | `/tmp` |
 | `RUNNER_TOOL_CACHE` | Path to the tool cache directory on the runner. | `/opt/hostedtoolcache` |
-| `RUNNER_WORKSPACE` | The parent directory of `GITEA_WORKSPACE`. | `/workspace/owner` |

 ### Internal environment variables

@@ -78,11 +64,11 @@ These are used internally by the runner and actions. They are typically not need
 | Name | Description | Example |
 |---|---|---|
 | `ACTIONS_CACHE_URL` | URL for the actions cache service. | `http://192.168.1.10:8088/` |
-| `ACTIONS_ID_TOKEN_REQUEST_TOKEN` | Token for OIDC requests. Only set when `id-token: write` is granted. | `***` |
-| `ACTIONS_ID_TOKEN_REQUEST_URL` | URL to request OIDC tokens. Only set when `id-token: write` is granted. | `https://gitea.example.com/api/actions/oidc/token?` |
-| `ACTIONS_RESULTS_URL` | URL for storing artifacts. | `https://gitea.example.com` |
+| `ACTIONS_ID_TOKEN_REQUEST_TOKEN` | Token for OIDC requests. Only set when configured. | `***` |
+| `ACTIONS_ID_TOKEN_REQUEST_URL` | URL to request OIDC tokens. Only set when configured. | `https://gitea.com/login/oauth/access_token` |
+| `ACTIONS_RESULTS_URL` | URL for storing artifacts. | `https://gitea.com` |
 | `ACTIONS_RUNTIME_TOKEN` | Authentication token for the Actions pipeline API. | `***` |
-| `ACTIONS_RUNTIME_URL` | URL for the Gitea Actions pipeline API. | `https://gitea.example.com/api/actions_pipeline/` |
+| `ACTIONS_RUNTIME_URL` | URL for the Gitea Actions pipeline API. | `https://gitea.com/api/actions_pipeline/` |

 ## Context variables

@@ -90,39 +76,39 @@ These variables are available in workflow expressions via `${{ gitea.<name> }}`.

 | Name | Description | Example |
 |---|---|---|
-| `gitea.action`<br/>`github.action` | The `id` of the current step, or its index when it has none. | `0` |
-| `gitea.action_path`<br/>`github.action_path` | The path where an action is located. Only supported in composite actions. | `/var/run/act/actions/***` |
+| `gitea.action`<br/>`github.action` | The name of the action currently running, or the `id` of a step. | `__run` |
+| `gitea.action_path`<br/>`github.action_path` | The path where an action is located. Only supported in composite actions. | `/home/runner/work/_actions/actions/checkout/v4` |
 | `gitea.action_ref`<br/>`github.action_ref` | The ref of the action being executed. | `v4` |
 | `gitea.action_repository`<br/>`github.action_repository` | The owner and repository name of the action. | `actions/checkout` |
 | `gitea.action_status`<br/>`github.action_status` | The current result of a composite action. | `success` |
-| `gitea.actor`<br/>`github.actor` | The username of the user that triggered the initial workflow run. | `alice` |
-| `gitea.api_url`<br/>`github.api_url` | The URL of the REST API. | `https://gitea.example.com/api/v1` |
+| `gitea.actor`<br/>`github.actor` | The username of the user that triggered the initial workflow run. | `silverwind` |
+| `gitea.api_url`<br/>`github.api_url` | The URL of the REST API. | `https://gitea.com/api/v1` |
 | `gitea.base_ref`<br/>`github.base_ref` | The target branch of a pull request. Only set for `pull_request` and `pull_request_target` events. | `main` |
-| `gitea.env`<br/>`github.env` | Path on the runner to the file that sets environment variables from workflow commands. | `/var/run/act/workflow/envs.txt` |
+| `gitea.env`<br/>`github.env` | Path on the runner to the file that sets environment variables from workflow commands. Unique to each step. | `/home/runner/work/_temp/_runner_file_commands/set_env_***` |
 | `gitea.event`<br/>`github.event` | The full event webhook payload as an object. See [Event payload](#event-payload). | `{...}` |
 | `gitea.event_name`<br/>`github.event_name` | The name of the event that triggered the workflow run. | `push` |
-| `gitea.event_path`<br/>`github.event_path` | Path on the runner to the file containing the full event webhook payload. | `/var/run/act/workflow/event.json` |
+| `gitea.event_path`<br/>`github.event_path` | Path on the runner to the file containing the full event webhook payload. | `/home/runner/work/_temp/_github_workflow/event.json` |
 | `gitea.head_ref`<br/>`github.head_ref` | The source branch of a pull request. Only set for `pull_request` and `pull_request_target` events. | `feature-branch` |
 | `gitea.job`<br/>`github.job` | The `job_id` of the current job. | `build` |
 | `gitea.ref`<br/>`github.ref` | The fully-formed ref that triggered the workflow. | `refs/heads/main` |
 | `gitea.ref_name`<br/>`github.ref_name` | The short ref name. | `main` |
 | `gitea.ref_protected`<br/>`github.ref_protected` | `true` if branch protections are configured for the ref that triggered the workflow run. | `true` |
 | `gitea.ref_type`<br/>`github.ref_type` | The type of ref: `branch` or `tag`. | `branch` |
-| `gitea.path`<br/>`github.path` | Path on the runner to the file that sets system `PATH` variables from workflow commands. | `/var/run/act/workflow/pathcmd.txt` |
-| `gitea.repository`<br/>`github.repository` | The owner and repository name. | `owner/repo` |
-| `gitea.repository_owner`<br/>`github.repository_owner` | The repository owner's username. | `owner` |
-| `gitea.repositoryUrl`<br/>`github.repositoryUrl` | The HTML URL to the repository. | `https://gitea.example.com/owner/repo` |
-| `gitea.retention_days`<br/>`github.retention_days` | The number of days that artifacts are kept, empty when kept forever. | `90` |
+| `gitea.path`<br/>`github.path` | Path on the runner to the file that sets system `PATH` variables from workflow commands. Unique to each step. | `/home/runner/work/_temp/_runner_file_commands/add_path_***` |
+| `gitea.repository`<br/>`github.repository` | The owner and repository name. | `gitea/docs` |
+| `gitea.repository_owner`<br/>`github.repository_owner` | The repository owner's username. | `gitea` |
+| `gitea.repositoryUrl`<br/>`github.repositoryUrl` | The HTML URL to the repository. | `https://gitea.com/gitea/docs` |
+| `gitea.retention_days`<br/>`github.retention_days` | The number of days that workflow run logs and artifacts are kept. | `90` |
 | `gitea.run_id`<br/>`github.run_id` | A unique number for each workflow run within a repository. Does not change on re-run. | `1234` |
 | `gitea.run_number`<br/>`github.run_number` | A unique number for each run of a particular workflow. Starts at 1 and increments with each new run. | `42` |
 | `gitea.run_attempt`<br/>`github.run_attempt` | A unique number for each re-run attempt. Starts at 1 and increments with each re-run. | `1` |
 | `gitea.secret_source`<br/>`github.secret_source` | The source of a secret used in a workflow. Always `Actions` in Gitea. | `Actions` |
-| `gitea.server_url`<br/>`github.server_url` | The URL of the Gitea instance. | `https://gitea.example.com` |
+| `gitea.server_url`<br/>`github.server_url` | The URL of the Gitea instance. | `https://gitea.com` |
 | `gitea.sha`<br/>`github.sha` | The commit SHA that triggered the workflow. | `a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2` |
-| `gitea.token`<br/>`github.token` | A token to authenticate on behalf of the Gitea App installed on the repository. See [Token permissions](token-permissions.md). | `***` |
-| `gitea.triggering_actor`<br/>`github.triggering_actor` | The username of the user that initiated the workflow run. May differ from `actor` on re-runs. | `alice` |
+| `gitea.token`<br/>`github.token` | A token to authenticate on behalf of the Gitea App installed on the repository. See [Token permissions](token-permissions.md). | `ghs_***` |
+| `gitea.triggering_actor`<br/>`github.triggering_actor` | The username of the user that initiated the workflow run. May differ from `actor` on re-runs. | `silverwind` |
 | `gitea.workflow`<br/>`github.workflow` | The name of the workflow. If unnamed, the full path of the workflow file. | `CI` |
-| `gitea.workspace`<br/>`github.workspace` | The default working directory on the runner and the default location of your repository when using the `checkout` action. | `/workspace/owner/repo` |
+| `gitea.workspace`<br/>`github.workspace` | The default working directory on the runner and the default location of your repository when using the `checkout` action. | `/workspace/gitea/docs` |
 | `gitea.gitea_default_actions_url` | The default URL for downloading actions. Gitea-specific. | `https://github.com` |

 ### Event payload
@@ -138,11 +124,11 @@ These fields exist in almost every payload:
 | Name | Description | Example |
 |---|---|---|
 | `gitea.event.action` | The activity type. Only set for events that have activity types, see [supported events](faq.md#what-workflow-trigger-events-does-gitea-support). | `opened` |
-| `gitea.event.repository.full_name` | The owner and name of the repository. | `owner/repo` |
+| `gitea.event.repository.full_name` | The owner and name of the repository. | `gitea/docs` |
 | `gitea.event.repository.default_branch` | The default branch of the repository. | `main` |
 | `gitea.event.repository.private` | Whether the repository is private. | `false` |
-| `gitea.event.repository.html_url` | The HTML URL of the repository. | `https://gitea.example.com/owner/repo` |
-| `gitea.event.sender.login` | The username of the user that triggered the event. Also available as `sender.username`. | `alice` |
+| `gitea.event.repository.html_url` | The HTML URL of the repository. | `https://gitea.com/gitea/docs` |
+| `gitea.event.sender.login` | The username of the user that triggered the event. Also available as `sender.username`. | `silverwind` |

 The remaining fields are specific to one or a few events:

@@ -157,12 +143,12 @@ The remaining fields are specific to one or a few events:
 | `gitea.event.commits` | `push` | The commits contained in the push, each with `id`, `message`, `url`, `author`, `added`, `removed` and `modified`. | `[{...}]` |
 | `gitea.event.head_commit.message` | `push` | The message of the most recent commit of the push. | `fix: broken link` |
 | `gitea.event.total_commits` | `push` | The number of commits in the push. Gitea-specific. | `3` |
-| `gitea.event.compare_url` | `push` | The URL comparing `before` with `after`. GitHub names this field `compare`. | `https://gitea.example.com/owner/repo/compare/a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2...f6e5d4c3b2a1f6e5d4c3b2a1f6e5d4c3b2a1f6e5` |
-| `gitea.event.pusher.login` | `push` | The username of the user that pushed. | `alice` |
-| `gitea.event.forkee.full_name` | `fork` | The owner and name of the new fork. | `alice/repo` |
+| `gitea.event.compare_url` | `push` | The URL comparing `before` with `after`. GitHub names this field `compare`. | `https://gitea.com/gitea/docs/compare/a1b2c3d...e5f6a1b` |
+| `gitea.event.pusher.login` | `push` | The username of the user that pushed. | `silverwind` |
+| `gitea.event.forkee.full_name` | `fork` | The owner and name of the new fork. | `silverwind/docs` |
 | `gitea.event.page` | `gollum` | The name of the wiki page. | `Home` |
 | `gitea.event.number` | `issues`, `pull_request`, `pull_request_target`, `pull_request_review`, `pull_request_review_comment` | The index of the issue or pull request. Not set for `issue_comment`, use `gitea.event.issue.number` there. | `386` |
-| `gitea.event.issue.number`<br/>`gitea.event.issue.title`<br/>`gitea.event.issue.body`<br/>`gitea.event.issue.state`<br/>`gitea.event.issue.labels`<br/>`gitea.event.issue.user.login` | `issues`, `issue_comment` | The issue the event happened on. | `Fix typo in README` |
+| `gitea.event.issue.number`<br/>`gitea.event.issue.title`<br/>`gitea.event.issue.body`<br/>`gitea.event.issue.state`<br/>`gitea.event.issue.labels`<br/>`gitea.event.issue.user.login` | `issues`, `issue_comment` | The issue the event happened on. | `Expand gitea.event in actions docs` |
 | `gitea.event.comment.body` | `issue_comment` | The body of the comment. | `LGTM` |
 | `gitea.event.is_pull` | `issue_comment` | Whether the comment was made on a pull request. Gitea-specific, GitHub sets `issue.pull_request` on the issue object instead. | `true` |
 | `gitea.event.pull_request.number`<br/>`gitea.event.pull_request.title`<br/>`gitea.event.pull_request.body`<br/>`gitea.event.pull_request.draft`<br/>`gitea.event.pull_request.merged`<br/>`gitea.event.pull_request.state`<br/>`gitea.event.pull_request.labels`<br/>`gitea.event.pull_request.user.login` | `pull_request`, `pull_request_target`, `pull_request_review`, `pull_request_review_comment` | The pull request the event happened on. | `Add caching to CI` |
@@ -15,7 +15,7 @@ creating issues and pull requests. This will cut down on the initial back and fo
 of getting some clarifying details.
 It is currently not possible to provide generic issue/pull-request templates globally.

-Additionally, the New Issue page URL can be suffixed with `?title=Issue+Title&body=Issue+Text` and the form will be populated with those strings. Those strings will be used instead of the template if there is one. See [Pre-filling Issues and Pull Requests](prefill-issues-pull-requests.md) for all parameters.
+Additionally, the New Issue page URL can be suffixed with `?title=Issue+Title&body=Issue+Text` and the form will be populated with those strings. Those strings will be used instead of the template if there is one.

 ## File names

@@ -1,42 +0,0 @@
---
-date: "2026-10-17T00:00:00+00:00"
-slug: "prefill-issues-pull-requests"
-sidebar_position: 14
---
-
-# Pre-filling Issues and Pull Requests
-
-Links to the pages for creating issues and pull requests can pre-fill the form with query parameters.
-This lets you link users from another app, a README or a project board to a form that is already categorized.
-
- New issue: `/{owner}/{repo}/issues/new?…`
- New pull request: `/{owner}/{repo}/compare/{base}...{head}?…`
-
-For example, this link opens a new issue with a title, two labels and an assignee:
-
-```
-https://gitea.example.com/owner/repo/issues/new?title=Dashboard+crashes&label=kind/bug,area/dashboard&assignee=alice
-```
-
-## Parameters
-
-| Parameter     | Value                                                                       |
-| ------------- | --------------------------------------------------------------------------- |
-| `title`       | Title                                                                       |
-| `body`        | Description                                                                 |
-| `label`       | Comma-separated label IDs or names                                          |
-| `labels`      | Alias of `label`                                                            |
-| `milestone`   | Milestone ID or name                                                        |
-| `project`     | Comma-separated project IDs or titles                                       |
-| `assignee`    | Comma-separated user IDs or usernames                                       |
-| `template`    | File name of the [template](issue-pull-request-templates.md) to use         |
-| `field:<id>`  | Value of the field with this `id` in a YAML template                        |
-
-IDs and names can be mixed and names are matched case-insensitively. Values that don't match anything in the repository are ignored.
-Labels include the organization's labels, and closed milestones and projects can be selected too.
-Milestones and projects are only offered to users who can write to issues or pull requests, so for other users these parameters have no effect.
-
-The values from the link take precedence over the title, description, labels and assignees of the template.
-
-When there are several issue templates to choose from, the parameters are passed through to the chosen one.
-On the compare page, any of these parameters also opens the pull request form directly, as `expand=1` does.
@@ -36,7 +36,6 @@ The following package managers are currently supported:
 | [RubyGems](usage/packages/rubygems.md) | Ruby | `gem`, `Bundler` |
 | [Swift](usage/packages/swift.md) | Swift | `swift` |
 | [Terraform](usage/packages/terraform.md) | - | `terraform` |
-| [Terraform Module](usage/packages/terraform-module.md) | - | `terraform`, `terragrunt` |
 | [Vagrant](usage/packages/vagrant.md) | - | `vagrant` |

 **The following paragraphs only apply if Packages are not globally disabled!**
@@ -56,11 +55,11 @@ and shows a link to the repository on the package site (as well as a link to the
 | Package owner type | User | Organization |
 |--------------------|------|--------------|
 | **read** access    | public, if user is public too; otherwise for this user only | public, if org is public, otherwise for org members only |
-| **write** access   | owner only | members of a team with write access to packages |
+| **write** access   | owner only | org members with admin or write access to the org |

 Please note, that your respective package manager needs to have a [personal access token](development/api-usage.md#authentication) with the permissions `package` set to either Read or Read & Write to download and publish packages respectively.

-The packages permission of an organization team applies to all packages of the organization, regardless of the repositories assigned to the team.
+N.B.: These access restrictions are [subject to change](https://github.com/go-gitea/gitea/issues/19270), where more finegrained control will be added via a dedicated organization team permission.

 ## Create or upload a package

@@ -1,170 +0,0 @@
---
-date: "2026-06-09T00:00:00+00:00"
-slug: "terraform-module"
-sidebar_position: 119
---
-
-# Terraform Module Registry
-
-Publish [Terraform](https://www.terraform.io/) modules for your user or organization and use them
-from Terraform or Terragrunt. The registry implements the
-[HashiCorp module registry protocol](https://developer.hashicorp.com/terraform/internals/module-registry-protocol),
-so modules are referenced with the usual `HOST/NAMESPACE/NAME/PROVIDER` address.
-
-## Requirements
-
- The [Terraform CLI](https://developer.hashicorp.com/terraform/install) or
-  [Terragrunt](https://terragrunt.gruntwork.io/).
- **Your Gitea instance must be served over HTTPS with a valid certificate.**
-  Terraform and Terragrunt only perform module registry discovery over HTTPS and reject
-  plain HTTP — including `http://localhost`. This is a requirement of the protocol, not of Gitea.
-
-A module is addressed by three segments:
-
-| Segment     | Meaning                                                        |
-| ----------- | ------------------------------------------------------------- |
-| `namespace` | The owner of the module: a Gitea user or organization name. It must follow the same rules as `name`, so owners with a `.` in their name cannot publish modules. |
-| `name`      | The module name. Letters, digits, `-` and `_`, starting and ending with a letter or digit, up to 64 characters. |
-| `provider`  | The main provider the module targets, e.g. `aws`. Lowercase letters and digits, up to 64 characters. |
-
-Versions follow [semantic versioning](https://semver.org/) and are stored in canonical form: a
-leading `v` is dropped and missing segments are padded, so `v1.2.3` and `1.2.3` address the same
-version, and `1.2` becomes `1.2.0`.
-
-## Packaging a module
-
-A module is published as a single `.tar.gz` archive, stored and served exactly as uploaded. The
-module's `.tf` files must therefore be at the **archive root**. A source tarball downloaded from a Git
-host wraps everything in a `repository-version/` directory and is rejected — repackage the module
-directory's contents instead:
-
-```shell
-tar -czf vpc-1.0.0.tar.gz -C path/to/module .
-```
-
-The root module's inputs, outputs, providers and `README` are shown on the package page. Each
-submodule found under `modules/<name>` is listed with its source address and links to its own page,
-which shows the install snippet for that submodule along with its inputs, outputs, providers and
-`README`. Only one level is indexed, so `modules/<name>/<nested>` is not listed. Anything else,
-including `examples/`, is kept in the archive but is not indexed. A module that is only a collection of
-submodules, with no root module, is also accepted. Files in JSON syntax (`.tf.json`) are accepted too,
-but only `.tf` files are indexed.
-
-## Authentication
-
-Create a [personal access token](development/api-usage.md#authentication) with the `read:package` scope to download
-private modules, and `write:package` to publish or delete them. Add it to your Terraform CLI
-configuration file (`~/.terraformrc` or `%APPDATA%/terraform.rc`):
-
-```hcl
-credentials "gitea.example.com" {
-  token = "<your token>"
-}
-```
-
-Modules owned by a public user or organization can be downloaded without a token.
-
-## Publishing a module
-
-Upload an archive with a `PUT` request, sending the file as the raw request body. Use
-`curl --upload-file` rather than `--data-binary`: the latter sends a form content type that
-the registry will not accept as an archive.
-
-```shell
-curl --user "your_username:your_token" \
-  --upload-file vpc-1.0.0.tar.gz \
-  https://gitea.example.com/api/packages/-/terraform/modules/{namespace}/{name}/{provider}/{version}
-```
-
-| Parameter   | Description                            |
-| ----------- | -------------------------------------- |
-| `namespace` | The owner (user or organization).      |
-| `name`      | The module name.                       |
-| `provider`  | The provider the module targets.       |
-| `version`   | The module version (semver).           |
-
-For example, to publish version `1.0.0` of the `vpc` module for the `aws` provider under the `acme`
-organization:
-
-```shell
-curl --user "your_username:your_token" \
-  --upload-file vpc-1.0.0.tar.gz \
-  https://gitea.example.com/api/packages/-/terraform/modules/acme/vpc/aws/1.0.0
-```
-
-A successful upload returns `201 Created`. Published versions are immutable: uploading a version that
-already exists returns `409 Conflict`. To replace a version, delete it first.
-
-## Linking a module to a repository
-
-A module always lives in a user or organization's package space — its namespace is that user or
-organization, never a repository, because the registry address (`HOST/NAMESPACE/NAME/PROVIDER`) has no
-repository segment. You cannot publish "into" a repository. Instead, a repository link is a display
-association that surfaces the module on a repository's **Packages** tab. The workflow is:
-
-1. **Publish** the module to the user or organization namespace, exactly as shown in
-   [Publishing a module](#publishing-a-module).
-2. **Link** the package to a repository owned by that same user or organization: open the package,
-   go to its **Settings**, and select the repository (or use the
-   `POST /api/v1/packages/{owner}/terraform-module/{name}%2F{provider}/-/link/{repo}` API).
-
-The link applies to the whole module — all of its versions, including ones published later — and can
-be changed or removed at any time. It only affects where the module is listed in the UI; the address
-used to consume it is unchanged (still `HOST/NAMESPACE/NAME/PROVIDER`, with no repository in it).
-
-## Consuming a module
-
-Reference the module by its registry address. With Terraform:
-
-```hcl
-module "vpc" {
-  source  = "gitea.example.com/acme/vpc/aws"
-  version = "~> 1.0"
-}
-```
-
-To use a submodule, append its path with the standard `//` separator:
-
-```hcl
-module "network" {
-  source  = "gitea.example.com/acme/infra/google//modules/network"
-  version = "~> 1.0"
-}
-```
-
-With Terragrunt, use the `tfr://` scheme and pass the version as a query parameter:
-
-```hcl
-terraform {
-  source = "tfr://gitea.example.com/acme/vpc/aws?version=1.0.0"
-}
-```
-
-`terraform init` (or `terragrunt init`) resolves the address through the service discovery document
-at `https://gitea.example.com/.well-known/terraform.json` and downloads the matching version.
-
-## Deleting a version
-
-```shell
-curl --user "your_username:your_token" \
-  --request DELETE \
-  https://gitea.example.com/api/packages/-/terraform/modules/acme/vpc/aws/1.0.0
-```
-
-A successful delete returns `204 No Content`. This requires the `write:package` scope. There is no
-separate deprecation flow — deleting a version removes it from the registry.
-
-## Limits
-
-The stored archive is bounded by the instance-wide package limits (`LIMIT_SIZE_TERRAFORM_MODULE` and
-`LIMIT_TOTAL_OWNER_SIZE`) set by your Gitea administrator; see the
-[configuration cheat sheet](../../administration/config-cheat-sheet.md#packages-packages).
-
-Independently of those settings, an archive may not exceed **32 MiB decompressed**. The registry
-reads the whole archive to index it, and stops with `413 Request Entity Too Large` past that ceiling,
-so raising `LIMIT_SIZE_TERRAFORM_MODULE` above 32 MiB does not allow larger modules. Real modules are
-kilobyte-scale, so this only affects archives carrying unrelated payloads.
-
-A `README` larger than **1 MiB**, of the root module or of a submodule, is not shown on the package
-page. The module is still accepted and the file stays in the archive.
-
@@ -1,9 +0,0 @@
-{
-  "label": "Projects",
-  "position": 60,
-  "link": {
-    "type": "generated-index",
-    "slug": "/usage/projects",
-    "description": "Plan and track work with project boards"
-  }
-}
@@ -1,82 +0,0 @@
---
-date: "2025-11-25T18:58:22Z"
-slug: "project-workflows"
-sidebar_position: 1
-description: "Automate project boards with event-driven filters and actions."
---
-
-# Project Workflows
-
-Project workflows automate a project board. When an issue or pull request in the project triggers an event, each enabled workflow for that event checks its filters and applies its actions. Workflows run in Gitea and need no runner.
-
-## Edit workflows
-
-1. Open a project and select **Workflows**.
-2. Select an event in the sidebar.
-3. Set filters and actions, then select **Save**. To change an existing workflow, select **Edit** first.
-
-An event can have several workflows. **Clone** copies the selected workflow so you can adapt it to other items. **Disable** pauses a workflow and keeps its configuration. **Remove** deletes it.
-
-## Events
-
-| Event | Runs when | Filters | Actions |
-| --- | --- | --- | --- |
-| Item added to project | An item is added to the project or created in it | Apply to, labels | Move to column, labels, issue state |
-| Item removed from project | An item is removed from the project | Apply to, labels | Labels, issue state |
-| Item reopened | An item is reopened | Apply to, labels | Move to column, labels |
-| Item closed | An item is closed | Apply to, labels | Move to column, labels |
-| Item column changed | An item moves to another column | Apply to, columns, labels | Labels, issue state |
-| Code changes requested | An official reviewer requests changes on a pull request | Labels | Move to column, labels |
-| Code review approved | An official reviewer approves a pull request | Labels | Move to column, labels |
-| Pull request merged | A pull request is merged | Labels | Move to column, labels |
-
-## Filters
-
-A workflow without filters runs for every item.
-
- **Apply to**: issues, pull requests, or both.
- **When moved from column**, **When moved to column**: the column the item left or entered.
- **Only if it has labels**: the item must have all selected labels.
-
-## Actions
-
-A workflow needs at least one action. Actions run in this order:
-
-1. **Move to column**: moves the item to a column.
-2. **Add labels**, **Remove labels**: changes the item's labels.
-3. **Issue state**: closes or reopens the item. Workflows never reopen pull requests.
-
-Workflow changes appear in the timeline as "Project workflow" followed by the event, and don't trigger other workflows. Workflows don't run in closed projects or for items in archived repositories.
-
-## Permissions
-
-Anyone who can read a project can view its workflows. Managing them requires write access to the project and:
-
- Repository project: write access to the repository's issues and pull requests.
- Organization project: organization owner or site administrator.
- User project: the project's owner.
-
-Access tokens limited to public repositories can't manage workflows for organization or user projects. Workflows apply their actions regardless of who triggered the event.
-
-## API
-
-Manage workflows under the project routes of a repository (`/repos/{owner}/{repo}/projects/{id}`), an organization (`/orgs/{org}/projects/{id}`) or the authenticated user (`/user/projects/{id}`):
-
-| Method | Path | Purpose |
-| --- | --- | --- |
-| `GET` | `.../workflows` | List workflows |
-| `GET` | `.../workflows/{workflow_id}` | Get a workflow |
-| `POST` | `.../workflows` | Create a workflow |
-| `PATCH` | `.../workflows/{workflow_id}` | Edit a workflow, omitted fields stay unchanged |
-| `DELETE` | `.../workflows/{workflow_id}` | Delete a workflow |
-
-A workflow has an `event` (`item_added_to_project`, `item_removed_from_project`, `item_reopened`, `item_closed`, `item_column_changed`, `code_changes_requested`, `code_review_approved` or `pull_request_merged`), an `enabled` flag, `filters` (`issue_type`, `source_column_id`, `target_column_id`, `label_ids`) and `actions` (`column_id`, `add_label_ids`, `remove_label_ids`, `issue_state`). Each event accepts only the filters and actions listed in [Events](#events).
-
-## Example
-
-To route new bug reports to triage, create a workflow for **Item added to project**:
-
- **Apply to**: Issues only
- **Only if it has labels**: `bug`
- **Move to column**: Triage
- **Add labels**: `needs-triage`
@@ -9,36 +9,25 @@ aliases:

 # Code Owners

-Gitea reads the first CODEOWNERS file found at these locations, in order:
+Gitea maintains code owner files. It looks for it in the following locations in this order:

 - `./CODEOWNERS`
 - `./docs/CODEOWNERS`
 - `./.gitea/CODEOWNERS`

-Pull requests use the base branch's rules. File views show owners from the commit
-being viewed, including when browsing a branch, tag, or historical commit.
+And stops at the first found file.

-## Patterns and owners
+File format: `<regexp rule> <@user or @org/team> [@user or @org/team]...`

-Each rule contains a pattern followed by users or organization teams.
-
-Patterns starting with `*` or containing `/*` are parsed as glob expressions.
-General patterns are parsed as regular expressions.
-A leading `!` inverts a match.
-
-Special rule characters like space, backslash and `#` must be escaped with a backslash.
-When using regexp, since backslash needs to be escaped in rule level, literal dot should be written as  `\\.`
+Regexp specified in golang Regex format.
+Regexp can start with `!` for negative rules - match all files except specified.

 Example file:

-```text
-*.js @alice @bob       # This is an inline comment
-doc/*.md @charles      # Patterns starting with "*" or containing "/*" are parsed as glob
-src/**/db*.py @david   # Use "**" to match any-level sub directories
-
-.*\\.go @user1 @user2   # General patterns are parsed as regexp
-test\\..*\\.js @user3   # !!! Do remeber: NOT "test.*.js", only regexp can be used for such cases
+```bash
+.*\\.go @user1 @user2 # This is comment

+# Comment too
 # You can assigning code owning for users or teams
 frontend/src/.*\\.js @org1/team1 @org1/team2 @user3

@@ -53,69 +42,24 @@ docs/(aws|google|azure)/[^/]*\\.(md|txt) @user8 @org1/team4
 Code owners listed in this file will automatically be requested to review pull requests
 that modify files matching at least one corresponding rule.

-## Sections
+### Escaping

-A section heading can supply default owners for the rules that follow it:
+You can escape characters `#`, ` ` (space) and `\` with `\`, like:

-```text
-[Documentation] @org1/team-doc
-*.md
-README.md @alice
-
-[Frontend] @bob
-*.js
 ```
-
-Owners on a rule replace the section's default owners. Section names are
-case-insensitive; repeated headings belong to the same section. For each file, the
-last matching rule in each named section applies. Matching rules outside named
-sections retain Gitea's existing behavior: they all apply.
-
-## Review request annotations
-
-Use `## review-request=true` or `## review-request=false` to control automatic
-review requests. A line annotation overrides a section annotation, which overrides
-the global value. When none is set, individual code owners receive automatic review
-requests only if they watch the repository and include pull requests in their watch
-preferences. Team-level requests are enabled by default. An explicit `true` requests
-a review regardless of the individual owner's watch preferences; `false` disables
-automatic requests for the rule.
-
-```text
-## review-request=false # global default for following rules
-
-*.js @alice ## review-request=true # only this rule
-
-[Documentation] @org1/team-doc ## review-request=true
-*.md
-private/* @bob ## review-request=false
-```
-
-A standalone annotation changes the global default for subsequent rules.
-Annotations on section headings apply until the next heading. Ordinary comments
-start with `#`, including comments after annotations.
-
-Disabling review requests keeps code owners visible when viewing a file and
-does not waive approvals required by branch protection.
-
-## Escaping
-
-You need to escape characters `#`, ` ` (space) and `\` with backslash `\`, e.g.:
-
-```text
 dir/with\#hashtag @user1
 path\ with\ space @user2
 path/with\\backslash @user3
 ```

-Some regexp characters (`.+*?()|[]{}^$\`) should be escaped with `\\`, e.g.:
+Some character (`.+*?()|[]{}^$\`) should be escaped with `\\` inside regexp, like:

 ```
 path/\\.with\\.dots
 path/with\\+plus
 ```

-## Branch Protection Rules
+### Branch Protection Rules

 When setting up branch protection rules, you may choose to enforce code owner approval of
 modified files. This will block a PR from being merged until at least one code owner
@@ -123,7 +67,7 @@ has given approval for every applicable rule listed in the `CODEOWNERS` file.

 For example, say you have the following `CODEOWNERS` file:

-```text
+```bash
 .*\\.go @Bob
 .*\\.md @Sally @Chris
 migrations/.* @Alice
Author	SHA1	Message	Date
Lunny Xiao	d39c6d0cd6	Merge branch 'main' into audit	2026-09-19 00:12:43 +00:00
Lunny Xiao	0c1071b3a6	Merge branch 'main' into audit	2026-09-19 00:04:45 +00:00
Lunny Xiao	2b1ddd1d44	Merge branch 'main' into audit	2026-09-18 03:37:34 +00:00
silverwindandClaude	1dd914792d	Correct audit logging actors, warning and coverage The system actor names did not match what Gitea records, the disabled warning only shows on the admin page, and the recorded/not recorded lists overstated login and issue edit coverage while missing user status changes. Co-Authored-By: Claude (Opus 5) <[email protected]>	2026-09-18 03:14:54 +02:00
Lunny Xiao	240a2840a4	Merge branch 'main' into audit	2026-09-17 20:22:15 +00:00
bircni	fa7c65e2dd	Merge branch 'main' into audit	2026-09-13 07:30:18 +00:00
bircni	a018c73100	docs: Document audit logging	2026-09-12 13:21:33 +02:00