docs: refine MAX_DECOMPRESSION_RATIO comment

Assisted-by: Claude Code:claude-opus-4-8

.gitea/workflows/build-and-publish.yaml

@@ -18,10 +18,10 @@ jobs:
       PUBLIC_DOCSEARCH_INDEX_NAME: ${{ secrets.DOCSEARCH_INDEX_NAME }}
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-      - uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6
+      - uses: pnpm/action-setup@73e46992e05b19abd31f2f3c20e0e7370d762115 # v6
       - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7
         with:
-          node-version: 24
+          node-version: 26
           cache: pnpm
       - name: prepare awesome list
         run: |

.gitea/workflows/test.yaml

@@ -15,10 +15,10 @@ jobs:
       NODE_OPTIONS: --max-old-space-size=8192
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-      - uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6
+      - uses: pnpm/action-setup@73e46992e05b19abd31f2f3c20e0e7370d762115 # v6
       - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7
         with:
-          node-version: 24
+          node-version: 26
           cache: pnpm
       - name: prepare awesome list
         run: |

docs/administration/config-cheat-sheet.md

@@ -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`: **false**: Set the default value for "Delete pull request branch after merge by default" for new repositories.
+- `DEFAULT_DELETE_BRANCH_AFTER_MERGE`: **true**: 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.
@@ -1468,6 +1468,7 @@ 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`)
@@ -1488,8 +1489,9 @@ 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`)
 

docs/installation/database-preparation.md

@@ -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. 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.
+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.
 
 :::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,6 +177,28 @@ 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.

docs/usage/actions/comparison.md

@@ -16,17 +16,7 @@ Gitea Actions is designed to be compatible with GitHub Actions, with the differe
 
 ### Action prefixes
 
-`uses:` accepts these prefixes:
-
-- `self:` references your own Gitea instance, e.g. `uses: self:owner/repo@v1` or `uses: self:owner/repo/.gitea/workflows/build.yml@v1`
-- `builtin:` runs an action built into Gitea Runner, which needs no download and no Node in the job image, e.g. `uses: builtin:checkout`
-
-`builtin:checkout` accepts the `repository`, `ref`, `token`, `path` and `fetch-depth` inputs of `actions/checkout` with the same defaults, and fails on any other input.
-
-### Workflow-relative actions
-
-`$/` references the repository and commit of the workflow, or of the enclosing composite action, e.g. `uses: $/.gitea/actions/build`.
-Unlike `./`, it needs no checkout first.
+`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`.
 
 ### Actions written in Go
 
@@ -92,7 +82,7 @@ See [Actions job token permissions](token-permissions.md).
 
 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), [Action prefixes](#action-prefixes) and [Workflow-relative actions](#workflow-relative-actions).
+For other sources, see [Absolute action URLs](#absolute-action-urls) and [Action prefixes](#action-prefixes).
 
 ### Context availability
 

docs/usage/packages/overview.md

@@ -36,6 +36,7 @@ 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!**

docs/usage/packages/terraform-module.md

@@ -0,0 +1,170 @@
+---
+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.
+

docs/usage/repository/code-owners.md

@@ -9,25 +9,36 @@ aliases:
 
 # Code Owners
 
-Gitea maintains code owner files. It looks for it in the following locations in this order:
+Gitea reads the first CODEOWNERS file found at these locations, in order:
 
 - `./CODEOWNERS`
 - `./docs/CODEOWNERS`
 - `./.gitea/CODEOWNERS`
 
-And stops at the first found file.
+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.
 
-File format: `<regexp rule> <@user or @org/team> [@user or @org/team]...`
+## Patterns and owners
 
-Regexp specified in golang Regex format.
-Regexp can start with `!` for negative rules - match all files except specified.
+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  `\\.`
 
 Example file:
 
-```bash
-.*\\.go @user1 @user2 # This is comment
+```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
 
-# Comment too
 # You can assigning code owning for users or teams
 frontend/src/.*\\.js @org1/team1 @org1/team2 @user3
 
@@ -42,24 +53,69 @@ 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.
 
-### Escaping
+## Sections
 
-You can escape characters `#`, ` ` (space) and `\` with `\`, like:
+A section heading can supply default owners for the rules that follow it:
 
+```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 character (`.+*?()|[]{}^$\`) should be escaped with `\\` inside regexp, like:
+Some regexp characters (`.+*?()|[]{}^$\`) should be escaped with `\\`, e.g.:
 
 ```
 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
@@ -67,7 +123,7 @@ has given approval for every applicable rule listed in the `CODEOWNERS` file.
 
 For example, say you have the following `CODEOWNERS` file:
 
-```bash
+```text
 .*\\.go @Bob
 .*\\.md @Sally @Chris
 migrations/.* @Alice

i18n/zh-cn/docs/current/administration/config-cheat-sheet.md

@@ -141,7 +141,7 @@ aliases:
 - `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES`: **false**: 在默认的 squash 合并消息中，包括构成拉取请求的所有提交的提交消息。
 - `ADD_CO_COMMITTER_TRAILERS`: **true**: 如果提交者与作者不匹配，在合并提交消息中添加`co-authored-by`和`co-committed-by`标记。
 - `RETARGET_CHILDREN_ON_MERGE`: **true**: 当父合并请求被合并时，将子合并请求重新定向到父合并请求的目标分支。仅适用于头分支和基分支指向同一仓库的已合并合并请求。
-- `DEFAULT_DELETE_BRANCH_AFTER_MERGE`: **false**: 为新仓库设置"合并后默认删除合并请求分支"的默认值。
+- `DEFAULT_DELETE_BRANCH_AFTER_MERGE`: **true**: 为新仓库设置"合并后默认删除合并请求分支"的默认值。
 
 ### 仓库 - 工单 (`repository.issue`)
 
@@ -1300,6 +1300,7 @@ ALLOW_DATA_URI_IMAGES = true
 - `CHUNKED_UPLOAD_PATH`：**tmp/package-upload**: 分块上传的路径。默认为 `APP_DATA_PATH` + `tmp/package-upload`。
 - `LIMIT_TOTAL_OWNER_COUNT`：**-1**: 单个所有者可以拥有的包版本的最大数量（`-1` 表示无限制）。
 - `LIMIT_TOTAL_OWNER_SIZE`：**-1**: 单个所有者可以使用的包的最大大小（`-1` 表示无限制，格式为 `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**: Alpine 上传的最大大小（`-1` 表示无限制，格式为 `1000`、`1 MB`、`1 GiB`）。
 - `LIMIT_SIZE_CARGO`：**-1**: Cargo 上传的最大大小（`-1` 表示无限制，格式为 `1000`、`1 MB`、`1 GiB`）。
 - `LIMIT_SIZE_CHEF`：**-1**: Chef 上传的最大大小（`-1` 表示无限制，格式为 `1000`、`1 MB`、`1 GiB`）。

i18n/zh-cn/docs/current/installation/database-preparation.md

@@ -8,7 +8,7 @@ aliases:
 
 # 数据库准备
 
-在使用 Gitea 前，您需要准备一个数据库。Gitea 支持 PostgreSQL（>= 12）、MySQL（>= 8.0）、MariaDB（>= 10.4）、SQLite（内置） 和 MSSQL（>= 2012 SP4）这几种数据库。本页将指导您准备数据库。由于 PostgreSQL 和 MySQL 在生产环境中被广泛使用，因此本文档将仅涵盖这两种数据库。如果您计划使用 SQLite，则可以忽略本章内容。
+在使用 Gitea 前，您需要准备一个数据库。Gitea 支持 PostgreSQL（>= 12）、MySQL（>= 8.0）、MariaDB（>= 10.4）、SQLite（内置） 和 MSSQL（>= 2012 SP4）这几种数据库。本页将指导您准备数据库。本文档涵盖 PostgreSQL、MySQL 和 MSSQL。如果您计划使用 SQLite，则可以忽略本章内容。
 
 如果您使用不受支持的数据库版本，请通过 [联系我们](/help/support) 以获取有关我们的扩展支持的信息。我们可以为旧数据库提供测试和支持，并将这些修复集成到 Gitea 代码库中。
 
@@ -168,6 +168,28 @@ aliases:
 
    您应该会被提示输入数据库用户的密码，并连接到数据库。
 
+## MSSQL
+
+1. 以管理员身份创建登录名、使用大小写敏感排序规则的数据库及其用户。请将密码 `'gitea'` 替换为安全的密码：
+
+   ```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
+   ```
+
+   升级会更改数据库结构，因此该用户需要 `db_owner`，或者 `db_ddladmin`、`db_datareader` 和 `db_datawriter`。使用后者时，还需以管理员身份执行 `ALTER DATABASE giteadb SET READ_COMMITTED_SNAPSHOT ON;`。
+
+2. 在您的 Gitea 服务器上，测试与数据库的连接：
+
+   ```sh
+   sqlcmd -S 203.0.113.3 -U gitea -d giteadb
+   ```
+
 ## 使用 TLS 进行数据库连接
 
 如果 Gitea 和您的数据库实例之间的通信是通过私有网络进行的，或者如果 Gitea 和数据库运行在同一台服务器上，那么可以省略本节，因为 Gitea 和数据库实例之间的安全性不会受到严重威胁。但是，如果数据库实例位于公共网络上，请使用 TLS 对数据库连接进行加密，以防止第三方拦截流量数据。

i18n/zh-cn/docs/current/usage/actions/comparison.md

@@ -18,18 +18,7 @@ Gitea Actions旨在与GitHub Actions兼容，差异如下。
 <a id="action-prefixes"></a>
 ### Action前缀
 
-`uses:`支持以下前缀：
-
-- `self:`引用您自己的Gitea实例，例如`uses: self:owner/repo@v1`或`uses: self:owner/repo/.gitea/workflows/build.yml@v1`
-- `builtin:`运行Gitea Runner内置的Action，无需下载，Job镜像中也无需Node，例如`uses: builtin:checkout`
-
-`builtin:checkout`支持`actions/checkout`的`repository`、`ref`、`token`、`path`和`fetch-depth`输入，默认值相同，其他输入会使步骤失败。
-
-<a id="workflow-relative-actions"></a>
-### 相对于工作流的Actions
-
-`$/`引用工作流所在的仓库和提交，或外层复合Action所在的仓库和提交，例如`uses: $/.gitea/actions/build`。
-与`./`不同，它无需事先检出代码。
+`uses:`支持`self:`前缀，用于引用您自己的Gitea实例，例如`uses: self:owner/repo@v1`或`uses: self:owner/repo/.gitea/workflows/build.yml@v1`。
 
 ### 使用Go编写Actions
 
@@ -95,7 +84,7 @@ Gitea Actions旨在与GitHub Actions兼容，差异如下。
 
 未指定主机的Actions（如`uses: actions/checkout@v4`）会从`https://github.com`下载，当`[actions].DEFAULT_ACTIONS_URL`为`self`时则从您自己的实例下载。
 请参阅[配置备忘单](../../administration/config-cheat-sheet.md#actions-actions)。
-其他来源请参阅[Action URL绝对路径](#absolute-action-urls)、[Action前缀](#action-prefixes)和[相对于工作流的Actions](#workflow-relative-actions)。
+其他来源请参阅[Action URL绝对路径](#absolute-action-urls)和[Action前缀](#action-prefixes)。
 
 ### 上下文可用性
 

i18n/zh-cn/docs/version-28/installation/database-preparation.md

@@ -8,7 +8,7 @@ aliases:
 
 # 数据库准备
 
-在使用 Gitea 前，您需要准备一个数据库。Gitea 支持 PostgreSQL（>= 12）、MySQL（>= 8.0）、MariaDB（>= 10.4）、SQLite（内置） 和 MSSQL（>= 2012 SP4）这几种数据库。本页将指导您准备数据库。由于 PostgreSQL 和 MySQL 在生产环境中被广泛使用，因此本文档将仅涵盖这两种数据库。如果您计划使用 SQLite，则可以忽略本章内容。
+在使用 Gitea 前，您需要准备一个数据库。Gitea 支持 PostgreSQL（>= 12）、MySQL（>= 8.0）、MariaDB（>= 10.4）、SQLite（内置） 和 MSSQL（>= 2012 SP4）这几种数据库。本页将指导您准备数据库。本文档涵盖 PostgreSQL、MySQL 和 MSSQL。如果您计划使用 SQLite，则可以忽略本章内容。
 
 如果您使用不受支持的数据库版本，请通过 [联系我们](/help/support) 以获取有关我们的扩展支持的信息。我们可以为旧数据库提供测试和支持，并将这些修复集成到 Gitea 代码库中。
 
@@ -168,6 +168,28 @@ aliases:
 
    您应该会被提示输入数据库用户的密码，并连接到数据库。
 
+## MSSQL
+
+1. 以管理员身份创建登录名、使用大小写敏感排序规则的数据库及其用户。请将密码 `'gitea'` 替换为安全的密码：
+
+   ```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
+   ```
+
+   升级会更改数据库结构，因此该用户需要 `db_owner`，或者 `db_ddladmin`、`db_datareader` 和 `db_datawriter`。使用后者时，还需以管理员身份执行 `ALTER DATABASE giteadb SET READ_COMMITTED_SNAPSHOT ON;`。
+
+2. 在您的 Gitea 服务器上，测试与数据库的连接：
+
+   ```sh
+   sqlcmd -S 203.0.113.3 -U gitea -d giteadb
+   ```
+
 ## 使用 TLS 进行数据库连接
 
 如果 Gitea 和您的数据库实例之间的通信是通过私有网络进行的，或者如果 Gitea 和数据库运行在同一台服务器上，那么可以省略本节，因为 Gitea 和数据库实例之间的安全性不会受到严重威胁。但是，如果数据库实例位于公共网络上，请使用 TLS 对数据库连接进行加密，以防止第三方拦截流量数据。

i18n/zh-cn/docs/version-28/usage/actions/comparison.md

@@ -21,15 +21,7 @@ Gitea Actions旨在与GitHub Actions兼容，差异如下。
 `uses:`支持以下前缀：
 
 - `self:`引用您自己的Gitea实例，例如`uses: self:owner/repo@v1`或`uses: self:owner/repo/.gitea/workflows/build.yml@v1`
-- `builtin:`运行Gitea Runner内置的Action，无需下载，Job镜像中也无需Node，例如`uses: builtin:checkout`
-
-`builtin:checkout`支持`actions/checkout`的`repository`、`ref`、`token`、`path`和`fetch-depth`输入，默认值相同，其他输入会使步骤失败。
-
-<a id="workflow-relative-actions"></a>
-### 相对于工作流的Actions
-
-`$/`引用工作流所在的仓库和提交，或外层复合Action所在的仓库和提交，例如`uses: $/.gitea/actions/build`。
-与`./`不同，它无需事先检出代码。
+- `builtin:`运行Gitea Runner内置的Action，无需下载，也不依赖Node.js，例如`uses: builtin:checkout`
 
 ### 使用Go编写Actions
 
@@ -95,7 +87,7 @@ Gitea Actions旨在与GitHub Actions兼容，差异如下。
 
 未指定主机的Actions（如`uses: actions/checkout@v4`）会从`https://github.com`下载，当`[actions].DEFAULT_ACTIONS_URL`为`self`时则从您自己的实例下载。
 请参阅[配置备忘单](../../administration/config-cheat-sheet.md#actions-actions)。
-其他来源请参阅[Action URL绝对路径](#absolute-action-urls)、[Action前缀](#action-prefixes)和[相对于工作流的Actions](#workflow-relative-actions)。
+其他来源请参阅[Action URL绝对路径](#absolute-action-urls)和[Action前缀](#action-prefixes)。
 
 ### 上下文可用性
 

i18n/zh-tw/docs/current/administration/config-cheat-sheet.md

@@ -142,7 +142,7 @@ aliases:
 - `POPULATE_SQUASH_COMMENT_WITH_COMMIT_MESSAGES`: **false**: 在預設的 squash 合併消息中，包括構成拉取請求的所有提交的提交消息。
 - `ADD_CO_COMMITTER_TRAILERS`: **true**: 如果提交者與作者不匹配，在合併提交消息中添加`co-authored-by`和`co-committed-by`標記。
 - `RETARGET_CHILDREN_ON_MERGE`: **true**: 當父合併請求被合併時，將子合併請求重新定向到父合併請求的目標分支。僅適用於頭分支和基分支指向同一儲存庫的已合併合併請求。
-- `DEFAULT_DELETE_BRANCH_AFTER_MERGE`: **false**: 為新儲存庫設定"合併後預設刪除合併請求分支"的預設值。
+- `DEFAULT_DELETE_BRANCH_AFTER_MERGE`: **true**: 為新儲存庫設定"合併後預設刪除合併請求分支"的預設值。
 
 ### 儲存庫 - 工單 (`repository.issue`)
 
@@ -1306,6 +1306,7 @@ ALLOW_DATA_URI_IMAGES = true
 - `CHUNKED_UPLOAD_PATH`：**tmp/package-upload**: 分塊上傳的路徑。預設為 `APP_DATA_PATH` + `tmp/package-upload`。
 - `LIMIT_TOTAL_OWNER_COUNT`：**-1**: 單個所有者可以擁有的包版本的最大數量（`-1` 表示無限制）。
 - `LIMIT_TOTAL_OWNER_SIZE`：**-1**: 單個所有者可以使用的包的最大大小（`-1` 表示無限制，格式為 `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**: Alpine 上傳的最大大小（`-1` 表示無限制，格式為 `1000`、`1 MB`、`1 GiB`）。
 - `LIMIT_SIZE_CARGO`：**-1**: Cargo 上傳的最大大小（`-1` 表示無限制，格式為 `1000`、`1 MB`、`1 GiB`）。
 - `LIMIT_SIZE_CHEF`：**-1**: Chef 上傳的最大大小（`-1` 表示無限制，格式為 `1000`、`1 MB`、`1 GiB`）。

i18n/zh-tw/docs/current/installation/database-preparation.md

@@ -8,7 +8,7 @@ aliases:
 
 # 資料庫準備
 
-在使用 Gitea 前，您需要準備一個資料庫。Gitea 支援 PostgreSQL（>= 12）、MySQL（>= 8.0）、MariaDB（>= 10.4）、SQLite（內置） 和 MSSQL（>= 2012 SP4）這幾種資料庫。本頁將指導您準備資料庫。由於 PostgreSQL 和 MySQL 在生產環境中被廣泛使用，因此本文件將僅涵蓋這兩種資料庫。如果您計劃使用 SQLite，則可以忽略本章內容。
+在使用 Gitea 前，您需要準備一個資料庫。Gitea 支援 PostgreSQL（>= 12）、MySQL（>= 8.0）、MariaDB（>= 10.4）、SQLite（內置） 和 MSSQL（>= 2012 SP4）這幾種資料庫。本頁將指導您準備資料庫。本文件涵蓋 PostgreSQL、MySQL 和 MSSQL。如果您計劃使用 SQLite，則可以忽略本章內容。
 
 如果您使用不受支援的資料庫版本，請通過 [聯繫我們](/help/support) 以獲取有關我們的擴展支援的資訊。我們可以為舊資料庫提供測試和支援，並將這些修復整合到 Gitea 程式碼庫中。
 
@@ -168,6 +168,28 @@ aliases:
 
    您應該會被提示輸入資料庫使用者的密碼，並連接到資料庫。
 
+## MSSQL
+
+1. 以管理員身份建立登入名稱、使用大小寫敏感排序規則的資料庫及其使用者。請將密碼 `'gitea'` 替換為安全的密碼：
+
+   ```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
+   ```
+
+   升級會更改資料庫結構，因此該使用者需要 `db_owner`，或者 `db_ddladmin`、`db_datareader` 和 `db_datawriter`。使用後者時，還需以管理員身份執行 `ALTER DATABASE giteadb SET READ_COMMITTED_SNAPSHOT ON;`。
+
+2. 在您的 Gitea 伺服器上，測試與資料庫的連接：
+
+   ```sh
+   sqlcmd -S 203.0.113.3 -U gitea -d giteadb
+   ```
+
 ## 使用 TLS 進行資料庫連接
 
 如果 Gitea 和您的資料庫實例之間的通信是通過私有網路進行的，或者如果 Gitea 和資料庫運行在同一臺伺服器上，那麼可以省略本節，因為 Gitea 和資料庫實例之間的安全性不會受到嚴重威脅。但是，如果資料庫實例位於公共網路上，請使用 TLS 對資料庫連接進行加密，以防止第三方攔截流量資料。

i18n/zh-tw/docs/current/usage/actions/comparison.md

@@ -18,18 +18,7 @@ Gitea Actions 旨在與 GitHub Actions 相容，差異如下。
 <a id="action-prefixes"></a>
 ### Action 前綴
 
-`uses:` 接受以下前綴：
-
-- `self:` 參照您自己的 Gitea 實例，例如 `uses: self:owner/repo@v1` 或 `uses: self:owner/repo/.gitea/workflows/build.yml@v1`
-- `builtin:` 執行 Gitea Runner 內建的 Action，無需下載，Job 映像檔中也不需要 Node，例如 `uses: builtin:checkout`
-
-`builtin:checkout` 支援 `actions/checkout` 的 `repository`、`ref`、`token`、`path` 和 `fetch-depth` 輸入，預設值相同，其他輸入會使步驟失敗。
-
-<a id="workflow-relative-actions"></a>
-### 相對於工作流的 Actions
-
-`$/` 參照工作流（或外層複合 Action）所在的儲存庫與提交，例如 `uses: $/.gitea/actions/build`。
-與 `./` 不同，它不需要事先簽出程式碼。
+`uses:` 接受 `self:` 前綴，用於參照您自己的 Gitea 實例，例如 `uses: self:owner/repo@v1` 或 `uses: self:owner/repo/.gitea/workflows/build.yml@v1`。
 
 ### 使用Go編寫Actions
 
@@ -95,7 +84,7 @@ Gitea Actions 旨在與 GitHub Actions 相容，差異如下。
 
 未指定主機的 Actions，例如 `uses: actions/checkout@v4`，會從 `https://github.com` 下載，若 `[actions].DEFAULT_ACTIONS_URL` 為 `self`，則從您自己的實例下載。
 請參閱[設定速查表](../../administration/config-cheat-sheet.md#actions-actions)。
-其他來源請參閱 [Action URL絕對路徑](#absolute-action-urls)、[Action 前綴](#action-prefixes)和[相對於工作流的 Actions](#workflow-relative-actions)。
+其他來源請參閱 [Action URL絕對路徑](#absolute-action-urls)和[Action 前綴](#action-prefixes)。
 
 ### 上下文可用性
 

i18n/zh-tw/docs/version-28/installation/database-preparation.md

@@ -8,7 +8,7 @@ aliases:
 
 # 資料庫準備
 
-在使用 Gitea 前，您需要準備一個資料庫。Gitea 支援 PostgreSQL（>= 12）、MySQL（>= 8.0）、MariaDB（>= 10.4）、SQLite（內置） 和 MSSQL（>= 2012 SP4）這幾種資料庫。本頁將指導您準備資料庫。由於 PostgreSQL 和 MySQL 在生產環境中被廣泛使用，因此本文件將僅涵蓋這兩種資料庫。如果您計劃使用 SQLite，則可以忽略本章內容。
+在使用 Gitea 前，您需要準備一個資料庫。Gitea 支援 PostgreSQL（>= 12）、MySQL（>= 8.0）、MariaDB（>= 10.4）、SQLite（內置） 和 MSSQL（>= 2012 SP4）這幾種資料庫。本頁將指導您準備資料庫。本文件涵蓋 PostgreSQL、MySQL 和 MSSQL。如果您計劃使用 SQLite，則可以忽略本章內容。
 
 如果您使用不受支援的資料庫版本，請通過 [聯繫我們](/help/support) 以獲取有關我們的擴展支援的資訊。我們可以為舊資料庫提供測試和支援，並將這些修復整合到 Gitea 程式碼庫中。
 
@@ -168,6 +168,28 @@ aliases:
 
    您應該會被提示輸入資料庫使用者的密碼，並連接到資料庫。
 
+## MSSQL
+
+1. 以管理員身份建立登入名稱、使用大小寫敏感排序規則的資料庫及其使用者。請將密碼 `'gitea'` 替換為安全的密碼：
+
+   ```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
+   ```
+
+   升級會更改資料庫結構，因此該使用者需要 `db_owner`，或者 `db_ddladmin`、`db_datareader` 和 `db_datawriter`。使用後者時，還需以管理員身份執行 `ALTER DATABASE giteadb SET READ_COMMITTED_SNAPSHOT ON;`。
+
+2. 在您的 Gitea 伺服器上，測試與資料庫的連接：
+
+   ```sh
+   sqlcmd -S 203.0.113.3 -U gitea -d giteadb
+   ```
+
 ## 使用 TLS 進行資料庫連接
 
 如果 Gitea 和您的資料庫實例之間的通信是通過私有網路進行的，或者如果 Gitea 和資料庫運行在同一臺伺服器上，那麼可以省略本節，因為 Gitea 和資料庫實例之間的安全性不會受到嚴重威脅。但是，如果資料庫實例位於公共網路上，請使用 TLS 對資料庫連接進行加密，以防止第三方攔截流量資料。

i18n/zh-tw/docs/version-28/usage/actions/comparison.md

@@ -21,15 +21,7 @@ Gitea Actions 旨在與 GitHub Actions 相容，差異如下。
 `uses:` 接受以下前綴：
 
 - `self:` 參照您自己的 Gitea 實例，例如 `uses: self:owner/repo@v1` 或 `uses: self:owner/repo/.gitea/workflows/build.yml@v1`
-- `builtin:` 執行 Gitea Runner 內建的 Action，無需下載，Job 映像檔中也不需要 Node，例如 `uses: builtin:checkout`
-
-`builtin:checkout` 支援 `actions/checkout` 的 `repository`、`ref`、`token`、`path` 和 `fetch-depth` 輸入，預設值相同，其他輸入會使步驟失敗。
-
-<a id="workflow-relative-actions"></a>
-### 相對於工作流的 Actions
-
-`$/` 參照工作流（或外層複合 Action）所在的儲存庫與提交，例如 `uses: $/.gitea/actions/build`。
-與 `./` 不同，它不需要事先簽出程式碼。
+- `builtin:` 執行 Gitea Runner 內建的 Action，無需下載，也不依賴 Node.js，例如 `uses: builtin:checkout`
 
 ### 使用Go編寫Actions
 
@@ -95,7 +87,7 @@ Gitea Actions 旨在與 GitHub Actions 相容，差異如下。
 
 未指定主機的 Actions，例如 `uses: actions/checkout@v4`，會從 `https://github.com` 下載，若 `[actions].DEFAULT_ACTIONS_URL` 為 `self`，則從您自己的實例下載。
 請參閱[設定速查表](../../administration/config-cheat-sheet.md#actions-actions)。
-其他來源請參閱 [Action URL絕對路徑](#absolute-action-urls)、[Action 前綴](#action-prefixes)和[相對於工作流的 Actions](#workflow-relative-actions)。
+其他來源請參閱 [Action URL絕對路徑](#absolute-action-urls)和[Action 前綴](#action-prefixes)。
 
 ### 上下文可用性
 

package.json

@@ -13,5 +13,5 @@
   "engines": {
     "node": ">=22"
   },
-  "packageManager": "[email protected]5.0"
+  "packageManager": "[email protected]7.0"
 }

runner-docs/index.md

@@ -23,7 +23,6 @@ Jobs need these tools wherever steps run, in the job image or on the host:
 
 - `bash` or `sh` for `run` steps, or `pwsh` or `powershell` on Windows.
 - `node` for JavaScript actions and `hashFiles()`.
-- `git` 2.34.1 or later for [`builtin:checkout`](jobs.md#built-in-checkout), plus `git-lfs` for its `lfs` input and `ssh` for its `ssh-key` input.
 
 ## Where jobs run
 

runner-docs/installation/binary.md

@@ -84,7 +84,16 @@ For jobs in containers, give the `gitea-runner` user access to the Docker daemon
 
 ## launchd (macOS)
 
-Adjust the paths and user for your setup, then save this file as `/Library/LaunchDaemons/com.gitea.runner.plist`:
+On macOS, run the runner in the login session of the user that jobs should run as. Jobs then have that user's login keychain and the GUI.
+
+Register the runner as that user, with a [host label](../labels.md) so that jobs run on the Mac itself:
+
+```bash
+mkdir ~/gitea-runner && cd ~/gitea-runner
+gitea-runner register --instance https://gitea.example.com --token <token> --labels macos-latest:host
+```
+
+Replace `/Users/gitea-runner` with the user's home directory, then save this file as `~/Library/LaunchAgents/com.gitea.runner.plist`:
 
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
@@ -97,22 +106,16 @@ Adjust the paths and user for your setup, then save this file as `/Library/Launc
     <array>
         <string>/usr/local/bin/gitea-runner</string>
         <string>daemon</string>
-        <string>--config</string>
-        <string>/etc/gitea-runner/config.yaml</string>
     </array>
-    <key>UserName</key>
-    <string>_gitea-runner</string>
     <key>WorkingDirectory</key>
-    <string>/var/lib/gitea-runner</string>
+    <string>/Users/gitea-runner/gitea-runner</string>
     <key>EnvironmentVariables</key>
     <dict>
         <key>PATH</key>
-        <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
-        <key>HOME</key>
-        <string>/var/lib/gitea-runner</string>
+        <string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
     </dict>
     <key>StandardErrorPath</key>
-    <string>/var/lib/gitea-runner/runner.log</string>
+    <string>/Users/gitea-runner/gitea-runner/runner.log</string>
     <key>RunAtLoad</key>
     <true/>
     <key>KeepAlive</key>
@@ -121,10 +124,30 @@ Adjust the paths and user for your setup, then save this file as `/Library/Launc
 </plist>
 ```
 
+Start the runner. From now on, it also starts whenever the user logs in:
+
 ```bash
-sudo launchctl bootstrap system /Library/LaunchDaemons/com.gitea.runner.plist
+launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.gitea.runner.plist
 ```
 
+Enable automatic login for the user in System Settings, so that the runner starts after a restart too. macOS does not offer automatic login while FileVault is on.
+
+The runner does not get the environment of your shell. Set what jobs need, such as [proxy settings](../proxy.md), in `EnvironmentVariables`.
+
+### Local network access
+
+macOS blocks a runner that was started this way from other hosts on the Mac's own subnet, such as the Gitea instance or a shared cache server. The runner then logs `no route to host`. Commands run in Terminal or over SSH are not blocked, so registering works even when the running runner cannot connect. See [local network privacy](https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy).
+
+macOS asks on the Mac's screen whether to allow the access. To allow it without that prompt, exempt the subnet on macOS 15.5 or later and restart the Mac. On Wi-Fi, the key is `AllowedWiFiLocalNetworkAddresses`:
+
+```bash
+sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array "192.168.1.0/24"
+```
+
+### Git credentials
+
+Git on macOS saves credentials from remote URLs to the keychain, which can stop a job at a dialog that nobody answers. To turn that off, set `GIT_CONFIG_NOSYSTEM` to `1` in `EnvironmentVariables`.
+
 ## Windows
 
 Run `gitea-runner daemon` with a service wrapper such as [WinSW](https://github.com/winsw/winsw). The runner has no service installer of its own.

runner-docs/jobs.md

@@ -68,10 +68,6 @@ Setup actions such as `actions/setup-go` install tools in `/opt/hostedtoolcache`
 
 With `none`, include tools in the job image at `/opt/hostedtoolcache/<tool>/<version>/<arch>`. Place an empty `<arch>.complete` file next to the directory. The `-full` variant of the [runner images](https://gitea.com/gitea/runner-images) includes its tools this way.
 
-## Built-in checkout
-
-`uses: builtin:checkout` checks out the repository like `actions/checkout`. It does not download an action or require Node in the job image. It runs `git` in the job. See [Requirements](index.md#requirements) and the inputs listed in [builtin-actions.md](https://gitea.com/gitea/runner/src/branch/main/docs/builtin-actions.md).
-
 ## Secrets
 
 The runner masks secrets and `::add-mask::` values in job logs, job summaries, and the names of containers it creates. The runner does not send job outputs that contain a secret. A `needs.<job>.outputs.<name>` expression that reads such an output is empty.

runner-docs/reference/cli.md

@@ -20,13 +20,13 @@ Usage:
   gitea-runner [command]
 
 Available Commands:
-  bug-report      Print information useful when filing a bug report
-  cache-server    Start a cache server for the cache action
-  config          Generate, read and edit config files
-  daemon          Run as a runner daemon
-  exec            Run workflow locally.
-  help            Help about any command
-  register        Register a runner to the server
+  bug-report          Print information useful when filing a bug report
+  cache-server        Start a cache server for the cache action
+  config              Generate, read and edit config files
+  daemon              Run as a runner daemon
+  exec                Run workflow locally.
+  help                Help about any command
+  register            Register a runner to the server
 
 Flags:
   -c, --config config   Config file path. config subcommands fall back to config.yaml in the working directory or next to the executable
@@ -91,8 +91,8 @@ Usage:
 
 Flags:
       --artifact-server-addr string      Defines the address where the artifact server listens
-      --artifact-server-path string      Defines the path where the artifact server stores uploads and retrieves downloads from. If not specified the artifact server will not start. (default ".")
-      --artifact-server-port string      Defines the port where the artifact server listens (will only bind to localhost). (default "34567")
+      --artifact-server-path string      Defines the path where the artifact server stores uploads and retrieves downloads from, outside the workspace that jobs copy. Defaults to a temporary directory removed on exit.
+      --artifact-server-port string      Defines the port where the artifact server listens (default "34567")
       --container-architecture string    Architecture which should be used to run containers, e.g.: linux/amd64. If not specified, will use host default architecture. Requires Docker server API Version 1.41+. Ignored on earlier Docker server platforms.
       --container-cap-add stringArray    kernel capabilities to add to the workflow containers (e.g. --container-cap-add SYS_PTRACE)
       --container-cap-drop stringArray   kernel capabilities to remove from the workflow containers (e.g. --container-cap-drop SYS_PTRACE)

runner-docs/reference/config-example.md

@@ -57,6 +57,12 @@ runner:
   # PEM client certificate and key for a Gitea instance that requires mutual TLS.
   #client_cert_file: /etc/gitea-runner/client.crt
   #client_key_file: /etc/gitea-runner/client.key
+  # PEM CA certificates of a Gitea instance with a private CA, trusted besides the system's.
+  # Runner-side git and builtin:checkout use it instead of the system's bundle for the instance.
+  # Jobs get it at /var/run/act/ca.crt, or in their act directory on the host, with NODE_EXTRA_CA_CERTS
+  # pointing there unless the job, or on Docker its image, sets it. Other tools in jobs, such as the
+  # git that actions/checkout runs, need the CA in the image's bundle, for example via container.volumes.
+  #ca_file: /etc/gitea-runner/ca.crt
   # The timeout for fetching the job from the Gitea instance.
   # Values above the 60s RPC timeout are capped to it.
   #fetch_timeout: 5s
@@ -126,6 +132,7 @@ runner:
   # If it's empty when execute `daemon`, will use labels in `.runner` file.
   #labels:
   #  - "ubuntu-latest:docker://docker.gitea.com/runner-images:ubuntu-latest"
+  #  - "ubuntu-26.04:docker://docker.gitea.com/runner-images:ubuntu-26.04"
   #  - "ubuntu-24.04:docker://docker.gitea.com/runner-images:ubuntu-24.04"
   #  - "ubuntu-22.04:docker://docker.gitea.com/runner-images:ubuntu-22.04"
   # Allocate a pseudo-TTY for each step's process. Applies to both host and docker backends.
@@ -207,7 +214,8 @@ cache:
   #  secret_key_file: "/run/secrets/cache-s3-secret-key"
   # When true, reuse a cached action instead of fetching from the remote on every job.
   # A moved tag (e.g. a re-tagged "v6") or an updated branch stays at the cached commit
-  # until its cache entry expires or is manually removed.
+  # until its cache entry expires or is manually removed. A cached action whose files changed size
+  # since it was downloaded is still fetched again, unless an older runner cached it without sizes.
   #offline_mode: false
   # Serve the actions cache service v2 API. The actions that use it fall back to v1 on any host
   # they do not take for GitHub, so reaching it means editing that check out of their own bundle,
@@ -218,8 +226,8 @@ cache:
   # How the cache server discards entries, ignored when external_server or s3 is set since
   # those apply their own. Leave a setting out for its default; 0s or 0 turns the three
   # limits off. Sizes accept 10GB, 512mb, 1TiB or a plain byte count, binary either way.
-  # Whatever these allow, the cache still sheds entries to keep free space on its volume
-  # above health_check.min_free_disk_space_mb when health checks are enabled.
+  # Whatever these allow, the cache still sheds entries to keep free space on its volume, room
+  # for uploads included, above health_check.min_free_disk_space_mb when health checks are enabled.
   # Remove entries nothing has read or written within this window. Only last access counts.
   #retention: 168h
   # Cap one repository, removing its least recently accessed entries until it fits. An entry
@@ -276,6 +284,15 @@ container:
   # valid_volumes:
   #   - '**'
   #valid_volumes: []
+  # Volumes and bind mounts the runner adds to every job, service and docker action container, as in
+  # `docker run --volume`, with sources on the docker daemon's host. One the workflow mounts on the same
+  # container path takes its place. Their sources need no valid_volumes entry, and workflow volumes may
+  # use them only with the same access, though a job given the docker socket can mount anything.
+  # Docker only, use pod_template on Kubernetes. For example, to trust a private CA in Debian and
+  # Ubuntu based images:
+  # volumes:
+  #   - /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro
+  #volumes: []
   # Overrides the docker client host with the specified one.
   # If it's empty, runner will find an available docker host automatically.
   # If it's "-", runner will find an available docker host automatically, but won't mount it into the job and action containers.
@@ -303,8 +320,8 @@ container:
   # healthy. A negative value (e.g. -1s) starts the steps without waiting.
   #service_ready_timeout: 5m
   # Remove the containers, networks and volumes a job creates through its Docker proxy when
-  # the job ends. Set to false when jobs deploy services to the runner's Docker daemon.
-  #sweep: true
+  # the job ends. Leave off when jobs deploy services to the runner's Docker daemon.
+  #sweep: false
 
 host:
   # The parent directory of a job's working directory.
@@ -318,6 +335,18 @@ kubernetes:
   #pod_template: {}
   # Pod templates merged over pod_template, in runs-on order, for jobs whose runs-on has the label they are keyed by.
   #pod_templates: {}
+  # Have job pods fetch directories, such as actions, and copies of 64 KiB or more gzipped from the runner over the pod network,
+  # instead of the runner streaming them through the API server. An init container copies gitea-runner from image into each job pod.
+  # api: through the API server (default). auto: over the pod network, through the API server for a job pod that
+  # cannot reach the runner. direct: over the pod network only, so a broken setup fails jobs instead of quietly
+  # costing API server traffic again.
+  #transfer:
+  #  mode: api
+  #  # Address and port the runner listens on and job pods reach it at, the outbound IP and a free port when empty.
+  #  host: ""
+  #  port: 0
+  #  # Image with gitea-runner on its PATH, the runner pod's image when it has a single container and runs in namespace.
+  #  image: ""
 
 # Optional local task-admission checks. Disabled by default. When enabled, low
 # disk space or a failing script pauses new task fetching; existing jobs continue.
@@ -327,8 +356,8 @@ health_check:
   # Minimum free space required on the filesystem holding runner workspaces.
   # Defaults to 1024 MiB when omitted or set to zero.
   #min_free_disk_space_mb: 1024
-  # Optional additional executable. A non-zero exit, timeout, or startup failure
-  # marks the runner unavailable.
+  # Optional additional executable, or a .bat or .cmd file on Windows. A non-zero
+  # exit, timeout, or startup failure marks the runner unavailable.
   #script: ''
   # How long a script result is cached and its maximum execution time.
   #interval: 30s

runner-docs/upgrade.md

@@ -14,6 +14,10 @@ sudo systemctl start gitea-runner
 
 Stopping the runner cancels running jobs unless `runner.shutdown_timeout` gives them time to finish. The runner logs a warning for unknown configuration keys and ignores them. Run `gitea-runner config generate` to list all configuration options.
 
+## Breaking changes in 6.0
+
+- **`builtin:checkout` is removed.** Steps that use it fail. Use `actions/checkout` or a lightweight action such as [`taiki-e/checkout-action`](https://github.com/taiki-e/checkout-action).
+
 ## Breaking changes in 5.0
 
 - **Git 2.34.1 or later is required** on the runner and in job images that use `builtin:checkout`.

runner-docs_versioned_docs/version-4/upgrade.md

@@ -26,7 +26,7 @@ Config files are read leniently: keys the running version does not know are repo
 
 ### Also new
 
-- `builtin:checkout`, which needs neither a download nor Node in the job image, see [docs/builtin-actions.md](https://gitea.com/gitea/runner/src/branch/main/docs/builtin-actions.md), and the `self:` prefix for actions hosted on the runner's own instance.
+- `builtin:checkout`, which needs neither a download nor Node in the job image, see [docs/builtin-actions.md](https://gitea.com/gitea/runner/src/tag/v4.1.0/docs/builtin-actions.md), and the `self:` prefix for actions hosted on the runner's own instance.
 - S3-compatible storage as a cache backend (`cache.s3` in the [example configuration](reference/config-example.md)), shared between runners without a cache server.
 - [OpenTelemetry tracing](monitoring.md#opentelemetry-tracing) of jobs and steps, and from `4.1` the Prometheus metrics exported through OpenTelemetry as well.
 - A Kubernetes backend that runs jobs as pods (`4.1`), see [docs/kubernetes.md](https://gitea.com/gitea/runner/src/branch/main/docs/kubernetes.md).

runner-docs_versioned_docs/version-5/installation/binary.md

@@ -84,7 +84,16 @@ For jobs in containers, give the `gitea-runner` user access to the Docker daemon
 
 ## launchd (macOS)
 
-Adjust the paths and user for your setup, then save this file as `/Library/LaunchDaemons/com.gitea.runner.plist`:
+On macOS, run the runner in the login session of the user that jobs should run as. Jobs then have that user's login keychain and the GUI.
+
+Register the runner as that user, with a [host label](../labels.md) so that jobs run on the Mac itself:
+
+```bash
+mkdir ~/gitea-runner && cd ~/gitea-runner
+gitea-runner register --instance https://gitea.example.com --token <token> --labels macos-latest:host
+```
+
+Replace `/Users/gitea-runner` with the user's home directory, then save this file as `~/Library/LaunchAgents/com.gitea.runner.plist`:
 
 ```xml
 <?xml version="1.0" encoding="UTF-8"?>
@@ -97,22 +106,16 @@ Adjust the paths and user for your setup, then save this file as `/Library/Launc
     <array>
         <string>/usr/local/bin/gitea-runner</string>
         <string>daemon</string>
-        <string>--config</string>
-        <string>/etc/gitea-runner/config.yaml</string>
     </array>
-    <key>UserName</key>
-    <string>_gitea-runner</string>
     <key>WorkingDirectory</key>
-    <string>/var/lib/gitea-runner</string>
+    <string>/Users/gitea-runner/gitea-runner</string>
     <key>EnvironmentVariables</key>
     <dict>
         <key>PATH</key>
-        <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
-        <key>HOME</key>
-        <string>/var/lib/gitea-runner</string>
+        <string>/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin</string>
     </dict>
     <key>StandardErrorPath</key>
-    <string>/var/lib/gitea-runner/runner.log</string>
+    <string>/Users/gitea-runner/gitea-runner/runner.log</string>
     <key>RunAtLoad</key>
     <true/>
     <key>KeepAlive</key>
@@ -121,10 +124,30 @@ Adjust the paths and user for your setup, then save this file as `/Library/Launc
 </plist>
 ```
 
+Start the runner. From now on, it also starts whenever the user logs in:
+
 ```bash
-sudo launchctl bootstrap system /Library/LaunchDaemons/com.gitea.runner.plist
+launchctl bootstrap gui/$(id -u) ~/Library/LaunchAgents/com.gitea.runner.plist
 ```
 
+Enable automatic login for the user in System Settings, so that the runner starts after a restart too. macOS does not offer automatic login while FileVault is on.
+
+The runner does not get the environment of your shell. Set what jobs need, such as [proxy settings](../proxy.md), in `EnvironmentVariables`.
+
+### Local network access
+
+macOS blocks a runner that was started this way from other hosts on the Mac's own subnet, such as the Gitea instance or a shared cache server. The runner then logs `no route to host`. Commands run in Terminal or over SSH are not blocked, so registering works even when the running runner cannot connect. See [local network privacy](https://developer.apple.com/documentation/technotes/tn3179-understanding-local-network-privacy).
+
+macOS asks on the Mac's screen whether to allow the access. To allow it without that prompt, exempt the subnet on macOS 15.5 or later and restart the Mac. On Wi-Fi, the key is `AllowedWiFiLocalNetworkAddresses`:
+
+```bash
+sudo defaults write com.apple.network.local-network AllowedEthernetLocalNetworkAddresses -array "192.168.1.0/24"
+```
+
+### Git credentials
+
+Git on macOS saves credentials from remote URLs to the keychain, which can stop a job at a dialog that nobody answers. To turn that off, set `GIT_CONFIG_NOSYSTEM` to `1` in `EnvironmentVariables`.
+
 ## Windows
 
 Run `gitea-runner daemon` with a service wrapper such as [WinSW](https://github.com/winsw/winsw). The runner has no service installer of its own.

runner-docs_versioned_docs/version-5/jobs.md

@@ -70,7 +70,7 @@ With `none`, include tools in the job image at `/opt/hostedtoolcache/<tool>/<ver
 
 ## Built-in checkout
 
-`uses: builtin:checkout` checks out the repository like `actions/checkout`. It does not download an action or require Node in the job image. It runs `git` in the job. See [Requirements](index.md#requirements) and the inputs listed in [builtin-actions.md](https://gitea.com/gitea/runner/src/branch/main/docs/builtin-actions.md).
+`uses: builtin:checkout` checks out the repository like `actions/checkout`. It does not download an action or require Node in the job image. It runs `git` in the job. See [Requirements](index.md#requirements) and the inputs listed in [builtin-actions.md](https://gitea.com/gitea/runner/src/tag/v5.4.1/docs/builtin-actions.md).
 
 ## Secrets
 

runner-docs_versioned_docs/version-5/reference/cli.md

@@ -20,13 +20,13 @@ Usage:
   gitea-runner [command]
 
 Available Commands:
-  bug-report      Print information useful when filing a bug report
-  cache-server    Start a cache server for the cache action
-  config          Generate, read and edit config files
-  daemon          Run as a runner daemon
-  exec            Run workflow locally.
-  help            Help about any command
-  register        Register a runner to the server
+  bug-report          Print information useful when filing a bug report
+  cache-server        Start a cache server for the cache action
+  config              Generate, read and edit config files
+  daemon              Run as a runner daemon
+  exec                Run workflow locally.
+  help                Help about any command
+  register            Register a runner to the server
 
 Flags:
   -c, --config config   Config file path. config subcommands fall back to config.yaml in the working directory or next to the executable
@@ -91,8 +91,8 @@ Usage:
 
 Flags:
       --artifact-server-addr string      Defines the address where the artifact server listens
-      --artifact-server-path string      Defines the path where the artifact server stores uploads and retrieves downloads from. If not specified the artifact server will not start. (default ".")
-      --artifact-server-port string      Defines the port where the artifact server listens (will only bind to localhost). (default "34567")
+      --artifact-server-path string      Defines the path where the artifact server stores uploads and retrieves downloads from, outside the workspace that jobs copy. Defaults to a temporary directory removed on exit.
+      --artifact-server-port string      Defines the port where the artifact server listens (default "34567")
       --container-architecture string    Architecture which should be used to run containers, e.g.: linux/amd64. If not specified, will use host default architecture. Requires Docker server API Version 1.41+. Ignored on earlier Docker server platforms.
       --container-cap-add stringArray    kernel capabilities to add to the workflow containers (e.g. --container-cap-add SYS_PTRACE)
       --container-cap-drop stringArray   kernel capabilities to remove from the workflow containers (e.g. --container-cap-drop SYS_PTRACE)

runner-docs_versioned_docs/version-5/reference/config-example.md

@@ -57,6 +57,12 @@ runner:
   # PEM client certificate and key for a Gitea instance that requires mutual TLS.
   #client_cert_file: /etc/gitea-runner/client.crt
   #client_key_file: /etc/gitea-runner/client.key
+  # PEM CA certificates of a Gitea instance with a private CA, trusted besides the system's.
+  # Runner-side git and builtin:checkout use it instead of the system's bundle for the instance.
+  # Jobs get it at /var/run/act/ca.crt, or in their act directory on the host, with NODE_EXTRA_CA_CERTS
+  # pointing there unless the job, or on Docker its image, sets it. Other tools in jobs, such as the
+  # git that actions/checkout runs, need the CA in the image's bundle, for example via container.volumes.
+  #ca_file: /etc/gitea-runner/ca.crt
   # The timeout for fetching the job from the Gitea instance.
   # Values above the 60s RPC timeout are capped to it.
   #fetch_timeout: 5s
@@ -207,7 +213,8 @@ cache:
   #  secret_key_file: "/run/secrets/cache-s3-secret-key"
   # When true, reuse a cached action instead of fetching from the remote on every job.
   # A moved tag (e.g. a re-tagged "v6") or an updated branch stays at the cached commit
-  # until its cache entry expires or is manually removed.
+  # until its cache entry expires or is manually removed. A cached action whose files changed size
+  # since it was downloaded is still fetched again, unless an older runner cached it without sizes.
   #offline_mode: false
   # Serve the actions cache service v2 API. The actions that use it fall back to v1 on any host
   # they do not take for GitHub, so reaching it means editing that check out of their own bundle,
@@ -218,8 +225,8 @@ cache:
   # How the cache server discards entries, ignored when external_server or s3 is set since
   # those apply their own. Leave a setting out for its default; 0s or 0 turns the three
   # limits off. Sizes accept 10GB, 512mb, 1TiB or a plain byte count, binary either way.
-  # Whatever these allow, the cache still sheds entries to keep free space on its volume
-  # above health_check.min_free_disk_space_mb when health checks are enabled.
+  # Whatever these allow, the cache still sheds entries to keep free space on its volume, room
+  # for uploads included, above health_check.min_free_disk_space_mb when health checks are enabled.
   # Remove entries nothing has read or written within this window. Only last access counts.
   #retention: 168h
   # Cap one repository, removing its least recently accessed entries until it fits. An entry
@@ -276,6 +283,15 @@ container:
   # valid_volumes:
   #   - '**'
   #valid_volumes: []
+  # Volumes and bind mounts the runner adds to every job, service and docker action container, as in
+  # `docker run --volume`, with sources on the docker daemon's host. One the workflow mounts on the same
+  # container path takes its place. Their sources need no valid_volumes entry, and workflow volumes may
+  # use them only with the same access, though a job given the docker socket can mount anything.
+  # Docker only, use pod_template on Kubernetes. For example, to trust a private CA in Debian and
+  # Ubuntu based images:
+  # volumes:
+  #   - /etc/ssl/certs/ca-certificates.crt:/etc/ssl/certs/ca-certificates.crt:ro
+  #volumes: []
   # Overrides the docker client host with the specified one.
   # If it's empty, runner will find an available docker host automatically.
   # If it's "-", runner will find an available docker host automatically, but won't mount it into the job and action containers.
@@ -303,8 +319,8 @@ container:
   # healthy. A negative value (e.g. -1s) starts the steps without waiting.
   #service_ready_timeout: 5m
   # Remove the containers, networks and volumes a job creates through its Docker proxy when
-  # the job ends. Set to false when jobs deploy services to the runner's Docker daemon.
-  #sweep: true
+  # the job ends. Leave off when jobs deploy services to the runner's Docker daemon.
+  #sweep: false
 
 host:
   # The parent directory of a job's working directory.
@@ -318,6 +334,18 @@ kubernetes:
   #pod_template: {}
   # Pod templates merged over pod_template, in runs-on order, for jobs whose runs-on has the label they are keyed by.
   #pod_templates: {}
+  # Have job pods fetch directories, such as actions, and copies of 64 KiB or more gzipped from the runner over the pod network,
+  # instead of the runner streaming them through the API server. An init container copies gitea-runner from image into each job pod.
+  # api: through the API server (default). auto: over the pod network, through the API server for a job pod that
+  # cannot reach the runner. direct: over the pod network only, so a broken setup fails jobs instead of quietly
+  # costing API server traffic again.
+  #transfer:
+  #  mode: api
+  #  # Address and port the runner listens on and job pods reach it at, the outbound IP and a free port when empty.
+  #  host: ""
+  #  port: 0
+  #  # Image with gitea-runner on its PATH, the runner pod's image when it has a single container and runs in namespace.
+  #  image: ""
 
 # Optional local task-admission checks. Disabled by default. When enabled, low
 # disk space or a failing script pauses new task fetching; existing jobs continue.
@@ -327,8 +355,8 @@ health_check:
   # Minimum free space required on the filesystem holding runner workspaces.
   # Defaults to 1024 MiB when omitted or set to zero.
   #min_free_disk_space_mb: 1024
-  # Optional additional executable. A non-zero exit, timeout, or startup failure
-  # marks the runner unavailable.
+  # Optional additional executable, or a .bat or .cmd file on Windows. A non-zero
+  # exit, timeout, or startup failure marks the runner unavailable.
   #script: ''
   # How long a script result is cached and its maximum execution time.
   #interval: 30s

sites/docs/package.json

@@ -11,16 +11,16 @@
     "check": "astro check"
   },
   "dependencies": {
-    "@astrojs/starlight": "0.42.6",
+    "@astrojs/starlight": "0.42.8",
     "@astrojs/starlight-docsearch": "0.8.0",
     "@gitea-docs/content-loader": "workspace:*",
-    "@pagefind/default-ui": "1.5.2",
-    "astro": "7.4.1",
+    "@pagefind/default-ui": "1.6.0",
+    "astro": "7.4.5",
     "sharp": "0.35.5",
     "starlight-openapi": "0.27.0"
   },
   "devDependencies": {
-    "@astrojs/check": "0.9.11",
+    "@astrojs/check": "0.9.12",
     "typescript": "6.0.3"
   }
 }

versioned_docs/version-28/installation/database-preparation.md

@@ -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. 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.
+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.
 
 :::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,6 +177,28 @@ 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.

versioned_docs/version-28/usage/actions/comparison.md

@@ -19,14 +19,7 @@ Gitea Actions is designed to be compatible with GitHub Actions, with the differe
 `uses:` accepts these prefixes:
 
 - `self:` references your own Gitea instance, e.g. `uses: self:owner/repo@v1` or `uses: self:owner/repo/.gitea/workflows/build.yml@v1`
-- `builtin:` runs an action built into Gitea Runner, which needs no download and no Node in the job image, e.g. `uses: builtin:checkout`
-
-`builtin:checkout` accepts the `repository`, `ref`, `token`, `path` and `fetch-depth` inputs of `actions/checkout` with the same defaults, and fails on any other input.
-
-### Workflow-relative actions
-
-`$/` references the repository and commit of the workflow, or of the enclosing composite action, e.g. `uses: $/.gitea/actions/build`.
-Unlike `./`, it needs no checkout first.
+- `builtin:` runs an action built into Gitea Runner, which needs no download and does not depend on Node.js, e.g. `uses: builtin:checkout`
 
 ### Actions written in Go
 
@@ -92,7 +85,7 @@ See [Actions job token permissions](token-permissions.md).
 
 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), [Action prefixes](#action-prefixes) and [Workflow-relative actions](#workflow-relative-actions).
+For other sources, see [Absolute action URLs](#absolute-action-urls) and [Action prefixes](#action-prefixes).
 
 ### Context availability