chore(deps): update dependencies

Automated update of static/swagger-latest.json and static/openapi3-latest.json from the gitea main branch, opened by the "update api spec files" scheduled workflow.

<!-- cloudflare-preview --> Preview: https://pr-561.docs-gitea-com.pages.dev

Reviewed-on: https://gitea.com/gitea/docs/pulls/561
Reviewed-by: Lunny Xiao <[email protected]>
Co-authored-by: Gitea Bot <[email protected]>

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

@@ -1,5 +1,5 @@
 name: Build and Publish Docs site
-run-name: docusaurus build docs site
+run-name: astro build docs site
 
 on:
   push:
@@ -8,41 +8,41 @@ on:
 
 jobs:
   build-docs:
-    runs-on: ubuntu-latest
+    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
+      # to pagefind otherwise
+      PUBLIC_DOCSEARCH_APP_ID: ${{ secrets.DOCSEARCH_APP_ID }}
+      PUBLIC_DOCSEARCH_API_KEY: ${{ secrets.DOCSEARCH_API_KEY }}
+      PUBLIC_DOCSEARCH_INDEX_NAME: ${{ secrets.DOCSEARCH_INDEX_NAME }}
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-      - uses: actions/setup-node@v4
+      - uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6
+      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
         with:
-          node-version: 20
+          node-version: 24
-          cache: npm
+          cache: pnpm
-      - name: install necessary tools
-        run: |
-          apt update -y && apt install -y rsync python3 python3-pip python-is-python3
-          pip install awscli
       - name: prepare awesome list
         run: |
-          make prepare-awesome-latest prepare-awesome\#22 prepare-awesome\#21 prepare-awesome\#20 prepare-awesome\#19
+          make prepare-awesome-latest prepare-awesome\#27 prepare-awesome\#26 prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22
-      - name: Cache ~/.npm for npm ci
-        uses: actions/cache@v4
-        with:
-          path: ~/.npm
-          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
-          restore-keys: ${{ runner.os }}-node
-
       - name: Install dependencies
-        run: npm ci
+        run: pnpm install --frozen-lockfile
 
-      #- uses: tats-u/docuactions-cache@v1
       - name: build site
+        run: make build
+
+      - name: Copy files to Cloudflare Pages
+        env:
+          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
+          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
         run: |
-          make build
+          # cloudflare/_headers and cloudflare/_redirects are only meaningful for
-      - name: aws credential configure
+          # the Cloudflare Pages deployment, so they are copied into the build
-        uses: aws-actions/configure-aws-credentials@v4
+          # right before the deploy.
-        with:
+          cp cloudflare/_headers sites/docs/dist/_headers
-          aws-access-key-id: ${{ secrets.AWS_KEY_ID }}
+          cp cloudflare/_redirects sites/docs/dist/_redirects
-          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY}}
+          test -f sites/docs/dist/_headers -a -f sites/docs/dist/_redirects || exit 1
-          aws-region: ${{ secrets.AWS_REGION}}
+          pnpm dlx wrangler@4 pages deploy sites/docs/dist \
-      - name: Copy files to the production website with the AWS CLI
+            --project-name docs-gitea-com \
-        run: |
+            --branch main
-          aws s3 sync build/ s3://docs-gitea-com
-          aws cloudfront create-invalidation --distribution-id ${{ secrets.AWS_DISTRIBUTION}} --paths '/*'

.gitea/workflows/cleanup-preview.yaml

@@ -0,0 +1,68 @@
+name: cleanup preview
+
+on:
+  pull_request:
+    types:
+      - closed
+
+# make sure two closing events for the same pull request do not delete the same
+# deployment twice
+concurrency:
+  group: cleanup-preview-${{ github.event.pull_request.number }}
+
+jobs:
+  cleanup-preview:
+    runs-on: ubuntu-latest
+    steps:
+      - name: delete the Cloudflare Pages preview deployments
+        env:
+          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
+          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
+          PR_NUMBER: ${{ github.event.pull_request.number }}
+        run: |
+          set -euo pipefail
+
+          # pull requests from forks do not get the secrets, nothing was
+          # deployed for them either
+          if [ -z "${CLOUDFLARE_API_TOKEN:-}" ] || [ -z "${CLOUDFLARE_ACCOUNT_ID:-}" ]; then
+            echo "no Cloudflare credentials available, skipping the preview cleanup"
+            exit 0
+          fi
+
+          project=docs-gitea-com
+          branch="pr-$PR_NUMBER"
+          api="https://api.cloudflare.com/client/v4/accounts/$CLOUDFLARE_ACCOUNT_ID/pages/projects/$project/deployments"
+
+          page=1
+          ids=""
+          while true; do
+            curl --silent --show-error --fail --output deployments.json \
+              -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
+              "$api?per_page=100&page=$page"
+
+            found="$(jq -r --arg branch "$branch" \
+              '.result[] | select(.deployment_trigger.metadata.branch == $branch) | .id' deployments.json)"
+            if [ -n "$found" ]; then
+              ids="$ids$found"$'\n'
+            fi
+
+            # the API returns an empty result once the last page is passed
+            [ "$(jq -r '.result | length' deployments.json)" -eq 100 ] || break
+            page=$((page + 1))
+          done
+
+          if [ -z "$(printf '%s' "$ids" | tr -d '[:space:]')" ]; then
+            echo "no preview deployment found for $branch"
+            exit 0
+          fi
+
+          # force=true also removes the deployment the branch alias points at
+          printf '%s' "$ids" | while read -r id; do
+            [ -n "$id" ] || continue
+            echo "deleting the deployment $id of $branch"
+            curl --silent --show-error --fail --output /dev/null \
+              -X DELETE "$api/$id?force=true" \
+              -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"
+          done
+
+          echo "the preview of $branch is gone"

.gitea/workflows/test.yaml

@@ -3,29 +3,101 @@ name: checks
 on:
   - pull_request
 
+# a new push to the same pull request replaces the running preview build
+concurrency:
+  group: checks-${{ github.event.pull_request.number }}
+  cancel-in-progress: true
+
 jobs:
   build-docs:
     runs-on: ubuntu-latest
+    env:
+      NODE_OPTIONS: --max-old-space-size=8192
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-      - uses: actions/setup-node@v4
+      - uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6
+      - uses: actions/setup-node@820762786026740c76f36085b0efc47a31fe5020 # v7
         with:
-          node-version: 20
+          node-version: 24
-          cache: npm
+          cache: pnpm
       - name: prepare awesome list
         run: |
-          make prepare-awesome-latest prepare-awesome\#22 prepare-awesome\#21 prepare-awesome\#20 prepare-awesome\#19
+          make prepare-awesome-latest prepare-awesome\#27 prepare-awesome\#26 prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22
-      - name: Cache ~/.npm for npm ci
-        uses: actions/cache@v4
-        with:
-          path: ~/.npm
-          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
-          restore-keys: ${{ runner.os }}-node
 
-      - name: Install dependencies
+      - name: install dependencies
-        run: npm ci
+        run: pnpm install --frozen-lockfile
 
-      #- uses: tats-u/docuactions-cache@v1
       - name: build site
+        run: make build
+
+      - name: type check
+        run: make check
+
+      - name: deploy the preview to Cloudflare Pages
+        id: preview
+        env:
+          CLOUDFLARE_ACCOUNT_ID: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
+          CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
+          PR_NUMBER: ${{ github.event.pull_request.number }}
         run: |
-          make build
+          set -euo pipefail
+
+          # 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 "no Cloudflare credentials available, skipping the preview deployment"
+            exit 0
+          fi
+
+          # same as the production deployment: _headers and _redirects only
+          # belong to the Cloudflare Pages output, so they are copied in right
+          # before uploading
+          cp cloudflare/_headers sites/docs/dist/_headers
+          cp cloudflare/_redirects sites/docs/dist/_redirects
+
+          pnpm dlx wrangler@4 pages deploy sites/docs/dist \
+            --project-name docs-gitea-com \
+            --branch "pr-$PR_NUMBER" | tee wrangler.log
+
+          url="$(grep -Eo 'https://[A-Za-z0-9.-]+\.pages\.dev' wrangler.log | tail -n 1)"
+          if [ -z "$url" ]; then
+            echo "could not read the preview URL from the wrangler output"
+            exit 1
+          fi
+          echo "url=$url" >> "$GITHUB_OUTPUT"
+      - name: update the pull request with the preview URL
+        if: steps.preview.outputs.url != ''
+        env:
+          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
+          PREVIEW_URL: ${{ steps.preview.outputs.url }}
+          PR_NUMBER: ${{ github.event.pull_request.number }}
+        run: |
+          set -euo pipefail
+
+          if [ -z "${DEPLOY_TOKEN:-}" ]; then
+            echo "secrets.DEPLOY_TOKEN is missing, the preview is at $PREVIEW_URL"
+            exit 0
+          fi
+
+          api="${GITHUB_API_URL:-$GITHUB_SERVER_URL/api/v1}/repos/$GITHUB_REPOSITORY/pulls/$PR_NUMBER"
+          curl --silent --show-error --fail --output pull.json \
+            -H "Authorization: token $DEPLOY_TOKEN" "$api"
+
+          marker='<!-- cloudflare-preview -->'
+          # drop the line written by an earlier run, so the URL is updated in
+          # place instead of piling up at the end of the description
+          body="$(jq -r '.body // ""' pull.json | grep -vF "$marker" || true)"
+          body="$(printf '%s\n' "$body" | sed -e :a -e '/^\n*$/{$d;N;ba' -e '}')"
+          if [ -n "$body" ]; then
+            body="$(printf '%s\n\n%s Preview: %s\n' "$body" "$marker" "$PREVIEW_URL")"
+          else
+            body="$(printf '%s Preview: %s\n' "$marker" "$PREVIEW_URL")"
+          fi
+
+          printf '%s' "$body" | jq -Rs '{body: .}' > patch.json
+          curl --silent --show-error --fail --output /dev/null \
+            -X PATCH "$api" \
+            -H "Authorization: token $DEPLOY_TOKEN" \
+            -H 'Content-Type: application/json' \
+            --data @patch.json
+          echo "the pull request now points at $PREVIEW_URL"

.gitea/workflows/update_runner_reference.yaml

@@ -0,0 +1,109 @@
+name: update runner reference
+
+on:
+  schedule:
+    - cron: '30 3 * * 1' # every Monday at 03:30
+  workflow_dispatch:
+
+env:
+  # main is protected, so the update is proposed as a pull request from this branch
+  BOT_BRANCH: bot/update-runner-reference
+  BASE_BRANCH: main
+  # the develop runner docs follow the main branch of gitea/runner, every
+  # documented release series follows its newest stable tag. The value is used
+  # unquoted, so the glob is expanded by the shell of each step.
+  TARGET_DIRS: runner-docs/reference runner-docs_versioned_docs/version-*/reference
+
+jobs:
+  update-runner-reference:
+    if: github.repository == 'gitea/docs'
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+        with:
+          ref: main
+          # pushing uses DEPLOY_TOKEN, keep the ephemeral job token out of .git/config
+          persist-credentials: false
+      - uses: actions/setup-go@b7ad1dad31e06c5925ef5d2fc7ad053ef454303e # v7
+        with:
+          go-version: 'stable'
+          cache: false
+      - name: regenerate the runner reference pages
+        run: |
+          set -euo pipefail
+          ./update_runner_docs.sh main runner-docs/reference
+          ./update_runner_docs.sh --released
+      - name: verify the generated files
+        run: |
+          set -euo pipefail
+          # the pages are built from `--help` and `generate-config`, so a truncated
+          # build would silently produce an almost empty page
+          for dir in $TARGET_DIRS; do
+            echo "checking $dir"
+            grep -q 'gitea-runner \[command\]' "$dir/cli.md"
+            grep -q 'gitea-runner exec \[flags\]' "$dir/cli.md"
+            grep -q '^runner:' "$dir/config-example.md"
+          done
+      - name: push bot branch
+        id: bot_branch
+        env:
+          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
+        run: |
+          set -euo pipefail
+
+          if git diff --quiet -- $TARGET_DIRS; then
+            echo "the runner reference is already up to date"
+            echo "changed=false" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
+
+          if [ -z "$DEPLOY_TOKEN" ]; then
+            echo "secrets.DEPLOY_TOKEN is missing, cannot push the update"
+            exit 1
+          fi
+          remote="https://x-access-token:$DEPLOY_TOKEN@${GITHUB_SERVER_URL#*://}/$GITHUB_REPOSITORY.git"
+
+          # skip if an open bot branch already carries exactly these files
+          if git fetch --quiet --depth=1 "$remote" "refs/heads/$BOT_BRANCH" 2>/dev/null; then
+            if git diff --quiet FETCH_HEAD -- $TARGET_DIRS; then
+              echo "$BOT_BRANCH already proposes this runner reference"
+              echo "changed=false" >> "$GITHUB_OUTPUT"
+              exit 0
+            fi
+          fi
+
+          git config user.name "Gitea Bot"
+          git config user.email "[email protected]"
+          git switch --create "$BOT_BRANCH"
+          git add $TARGET_DIRS
+          git commit -m "Update the runner reference pages"
+          # force push: the branch is always rebuilt on top of the current main
+          git push --force "$remote" "HEAD:refs/heads/$BOT_BRANCH"
+          echo "changed=true" >> "$GITHUB_OUTPUT"
+      - name: create pull request
+        if: steps.bot_branch.outputs.changed == 'true'
+        env:
+          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
+        run: |
+          set -euo pipefail
+
+          cat > pull.json <<EOF
+          {
+            "base": "$BASE_BRANCH",
+            "head": "$BOT_BRANCH",
+            "title": "Update the runner reference pages",
+            "body": "Automated update of the generated runner reference pages from gitea/runner (main for the develop docs, the newest stable tag for every documented series), opened by the \"update runner reference\" scheduled workflow."
+          }
+          EOF
+
+          code="$(curl --silent --show-error --output pull-response.json --write-out '%{http_code}' \
+            -X POST "${GITHUB_API_URL:-$GITHUB_SERVER_URL/api/v1}/repos/$GITHUB_REPOSITORY/pulls" \
+            -H "Authorization: token $DEPLOY_TOKEN" \
+            -H 'Content-Type: application/json' \
+            --data @pull.json)"
+
+          case "$code" in
+            201) echo "pull request created" ;;
+            409) echo "an open pull request for $BOT_BRANCH already exists, it now points at the new commit" ;;
+            *) echo "unexpected response $code:"; cat pull-response.json; exit 1 ;;
+          esac

.gitea/workflows/update_swagger.yaml

@@ -1,28 +1,110 @@
-name: update swagger files
+name: update api spec files
 
 on:
   schedule:
     - cron:  '0 */12 * * *' # every 12 hours on the hour
   workflow_dispatch:
 
+env:
+  # main is protected, so the update is proposed as a pull request from this branch
+  BOT_BRANCH: bot/update-swagger-latest
+  BASE_BRANCH: main
+  # the documents of the gitea main branch, refreshed by this job
+  LATEST_FILES: static/swagger-latest.json static/openapi3-latest.json
+
 jobs:
   update-swagger:
+    if: github.repository == 'gitea/docs'
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v4
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
-      - run: |
+        with:
-          wget https://github.com/go-gitea/gitea/blob/main/templates/swagger/v1_json.tmpl
+          ref: main
-          sed -i "$@" 's/"version": "{{AppVer | JSEscape | Safe}}"/"version": "dev"/' static/swagger-latest.json
+          # pushing uses DEPLOY_TOKEN, keep the ephemeral job token out of .git/config
-          rm v1_json.tmpl
+          persist-credentials: false
+      - name: regenerate the latest api documents
+        run: make update-api-docs-latest
+      - name: verify the generated file
+        run: |
+          set -euo pipefail
+          for file in $LATEST_FILES; do
+            # placeholders must have been replaced, otherwise upstream changed them again
+            if grep -q -e 'GITEA-API-APP' -e '{{' "$file"; then
+              echo "$file still contains template placeholders"
+              exit 1
+            fi
+            if command -v python3 >/dev/null 2>&1; then
+              python3 -c "import json,sys; json.load(open(sys.argv[1]))" "$file"
+            fi
+          done
+      - name: push bot branch
+        id: bot_branch
+        env:
+          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
+        run: |
+          set -euo pipefail
 
-          wget https://github.com/go-gitea/gitea/blob/v1.22.4/templates/swagger/v1_json.tmpl
+          if git diff --quiet -- $LATEST_FILES; then
-          sed -i "$@" 's/"version": "{{AppVer | JSEscape | Safe}}"/"version": "1.22.6"/' static/swagger-22.json
+            echo "the api documents are already up to date"
-          rm v1_json.tmpl
+            echo "changed=false" >> "$GITHUB_OUTPUT"
+            exit 0
+          fi
 
-          if ! [[ $(git diff --shortstat) ]]; then exit 0; fi
+          if [ -z "$DEPLOY_TOKEN" ]; then
-          git config --global user.name "Gitea Bot"
+            echo "secrets.DEPLOY_TOKEN is missing, cannot push the update"
-          git config --global user.email "[email protected]"
+            exit 1
-          git remote set-url origin https://x-access-token:${{ secrets.DEPLOY_TOKEN }}@gitea.com/gitea/docs.git
+          fi
-          git add --all
+          remote="https://x-access-token:$DEPLOY_TOKEN@${GITHUB_SERVER_URL#*://}/$GITHUB_REPOSITORY.git"
-          git commit -m "[skip ci] Updated swagger files"
+
-          git push
+          # skip if an open bot branch already carries exactly this file
+          if git fetch --quiet --depth=1 "$remote" "refs/heads/$BOT_BRANCH" 2>/dev/null; then
+            same=true
+            for file in $LATEST_FILES; do
+              old_blob="$(git rev-parse --quiet --verify "FETCH_HEAD:$file" || true)"
+              if [ "$old_blob" != "$(git hash-object "$file")" ]; then
+                same=false
+                break
+              fi
+            done
+            if [ "$same" = true ]; then
+              echo "$BOT_BRANCH already proposes these api documents"
+              echo "changed=false" >> "$GITHUB_OUTPUT"
+              exit 0
+            fi
+          fi
+
+          git config user.name "Gitea Bot"
+          git config user.email "[email protected]"
+          git switch --create "$BOT_BRANCH"
+          git add $LATEST_FILES
+          git commit -m "Update the latest api documents"
+          # force push: the branch is always rebuilt on top of the current main
+          git push --force "$remote" "HEAD:refs/heads/$BOT_BRANCH"
+          echo "changed=true" >> "$GITHUB_OUTPUT"
+      - name: create pull request
+        if: steps.bot_branch.outputs.changed == 'true'
+        env:
+          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
+        run: |
+          set -euo pipefail
+
+          cat > pull.json <<EOF
+          {
+            "base": "$BASE_BRANCH",
+            "head": "$BOT_BRANCH",
+            "title": "Update the latest api documents",
+            "body": "Automated update of static/swagger-latest.json and static/openapi3-latest.json from the gitea main branch, opened by the \"update api spec files\" scheduled workflow."
+          }
+          EOF
+
+          code="$(curl --silent --show-error --output pull-response.json --write-out '%{http_code}' \
+            -X POST "${GITHUB_API_URL:-$GITHUB_SERVER_URL/api/v1}/repos/$GITHUB_REPOSITORY/pulls" \
+            -H "Authorization: token $DEPLOY_TOKEN" \
+            -H 'Content-Type: application/json' \
+            --data @pull.json)"
+
+          case "$code" in
+            201) echo "pull request created" ;;
+            409) echo "an open pull request for $BOT_BRANCH already exists, it now points at the new commit" ;;
+            *) echo "unexpected response $code:"; cat pull-response.json; exit 1 ;;
+          esac

.gitignore

@@ -1,12 +1,12 @@
 # Dependencies
-/node_modules
+node_modules
 
-# Production
+# Build output
-/build
+sites/*/dist
-
+sites/*/.astro
-# Generated files
+sites/*/.cache
-.docusaurus
+build/
-.cache-loader
+.docusaurus/
 
 # Misc
 .DS_Store
@@ -20,4 +20,5 @@ yarn-debug.log*
 yarn-error.log*
 
 .tmp/
+awesome/
 awesome.md

.npmrc

@@ -1,5 +0,0 @@
-audit=false
-fund=false
-update-notifier=false
-package-lock=true
-lockfile-version=3

Makefile

@@ -1,5 +1,3 @@
-export NODE_OPTIONS := "--max-old-space-size=8192"
-
 GITEA_AWESOME_REMOTE := https://gitea.com/gitea/awesome-gitea.git
 GITEA_AWESOME_BRANCH := main
 
@@ -8,7 +6,7 @@ all: build
 
 .PHONY: create_dir
 create_dir:
-	mkdir -p .tmp awesome
+	mkdir -p .tmp
 
 .PHONY: clone_awesome
 clone_awesome: create_dir
@@ -24,29 +22,69 @@ prepare-awesome\#%:
 
 .PHONY: install
 install:
-	npm install
+	pnpm install
 
 .PHONY: prepare-docs
-prepare-docs: install prepare-awesome-latest prepare-awesome\#19 prepare-awesome\#20 prepare-awesome\#21 prepare-awesome\#22
+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:
-	npm run build
+	pnpm run build
+
+# type checks the astro site and its components
+.PHONY: check
+check:
+	pnpm run check
 
 .PHONY: serve
 serve: prepare-docs
-	npm run start
+	pnpm run dev
 
-.PHONY: serve-zh
+# only the english docs of the version served at the root, plus the runner:
-serve-zh: prepare-docs
+# starts in a few seconds instead of loading the whole matrix
-	npm run start -- --locale zh-cn
+.PHONY: serve-fast
+serve-fast:
+	pnpm run dev:en-latest
+
+# search is built by pagefind at build time, so it is only available on the
+# built site; this serves it locally
+.PHONY: serve-built
+serve-built: build
+	pnpm run preview
 
 .PHONY: clean
 clean:
 	rm -rf .tmp
-	rm -rf static/_*
+	rm -rf sites/docs/dist
-	rm -rf static/swagger-latest.json
+	rm -rf sites/docs/.cache
-	rm -rf static/swagger-19.json
+	rm -rf sites/docs/node_modules/.astro
-	rm -rf static/swagger-20.json
+
-	rm -rf static/swagger-21.json
+# static/swagger-*.json and static/openapi3-*.json are committed files, use
-	rm -rf static/swagger-22.json
+# update-api-docs to refresh them
+.PHONY: update-api-docs
+update-api-docs:
+	./update_api_docs.sh
+
+# only refresh the documents of the gitea main branch (used by the cron job)
+.PHONY: update-api-docs-latest
+update-api-docs-latest:
+	./update_api_docs.sh --latest-only
+
+# regenerate the generated runner reference pages of the develop docs from the
+# main branch of gitea/runner (used by the update runner reference cron job)
+.PHONY: update-runner-docs
+update-runner-docs:
+	./update_runner_docs.sh main runner-docs/reference
+
+# same, for every documented release series: the tags are looked up through the
+# Gitea API, so a runner release needs no change here
+.PHONY: update-runner-docs-released
+update-runner-docs-released:
+	./update_runner_docs.sh --released
+
+# freezes the current docs or runner tree as a new version, see
+# scripts/cut-version.mjs
+.PHONY: cut-version
+cut-version:
+	@test -n "$(PRODUCT)" -a -n "$(VERSION)" || { echo 'usage: make cut-version PRODUCT=docs VERSION=1.28'; exit 1; }
+	node scripts/cut-version.mjs $(PRODUCT) $(VERSION)

README.md

@@ -1,23 +1,126 @@
 # Gitea Docs ![badge](https://gitea.com/gitea/docs/actions/workflows/build-and-publish.yaml/badge.svg)
 
-## How to build
+The sources of [docs.gitea.com](https://docs.gitea.com), built with
+[Astro](https://astro.build) and [Starlight](https://starlight.astro.build).
 
-```shell
+The site covers three products, all served from this repository:
-make clean
+
-make prepare-docs
+| Product | Content | Versions | Languages |
-make build
+| --- | --- | --- | --- |
-```
+| 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
+routes to that deployment.
 
 ## Development
 
 ```shell
-make clean
+make install       # pnpm install
-make prepare-docs
+make serve-fast    # english, the version served at the root, starts in seconds
-make serve
+make serve         # the whole matrix, every version and language
+make build         # production build into sites/docs/dist
+make check         # type checks the site and its components
 ```
 
-## Test en version
+Search is built by Pagefind while the site is built, so it only answers on the
+built site: use `make serve-built` to try it. With the Algolia credentials
+(`PUBLIC_DOCSEARCH_APP_ID`, `PUBLIC_DOCSEARCH_API_KEY`) set, DocSearch is used
+instead and works in `make serve` too.
+
+`GITEA_DOCS_PRODUCTS`, `GITEA_DOCS_VERSIONS` and `GITEA_DOCS_LOCALES` (comma
+separated) restrict what is built, which is what `make serve-fast` uses.
+`GITEA_DOCS_STRICT_LINKS=true` turns the warnings about unresolved relative
+markdown links into a build error.
+
+`sites/docs/README.md` documents how the sources are mapped onto the site.
+
+## Writing
+
+Pages are plain markdown with the same frontmatter and admonitions as before:
+frontmatter `slug`, `sidebar_position` and `sidebar_label` keep working, and so
+do the `:::note` style admonitions and the `@version@` style release variables.
+Relative `*.md` links are rewritten to urls while the site is built.
+
+The order of the top level sidebar groups comes from `sidebars.js` (and
+`versioned_sidebars/` for released versions), the label and order of every other
+group from the `_category_.json` of its directory.
+
+## Cutting a version
 
 ```shell
-npm run start
+make cut-version PRODUCT=docs VERSION=1.28
+make cut-version PRODUCT=runner VERSION=4
 ```
+
+This freezes the current tree, its translations and its sidebar. The label of
+the version, its release variables (`@version@`, `@dockerVersion@`, ...) and
+which version is served at the root live in
+`packages/content-loader/src/products.ts` and are edited by hand afterwards.
+That file is the single source of truth for the product, version and language
+matrix.
+
+## API docs
+
+The definitions rendered under `/api/` live in `static/`:
+`swagger-latest.json` (gitea main) and `swagger-<minor>.json` (released
+versions) hold the swagger 2.0 document every gitea version ships,
+`openapi3-latest.json` and `openapi3-<minor>.json` the openapi 3.0 document
+gitea generates since 1.27. The openapi 3.0 document is what gets rendered
+where it exists, and both are offered for download on the overview page of the
+version, since code generators cannot read the rendered pages (and several of
+them reject swagger 2.0).
+
+```shell
+make update-api-docs         # refresh latest + every released version
+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 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.
+
+## Runner docs
+
+| Version | Content | URL |
+| --- | --- | --- |
+| develop | `runner-docs/` | `/runner/develop/` |
+| 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
+folder. Use floating image tags (`gitea/runner:3`) and links to the runner's
+`main` branch in those pages to keep them valid across patch releases.
+
+Its sidebar is written by hand: `runner-sidebars.js` for develop, and
+`runner-docs_versioned_sidebars/version-<version>-sidebars.json` per documented
+version.
+
+The pages under `reference/` are generated from the runner sources — the command
+line reference from `--help`, the example configuration from `generate-config`:
+
+```shell
+make update-runner-docs           # develop docs, from the main branch of gitea/runner
+make update-runner-docs-released  # every series, from its newest stable tag
+./update_runner_docs.sh v3.0.2 runner-docs_versioned_docs/version-3/reference
+```
+
+These are refreshed automatically as well: the `update runner reference`
+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.
+
+## Deployment
+
+`main` is built and published by the `Build and Publish Docs site` workflow, to
+S3/CloudFront and to Cloudflare Pages. `cloudflare/_headers` sets the cache
+policy and `cloudflare/_redirects` keeps the urls the site used to serve; both
+are copied next to the build output by that workflow.
+`cloudflare/docsearch-crawler.json` is the Algolia crawler configuration.
+
+`/enterprise/` is served by another deployment and routed to it by a Cloudflare
+worker that lives outside this repository.

babel.config.js

@@ -1,3 +0,0 @@
-module.exports = {
-  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
-};

cloudflare/_headers

@@ -0,0 +1,24 @@
+# Cloudflare Pages reads this file from the root of the deployed directory. It
+# 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.
+#
+# 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.
+/_astro/*
+  Cache-Control: public, max-age=31536000, immutable
+
+# Files under public/img and public/images keep stable names and are replaced in
+# place, so they get a short, conservative max-age instead.
+/img/*
+  Cache-Control: public, max-age=86400
+
+/images/*
+  Cache-Control: public, max-age=86400
+
+# The pagefind index, only present when the site is built without algolia
+# docsearch. Content hashed as well.
+/pagefind/*
+  Cache-Control: public, max-age=31536000, immutable

cloudflare/_redirects

@@ -0,0 +1,458 @@
+# Redirects for legacy URLs and routes the site no longer serves directly.
+
+# 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
+
+# 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/1.27/* /api/:splat 301
+/runner/3/* /runner/: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.
+/search /  301
+/zh-cn/search /zh-cn/ 301
+/zh-tw/search /zh-tw/ 301
+
+# Pages that moved when the docs were reorganized: the flat `/usage/webhooks`,
+# `/advanced/...` and `/developers/...` layout of 1.19 and 1.20, and
+# `/help/seek-help`. Those urls kept working until the site moved to Cloudflare
+# because it was published with `aws s3 sync` without `--delete`, so the pages
+# built before the move were never removed from the bucket. Only what the build
+# emits is served now, and gitea itself and blog.gitea.com still link to some of
+# them, so they are redirected here.
+/actions                                          /usage/actions/ 301
+/actions/                                         /usage/actions/ 301
+/administration                                   /category/administration/ 301
+/administration/                                  /category/administration/ 301
+/administration/logging-configuration             /administration/logging-config/ 301
+/advanced/adding-legal-pages                      /administration/adding-legal-pages/ 301
+/advanced/clone-filters                           /usage/repository/clone-filters/ 301
+/advanced/cmd-embedded                            /administration/cmd-embedded/ 301
+/advanced/config-cheat-sheet                      /administration/config-cheat-sheet/ 301
+/advanced/customizing-gitea                       /administration/customizing-gitea/ 301
+/advanced/environment-variables                   /administration/environment-variables/ 301
+/advanced/external-renderers                      /administration/external-renderers/ 301
+/advanced/logging-configuration                   /administration/logging-config/ 301
+/advanced/mail-templates                          /administration/mail-templates/ 301
+/advanced/protected-tags                          /usage/access-control/protected-tags/ 301
+/advanced/repo-indexer                            /administration/repo-indexer/ 301
+/advanced/repo-mirror                             /usage/repository/repo-mirror/ 301
+/advanced/search-engines-indexation               /administration/search-engines-indexation/ 301
+/advanced/signing                                 /administration/signing/ 301
+/developers/api-usage                             /development/api-usage/ 301
+/developers/integrations                          /development/integrations/ 301
+/developers/migrations-interfaces                 /development/migrations-interfaces/ 301
+/developers/oauth2-provider                       /development/oauth2-provider/ 301
+/development                                      /category/development/ 301
+/development/                                     /category/development/ 301
+/features/authentication                          /administration/authentication/ 301
+/features/comparison                              /installation/comparison/ 301
+/features/webhooks                                /usage/repository/webhooks/ 301
+/help                                             /category/help/ 301
+/help/                                            /category/help/ 301
+/help/seek-help                                   /help/support/ 301
+/installation                                     /category/installation/ 301
+/installation/                                    /category/installation/ 301
+/installation/upgrade-from-gogs                   /category/installation/ 301
+/upgrade/upgrade-from-gitea                       /installation/upgrade-from-gitea/ 301
+/upgrade/upgrade-from-gogs                        /category/installation/ 301
+/usage                                            /category/usage/ 301
+/usage/                                           /category/usage/ 301
+/usage/actions/act-runner                         /runner/ 301
+/usage/agit                                       /usage/issues-prs/agit/ 301
+/usage/agit-setup                                 /usage/issues-prs/agit/ 301
+/usage/authentication                             /administration/authentication/ 301
+/usage/automatically-linked-references            /usage/issues-prs/automatically-linked-references/ 301
+/usage/badge                                      /usage/actions/badge/ 301
+/usage/blame                                      /usage/repository/blame/ 301
+/usage/blocking-user                              /usage/access-control/blocking-user/ 301
+/usage/clone-filters                              /usage/repository/clone-filters/ 301
+/usage/code-owners                                /usage/repository/code-owners/ 301
+/usage/command-line                               /administration/command-line/ 301
+/usage/email-setup                                /administration/email-setup/ 301
+/usage/git-lfs-setup                              /administration/git-lfs-setup/ 301
+/usage/https-setup                                /administration/https-setup/ 301
+/usage/incoming-email                             /usage/repository/incoming-email/ 301
+/usage/issue-pull-request-templates               /usage/issues-prs/issue-pull-request-templates/ 301
+/usage/labels                                     /usage/issues-prs/labels/ 301
+/usage/markdown                                   /usage/repository/markdown/ 301
+/usage/merge-message-templates                    /usage/issues-prs/merge-message-templates/ 301
+/usage/migration                                  /usage/repository/migration/ 301
+/usage/multi-factor-authentication                /usage/user-setting/multi-factor-authentication/ 301
+/usage/permissions                                /usage/access-control/permissions/ 301
+/usage/profile-readme                             /usage/repository/profile-readme/ 301
+/usage/protected-tags                             /usage/access-control/protected-tags/ 301
+/usage/pull-request                               /usage/issues-prs/pull-request/ 301
+/usage/push                                       /usage/repository/push/ 301
+/usage/push-options                               /usage/repository/push/ 301
+/usage/push-to-create                             /usage/repository/push/ 301
+/usage/repo-mirror                                /usage/repository/repo-mirror/ 301
+/usage/secrets                                    /usage/actions/secrets/ 301
+/usage/template-repositories                      /usage/repository/template-repositories/ 301
+/usage/webhooks                                   /usage/repository/webhooks/ 301
+
+# ... and under simplified chinese.
+/zh-cn/actions                                    /zh-cn/usage/actions/ 301
+/zh-cn/actions/                                   /zh-cn/usage/actions/ 301
+/zh-cn/administration                             /zh-cn/category/administration/ 301
+/zh-cn/administration/                            /zh-cn/category/administration/ 301
+/zh-cn/administration/logging-configuration       /zh-cn/administration/logging-config/ 301
+/zh-cn/advanced/adding-legal-pages                /zh-cn/administration/adding-legal-pages/ 301
+/zh-cn/advanced/clone-filters                     /zh-cn/usage/repository/clone-filters/ 301
+/zh-cn/advanced/cmd-embedded                      /zh-cn/administration/cmd-embedded/ 301
+/zh-cn/advanced/config-cheat-sheet                /zh-cn/administration/config-cheat-sheet/ 301
+/zh-cn/advanced/customizing-gitea                 /zh-cn/administration/customizing-gitea/ 301
+/zh-cn/advanced/environment-variables             /zh-cn/administration/environment-variables/ 301
+/zh-cn/advanced/external-renderers                /zh-cn/administration/external-renderers/ 301
+/zh-cn/advanced/logging-configuration             /zh-cn/administration/logging-config/ 301
+/zh-cn/advanced/mail-templates                    /zh-cn/administration/mail-templates/ 301
+/zh-cn/advanced/protected-tags                    /zh-cn/usage/access-control/protected-tags/ 301
+/zh-cn/advanced/repo-indexer                      /zh-cn/administration/repo-indexer/ 301
+/zh-cn/advanced/repo-mirror                       /zh-cn/usage/repository/repo-mirror/ 301
+/zh-cn/advanced/search-engines-indexation         /zh-cn/administration/search-engines-indexation/ 301
+/zh-cn/advanced/signing                           /zh-cn/administration/signing/ 301
+/zh-cn/developers/api-usage                       /zh-cn/development/api-usage/ 301
+/zh-cn/developers/integrations                    /zh-cn/development/integrations/ 301
+/zh-cn/developers/migrations-interfaces           /zh-cn/development/migrations-interfaces/ 301
+/zh-cn/developers/oauth2-provider                 /zh-cn/development/oauth2-provider/ 301
+/zh-cn/development                                /zh-cn/category/development/ 301
+/zh-cn/development/                               /zh-cn/category/development/ 301
+/zh-cn/features/authentication                    /zh-cn/administration/authentication/ 301
+/zh-cn/features/comparison                        /zh-cn/installation/comparison/ 301
+/zh-cn/features/webhooks                          /zh-cn/usage/repository/webhooks/ 301
+/zh-cn/help                                       /zh-cn/category/help/ 301
+/zh-cn/help/                                      /zh-cn/category/help/ 301
+/zh-cn/help/seek-help                             /zh-cn/help/support/ 301
+/zh-cn/installation                               /zh-cn/category/installation/ 301
+/zh-cn/installation/                              /zh-cn/category/installation/ 301
+/zh-cn/installation/upgrade-from-gogs             /zh-cn/category/installation/ 301
+/zh-cn/upgrade/upgrade-from-gitea                 /zh-cn/installation/upgrade-from-gitea/ 301
+/zh-cn/upgrade/upgrade-from-gogs                  /zh-cn/category/installation/ 301
+/zh-cn/usage                                      /zh-cn/category/usage/ 301
+/zh-cn/usage/                                     /zh-cn/category/usage/ 301
+/zh-cn/usage/actions/act-runner                   /runner/ 301
+/zh-cn/usage/agit-setup                           /zh-cn/usage/issues-prs/agit/ 301
+/zh-cn/usage/authentication                       /zh-cn/administration/authentication/ 301
+/zh-cn/usage/automatically-linked-references      /zh-cn/usage/issues-prs/automatically-linked-references/ 301
+/zh-cn/usage/badge                                /zh-cn/usage/actions/badge/ 301
+/zh-cn/usage/blame                                /zh-cn/usage/repository/blame/ 301
+/zh-cn/usage/blocking-user                        /zh-cn/usage/access-control/blocking-user/ 301
+/zh-cn/usage/clone-filters                        /zh-cn/usage/repository/clone-filters/ 301
+/zh-cn/usage/code-owners                          /zh-cn/usage/repository/code-owners/ 301
+/zh-cn/usage/command-line                         /zh-cn/administration/command-line/ 301
+/zh-cn/usage/email-setup                          /zh-cn/administration/email-setup/ 301
+/zh-cn/usage/git-lfs-setup                        /zh-cn/administration/git-lfs-setup/ 301
+/zh-cn/usage/https-setup                          /zh-cn/administration/https-setup/ 301
+/zh-cn/usage/incoming-email                       /zh-cn/usage/repository/incoming-email/ 301
+/zh-cn/usage/issue-pull-request-templates         /zh-cn/usage/issues-prs/issue-pull-request-templates/ 301
+/zh-cn/usage/labels                               /zh-cn/usage/issues-prs/labels/ 301
+/zh-cn/usage/markdown                             /zh-cn/usage/repository/markdown/ 301
+/zh-cn/usage/merge-message-templates              /zh-cn/usage/issues-prs/merge-message-templates/ 301
+/zh-cn/usage/migration                            /zh-cn/usage/repository/migration/ 301
+/zh-cn/usage/multi-factor-authentication          /zh-cn/usage/user-setting/multi-factor-authentication/ 301
+/zh-cn/usage/permissions                          /zh-cn/usage/access-control/permissions/ 301
+/zh-cn/usage/profile-readme                       /zh-cn/usage/repository/profile-readme/ 301
+/zh-cn/usage/protected-tags                       /zh-cn/usage/access-control/protected-tags/ 301
+/zh-cn/usage/pull-request                         /zh-cn/usage/issues-prs/pull-request/ 301
+/zh-cn/usage/push                                 /zh-cn/usage/repository/push/ 301
+/zh-cn/usage/push-options                         /zh-cn/usage/repository/push/ 301
+/zh-cn/usage/push-to-create                       /zh-cn/usage/repository/push/ 301
+/zh-cn/usage/repo-mirror                          /zh-cn/usage/repository/repo-mirror/ 301
+/zh-cn/usage/secrets                              /zh-cn/usage/actions/secrets/ 301
+/zh-cn/usage/template-repositories                /zh-cn/usage/repository/template-repositories/ 301
+/zh-cn/usage/webhooks                             /zh-cn/usage/repository/webhooks/ 301
+
+# ... and under traditional chinese.
+/zh-tw/actions                                    /zh-tw/usage/actions/ 301
+/zh-tw/actions/                                   /zh-tw/usage/actions/ 301
+/zh-tw/administration                             /zh-tw/category/administration/ 301
+/zh-tw/administration/                            /zh-tw/category/administration/ 301
+/zh-tw/administration/logging-configuration       /zh-tw/administration/logging-config/ 301
+/zh-tw/advanced/adding-legal-pages                /zh-tw/administration/adding-legal-pages/ 301
+/zh-tw/advanced/clone-filters                     /zh-tw/usage/repository/clone-filters/ 301
+/zh-tw/advanced/cmd-embedded                      /zh-tw/administration/cmd-embedded/ 301
+/zh-tw/advanced/config-cheat-sheet                /zh-tw/administration/config-cheat-sheet/ 301
+/zh-tw/advanced/customizing-gitea                 /zh-tw/administration/customizing-gitea/ 301
+/zh-tw/advanced/environment-variables             /zh-tw/administration/environment-variables/ 301
+/zh-tw/advanced/external-renderers                /zh-tw/administration/external-renderers/ 301
+/zh-tw/advanced/logging-configuration             /zh-tw/administration/logging-config/ 301
+/zh-tw/advanced/mail-templates                    /zh-tw/administration/mail-templates/ 301
+/zh-tw/advanced/protected-tags                    /zh-tw/usage/access-control/protected-tags/ 301
+/zh-tw/advanced/repo-indexer                      /zh-tw/administration/repo-indexer/ 301
+/zh-tw/advanced/repo-mirror                       /zh-tw/usage/repository/repo-mirror/ 301
+/zh-tw/advanced/search-engines-indexation         /zh-tw/administration/search-engines-indexation/ 301
+/zh-tw/advanced/signing                           /zh-tw/administration/signing/ 301
+/zh-tw/developers/api-usage                       /zh-tw/development/api-usage/ 301
+/zh-tw/developers/integrations                    /zh-tw/development/integrations/ 301
+/zh-tw/developers/migrations-interfaces           /zh-tw/development/migrations-interfaces/ 301
+/zh-tw/developers/oauth2-provider                 /zh-tw/development/oauth2-provider/ 301
+/zh-tw/development                                /zh-tw/category/development/ 301
+/zh-tw/development/                               /zh-tw/category/development/ 301
+/zh-tw/features/authentication                    /zh-tw/administration/authentication/ 301
+/zh-tw/features/comparison                        /zh-tw/installation/comparison/ 301
+/zh-tw/features/webhooks                          /zh-tw/usage/repository/webhooks/ 301
+/zh-tw/help                                       /zh-tw/category/help/ 301
+/zh-tw/help/                                      /zh-tw/category/help/ 301
+/zh-tw/help/seek-help                             /zh-tw/help/support/ 301
+/zh-tw/installation                               /zh-tw/category/installation/ 301
+/zh-tw/installation/                              /zh-tw/category/installation/ 301
+/zh-tw/installation/upgrade-from-gogs             /zh-tw/category/installation/ 301
+/zh-tw/upgrade/upgrade-from-gitea                 /zh-tw/installation/upgrade-from-gitea/ 301
+/zh-tw/upgrade/upgrade-from-gogs                  /zh-tw/category/installation/ 301
+/zh-tw/usage                                      /zh-tw/category/usage/ 301
+/zh-tw/usage/                                     /zh-tw/category/usage/ 301
+/zh-tw/usage/actions/act-runner                   /runner/ 301
+/zh-tw/usage/agit-setup                           /zh-tw/usage/issues-prs/agit/ 301
+/zh-tw/usage/authentication                       /zh-tw/administration/authentication/ 301
+/zh-tw/usage/automatically-linked-references      /zh-tw/usage/issues-prs/automatically-linked-references/ 301
+/zh-tw/usage/badge                                /zh-tw/usage/actions/badge/ 301
+/zh-tw/usage/blame                                /zh-tw/usage/repository/blame/ 301
+/zh-tw/usage/blocking-user                        /zh-tw/usage/access-control/blocking-user/ 301
+/zh-tw/usage/clone-filters                        /zh-tw/usage/repository/clone-filters/ 301
+/zh-tw/usage/code-owners                          /zh-tw/usage/repository/code-owners/ 301
+/zh-tw/usage/command-line                         /zh-tw/administration/command-line/ 301
+/zh-tw/usage/email-setup                          /zh-tw/administration/email-setup/ 301
+/zh-tw/usage/git-lfs-setup                        /zh-tw/administration/git-lfs-setup/ 301
+/zh-tw/usage/https-setup                          /zh-tw/administration/https-setup/ 301
+/zh-tw/usage/incoming-email                       /zh-tw/usage/repository/incoming-email/ 301
+/zh-tw/usage/issue-pull-request-templates         /zh-tw/usage/issues-prs/issue-pull-request-templates/ 301
+/zh-tw/usage/labels                               /zh-tw/usage/issues-prs/labels/ 301
+/zh-tw/usage/markdown                             /zh-tw/usage/repository/markdown/ 301
+/zh-tw/usage/merge-message-templates              /zh-tw/usage/issues-prs/merge-message-templates/ 301
+/zh-tw/usage/migration                            /zh-tw/usage/repository/migration/ 301
+/zh-tw/usage/multi-factor-authentication          /zh-tw/usage/user-setting/multi-factor-authentication/ 301
+/zh-tw/usage/permissions                          /zh-tw/usage/access-control/permissions/ 301
+/zh-tw/usage/protected-tags                       /zh-tw/usage/access-control/protected-tags/ 301
+/zh-tw/usage/pull-request                         /zh-tw/usage/issues-prs/pull-request/ 301
+/zh-tw/usage/push                                 /zh-tw/usage/repository/push/ 301
+/zh-tw/usage/push-options                         /zh-tw/usage/repository/push/ 301
+/zh-tw/usage/push-to-create                       /zh-tw/usage/repository/push/ 301
+/zh-tw/usage/repo-mirror                          /zh-tw/usage/repository/repo-mirror/ 301
+/zh-tw/usage/secrets                              /zh-tw/usage/actions/secrets/ 301
+/zh-tw/usage/template-repositories                /zh-tw/usage/repository/template-repositories/ 301
+/zh-tw/usage/webhooks                             /zh-tw/usage/repository/webhooks/ 301
+
+# ... and under the develop version.
+/next/actions                                     /next/usage/actions/ 301
+/next/actions/                                    /next/usage/actions/ 301
+/next/administration                              /next/category/administration/ 301
+/next/administration/                             /next/category/administration/ 301
+/next/administration/logging-configuration        /next/administration/logging-config/ 301
+/next/advanced/adding-legal-pages                 /next/administration/adding-legal-pages/ 301
+/next/advanced/clone-filters                      /next/usage/repository/clone-filters/ 301
+/next/advanced/cmd-embedded                       /next/administration/cmd-embedded/ 301
+/next/advanced/config-cheat-sheet                 /next/administration/config-cheat-sheet/ 301
+/next/advanced/customizing-gitea                  /next/administration/customizing-gitea/ 301
+/next/advanced/environment-variables              /next/administration/environment-variables/ 301
+/next/advanced/external-renderers                 /next/administration/external-renderers/ 301
+/next/advanced/logging-configuration              /next/administration/logging-config/ 301
+/next/advanced/mail-templates                     /next/administration/mail-templates/ 301
+/next/advanced/protected-tags                     /next/usage/access-control/protected-tags/ 301
+/next/advanced/repo-indexer                       /next/administration/repo-indexer/ 301
+/next/advanced/repo-mirror                        /next/usage/repository/repo-mirror/ 301
+/next/advanced/search-engines-indexation          /next/administration/search-engines-indexation/ 301
+/next/advanced/signing                            /next/administration/signing/ 301
+/next/developers/api-usage                        /next/development/api-usage/ 301
+/next/developers/integrations                     /next/development/integrations/ 301
+/next/developers/migrations-interfaces            /next/development/migrations-interfaces/ 301
+/next/developers/oauth2-provider                  /next/development/oauth2-provider/ 301
+/next/development                                 /next/category/development/ 301
+/next/development/                                /next/category/development/ 301
+/next/features/authentication                     /next/administration/authentication/ 301
+/next/features/comparison                         /next/installation/comparison/ 301
+/next/features/webhooks                           /next/usage/repository/webhooks/ 301
+/next/help                                        /next/category/help/ 301
+/next/help/                                       /next/category/help/ 301
+/next/help/seek-help                              /next/help/support/ 301
+/next/installation                                /next/category/installation/ 301
+/next/installation/                               /next/category/installation/ 301
+/next/installation/upgrade-from-gogs              /next/category/installation/ 301
+/next/upgrade/upgrade-from-gitea                  /next/installation/upgrade-from-gitea/ 301
+/next/upgrade/upgrade-from-gogs                   /next/category/installation/ 301
+/next/usage                                       /next/category/usage/ 301
+/next/usage/                                      /next/category/usage/ 301
+/next/usage/actions/act-runner                    /runner/ 301
+/next/usage/agit                                  /next/usage/issues-prs/agit/ 301
+/next/usage/agit-setup                            /next/usage/issues-prs/agit/ 301
+/next/usage/authentication                        /next/administration/authentication/ 301
+/next/usage/automatically-linked-references       /next/usage/issues-prs/automatically-linked-references/ 301
+/next/usage/badge                                 /next/usage/actions/badge/ 301
+/next/usage/blame                                 /next/usage/repository/blame/ 301
+/next/usage/blocking-user                         /next/usage/access-control/blocking-user/ 301
+/next/usage/clone-filters                         /next/usage/repository/clone-filters/ 301
+/next/usage/code-owners                           /next/usage/repository/code-owners/ 301
+/next/usage/command-line                          /next/administration/command-line/ 301
+/next/usage/email-setup                           /next/administration/email-setup/ 301
+/next/usage/git-lfs-setup                         /next/administration/git-lfs-setup/ 301
+/next/usage/https-setup                           /next/administration/https-setup/ 301
+/next/usage/incoming-email                        /next/usage/repository/incoming-email/ 301
+/next/usage/issue-pull-request-templates          /next/usage/issues-prs/issue-pull-request-templates/ 301
+/next/usage/labels                                /next/usage/issues-prs/labels/ 301
+/next/usage/markdown                              /next/usage/repository/markdown/ 301
+/next/usage/merge-message-templates               /next/usage/issues-prs/merge-message-templates/ 301
+/next/usage/migration                             /next/usage/repository/migration/ 301
+/next/usage/multi-factor-authentication           /next/usage/user-setting/multi-factor-authentication/ 301
+/next/usage/permissions                           /next/usage/access-control/permissions/ 301
+/next/usage/profile-readme                        /next/usage/repository/profile-readme/ 301
+/next/usage/protected-tags                        /next/usage/access-control/protected-tags/ 301
+/next/usage/pull-request                          /next/usage/issues-prs/pull-request/ 301
+/next/usage/push                                  /next/usage/repository/push/ 301
+/next/usage/push-options                          /next/usage/repository/push/ 301
+/next/usage/push-to-create                        /next/usage/repository/push/ 301
+/next/usage/repo-mirror                           /next/usage/repository/repo-mirror/ 301
+/next/usage/secrets                               /next/usage/actions/secrets/ 301
+/next/usage/template-repositories                 /next/usage/repository/template-repositories/ 301
+/next/usage/webhooks                              /next/usage/repository/webhooks/ 301
+
+# ... and under simplified chinese, develop.
+/zh-cn/next/actions                               /zh-cn/next/usage/actions/ 301
+/zh-cn/next/actions/                              /zh-cn/next/usage/actions/ 301
+/zh-cn/next/administration                        /zh-cn/next/category/administration/ 301
+/zh-cn/next/administration/                       /zh-cn/next/category/administration/ 301
+/zh-cn/next/administration/logging-configuration  /zh-cn/next/administration/logging-config/ 301
+/zh-cn/next/advanced/adding-legal-pages           /zh-cn/next/administration/adding-legal-pages/ 301
+/zh-cn/next/advanced/clone-filters                /zh-cn/next/usage/repository/clone-filters/ 301
+/zh-cn/next/advanced/cmd-embedded                 /zh-cn/next/administration/cmd-embedded/ 301
+/zh-cn/next/advanced/config-cheat-sheet           /zh-cn/next/administration/config-cheat-sheet/ 301
+/zh-cn/next/advanced/customizing-gitea            /zh-cn/next/administration/customizing-gitea/ 301
+/zh-cn/next/advanced/environment-variables        /zh-cn/next/administration/environment-variables/ 301
+/zh-cn/next/advanced/external-renderers           /zh-cn/next/administration/external-renderers/ 301
+/zh-cn/next/advanced/logging-configuration        /zh-cn/next/administration/logging-config/ 301
+/zh-cn/next/advanced/mail-templates               /zh-cn/next/administration/mail-templates/ 301
+/zh-cn/next/advanced/protected-tags               /zh-cn/next/usage/access-control/protected-tags/ 301
+/zh-cn/next/advanced/repo-indexer                 /zh-cn/next/administration/repo-indexer/ 301
+/zh-cn/next/advanced/repo-mirror                  /zh-cn/next/usage/repository/repo-mirror/ 301
+/zh-cn/next/advanced/search-engines-indexation    /zh-cn/next/administration/search-engines-indexation/ 301
+/zh-cn/next/advanced/signing                      /zh-cn/next/administration/signing/ 301
+/zh-cn/next/developers/api-usage                  /zh-cn/next/development/api-usage/ 301
+/zh-cn/next/developers/integrations               /zh-cn/next/development/integrations/ 301
+/zh-cn/next/developers/migrations-interfaces      /zh-cn/next/development/migrations-interfaces/ 301
+/zh-cn/next/developers/oauth2-provider            /zh-cn/next/development/oauth2-provider/ 301
+/zh-cn/next/development                           /zh-cn/next/category/development/ 301
+/zh-cn/next/development/                          /zh-cn/next/category/development/ 301
+/zh-cn/next/features/authentication               /zh-cn/next/administration/authentication/ 301
+/zh-cn/next/features/comparison                   /zh-cn/next/installation/comparison/ 301
+/zh-cn/next/features/webhooks                     /zh-cn/next/usage/repository/webhooks/ 301
+/zh-cn/next/help                                  /zh-cn/next/category/help/ 301
+/zh-cn/next/help/                                 /zh-cn/next/category/help/ 301
+/zh-cn/next/help/seek-help                        /zh-cn/next/help/support/ 301
+/zh-cn/next/installation                          /zh-cn/next/category/installation/ 301
+/zh-cn/next/installation/                         /zh-cn/next/category/installation/ 301
+/zh-cn/next/installation/upgrade-from-gogs        /zh-cn/next/category/installation/ 301
+/zh-cn/next/upgrade/upgrade-from-gitea            /zh-cn/next/installation/upgrade-from-gitea/ 301
+/zh-cn/next/upgrade/upgrade-from-gogs             /zh-cn/next/category/installation/ 301
+/zh-cn/next/usage                                 /zh-cn/next/category/usage/ 301
+/zh-cn/next/usage/                                /zh-cn/next/category/usage/ 301
+/zh-cn/next/usage/actions/act-runner              /runner/ 301
+/zh-cn/next/usage/agit-setup                      /zh-cn/next/usage/issues-prs/agit/ 301
+/zh-cn/next/usage/authentication                  /zh-cn/next/administration/authentication/ 301
+/zh-cn/next/usage/automatically-linked-references /zh-cn/next/usage/issues-prs/automatically-linked-references/ 301
+/zh-cn/next/usage/badge                           /zh-cn/next/usage/actions/badge/ 301
+/zh-cn/next/usage/blame                           /zh-cn/next/usage/repository/blame/ 301
+/zh-cn/next/usage/blocking-user                   /zh-cn/next/usage/access-control/blocking-user/ 301
+/zh-cn/next/usage/clone-filters                   /zh-cn/next/usage/repository/clone-filters/ 301
+/zh-cn/next/usage/code-owners                     /zh-cn/next/usage/repository/code-owners/ 301
+/zh-cn/next/usage/command-line                    /zh-cn/next/administration/command-line/ 301
+/zh-cn/next/usage/email-setup                     /zh-cn/next/administration/email-setup/ 301
+/zh-cn/next/usage/git-lfs-setup                   /zh-cn/next/administration/git-lfs-setup/ 301
+/zh-cn/next/usage/https-setup                     /zh-cn/next/administration/https-setup/ 301
+/zh-cn/next/usage/incoming-email                  /zh-cn/next/usage/repository/incoming-email/ 301
+/zh-cn/next/usage/issue-pull-request-templates    /zh-cn/next/usage/issues-prs/issue-pull-request-templates/ 301
+/zh-cn/next/usage/labels                          /zh-cn/next/usage/issues-prs/labels/ 301
+/zh-cn/next/usage/markdown                        /zh-cn/next/usage/repository/markdown/ 301
+/zh-cn/next/usage/merge-message-templates         /zh-cn/next/usage/issues-prs/merge-message-templates/ 301
+/zh-cn/next/usage/migration                       /zh-cn/next/usage/repository/migration/ 301
+/zh-cn/next/usage/multi-factor-authentication     /zh-cn/next/usage/user-setting/multi-factor-authentication/ 301
+/zh-cn/next/usage/permissions                     /zh-cn/next/usage/access-control/permissions/ 301
+/zh-cn/next/usage/profile-readme                  /zh-cn/next/usage/repository/profile-readme/ 301
+/zh-cn/next/usage/protected-tags                  /zh-cn/next/usage/access-control/protected-tags/ 301
+/zh-cn/next/usage/pull-request                    /zh-cn/next/usage/issues-prs/pull-request/ 301
+/zh-cn/next/usage/push                            /zh-cn/next/usage/repository/push/ 301
+/zh-cn/next/usage/push-options                    /zh-cn/next/usage/repository/push/ 301
+/zh-cn/next/usage/push-to-create                  /zh-cn/next/usage/repository/push/ 301
+/zh-cn/next/usage/repo-mirror                     /zh-cn/next/usage/repository/repo-mirror/ 301
+/zh-cn/next/usage/secrets                         /zh-cn/next/usage/actions/secrets/ 301
+/zh-cn/next/usage/template-repositories           /zh-cn/next/usage/repository/template-repositories/ 301
+/zh-cn/next/usage/webhooks                        /zh-cn/next/usage/repository/webhooks/ 301
+
+# ... and under traditional chinese, develop.
+/zh-tw/next/actions                               /zh-tw/next/usage/actions/ 301
+/zh-tw/next/actions/                              /zh-tw/next/usage/actions/ 301
+/zh-tw/next/administration                        /zh-tw/next/category/administration/ 301
+/zh-tw/next/administration/                       /zh-tw/next/category/administration/ 301
+/zh-tw/next/administration/logging-configuration  /zh-tw/next/administration/logging-config/ 301
+/zh-tw/next/advanced/adding-legal-pages           /zh-tw/next/administration/adding-legal-pages/ 301
+/zh-tw/next/advanced/clone-filters                /zh-tw/next/usage/repository/clone-filters/ 301
+/zh-tw/next/advanced/cmd-embedded                 /zh-tw/next/administration/cmd-embedded/ 301
+/zh-tw/next/advanced/config-cheat-sheet           /zh-tw/next/administration/config-cheat-sheet/ 301
+/zh-tw/next/advanced/customizing-gitea            /zh-tw/next/administration/customizing-gitea/ 301
+/zh-tw/next/advanced/environment-variables        /zh-tw/next/administration/environment-variables/ 301
+/zh-tw/next/advanced/external-renderers           /zh-tw/next/administration/external-renderers/ 301
+/zh-tw/next/advanced/logging-configuration        /zh-tw/next/administration/logging-config/ 301
+/zh-tw/next/advanced/mail-templates               /zh-tw/next/administration/mail-templates/ 301
+/zh-tw/next/advanced/protected-tags               /zh-tw/next/usage/access-control/protected-tags/ 301
+/zh-tw/next/advanced/repo-indexer                 /zh-tw/next/administration/repo-indexer/ 301
+/zh-tw/next/advanced/repo-mirror                  /zh-tw/next/usage/repository/repo-mirror/ 301
+/zh-tw/next/advanced/search-engines-indexation    /zh-tw/next/administration/search-engines-indexation/ 301
+/zh-tw/next/advanced/signing                      /zh-tw/next/administration/signing/ 301
+/zh-tw/next/developers/api-usage                  /zh-tw/next/development/api-usage/ 301
+/zh-tw/next/developers/integrations               /zh-tw/next/development/integrations/ 301
+/zh-tw/next/developers/migrations-interfaces      /zh-tw/next/development/migrations-interfaces/ 301
+/zh-tw/next/developers/oauth2-provider            /zh-tw/next/development/oauth2-provider/ 301
+/zh-tw/next/development                           /zh-tw/next/category/development/ 301
+/zh-tw/next/development/                          /zh-tw/next/category/development/ 301
+/zh-tw/next/features/authentication               /zh-tw/next/administration/authentication/ 301
+/zh-tw/next/features/comparison                   /zh-tw/next/installation/comparison/ 301
+/zh-tw/next/features/webhooks                     /zh-tw/next/usage/repository/webhooks/ 301
+/zh-tw/next/help                                  /zh-tw/next/category/help/ 301
+/zh-tw/next/help/                                 /zh-tw/next/category/help/ 301
+/zh-tw/next/help/seek-help                        /zh-tw/next/help/support/ 301
+/zh-tw/next/installation                          /zh-tw/next/category/installation/ 301
+/zh-tw/next/installation/                         /zh-tw/next/category/installation/ 301
+/zh-tw/next/installation/upgrade-from-gogs        /zh-tw/next/category/installation/ 301
+/zh-tw/next/upgrade/upgrade-from-gitea            /zh-tw/next/installation/upgrade-from-gitea/ 301
+/zh-tw/next/upgrade/upgrade-from-gogs             /zh-tw/next/category/installation/ 301
+/zh-tw/next/usage                                 /zh-tw/next/category/usage/ 301
+/zh-tw/next/usage/                                /zh-tw/next/category/usage/ 301
+/zh-tw/next/usage/actions/act-runner              /runner/ 301
+/zh-tw/next/usage/agit-setup                      /zh-tw/next/usage/issues-prs/agit/ 301
+/zh-tw/next/usage/authentication                  /zh-tw/next/administration/authentication/ 301
+/zh-tw/next/usage/automatically-linked-references /zh-tw/next/usage/issues-prs/automatically-linked-references/ 301
+/zh-tw/next/usage/badge                           /zh-tw/next/usage/actions/badge/ 301
+/zh-tw/next/usage/blame                           /zh-tw/next/usage/repository/blame/ 301
+/zh-tw/next/usage/blocking-user                   /zh-tw/next/usage/access-control/blocking-user/ 301
+/zh-tw/next/usage/clone-filters                   /zh-tw/next/usage/repository/clone-filters/ 301
+/zh-tw/next/usage/code-owners                     /zh-tw/next/usage/repository/code-owners/ 301
+/zh-tw/next/usage/command-line                    /zh-tw/next/administration/command-line/ 301
+/zh-tw/next/usage/email-setup                     /zh-tw/next/administration/email-setup/ 301
+/zh-tw/next/usage/git-lfs-setup                   /zh-tw/next/administration/git-lfs-setup/ 301
+/zh-tw/next/usage/https-setup                     /zh-tw/next/administration/https-setup/ 301
+/zh-tw/next/usage/incoming-email                  /zh-tw/next/usage/repository/incoming-email/ 301
+/zh-tw/next/usage/issue-pull-request-templates    /zh-tw/next/usage/issues-prs/issue-pull-request-templates/ 301
+/zh-tw/next/usage/labels                          /zh-tw/next/usage/issues-prs/labels/ 301
+/zh-tw/next/usage/markdown                        /zh-tw/next/usage/repository/markdown/ 301
+/zh-tw/next/usage/merge-message-templates         /zh-tw/next/usage/issues-prs/merge-message-templates/ 301
+/zh-tw/next/usage/migration                       /zh-tw/next/usage/repository/migration/ 301
+/zh-tw/next/usage/multi-factor-authentication     /zh-tw/next/usage/user-setting/multi-factor-authentication/ 301
+/zh-tw/next/usage/permissions                     /zh-tw/next/usage/access-control/permissions/ 301
+/zh-tw/next/usage/protected-tags                  /zh-tw/next/usage/access-control/protected-tags/ 301
+/zh-tw/next/usage/pull-request                    /zh-tw/next/usage/issues-prs/pull-request/ 301
+/zh-tw/next/usage/push                            /zh-tw/next/usage/repository/push/ 301
+/zh-tw/next/usage/push-options                    /zh-tw/next/usage/repository/push/ 301
+/zh-tw/next/usage/push-to-create                  /zh-tw/next/usage/repository/push/ 301
+/zh-tw/next/usage/repo-mirror                     /zh-tw/next/usage/repository/repo-mirror/ 301
+/zh-tw/next/usage/secrets                         /zh-tw/next/usage/actions/secrets/ 301
+/zh-tw/next/usage/template-repositories           /zh-tw/next/usage/repository/template-repositories/ 301
+/zh-tw/next/usage/webhooks                        /zh-tw/next/usage/repository/webhooks/ 301
+
+# Runner versions that were published under their full number, and the develop
+# runner docs, which used to be `next`.
+/runner/0.2.11/* /runner/0/:splat 301
+/runner/1.0.8/* /runner/1/:splat 301
+/runner/next/* /runner/develop/:splat 301

cloudflare/docsearch-crawler.json

@@ -0,0 +1,32 @@
+{
+  "_comment": "Algolia DocSearch crawler configuration. The three facets come from the docsearch:* meta tags every page carries; only the versions people read are indexed, the older ones stay reachable through the version picker.",
+  "index_name": "gitea",
+  "start_urls": [
+    "https://docs.gitea.com/",
+    "https://docs.gitea.com/next/",
+    "https://docs.gitea.com/zh-cn/",
+    "https://docs.gitea.com/zh-tw/",
+    "https://docs.gitea.com/runner/",
+    "https://docs.gitea.com/api/",
+    "https://docs.gitea.com/enterprise/"
+  ],
+  "sitemap_urls": ["https://docs.gitea.com/sitemap-index.xml"],
+  "exclusion_patterns": [
+    "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]/**"
+  ],
+  "selectors": {
+    "lvl0": { "selector": "//nav[contains(@aria-labelledby,'starlight__sidebar')]//a[@aria-current='page']/ancestor::details//summary//span", "type": "xpath", "global": true, "default_value": "Documentation" },
+    "lvl1": ".sl-markdown-content h1, h1",
+    "lvl2": ".sl-markdown-content h2",
+    "lvl3": ".sl-markdown-content h3",
+    "lvl4": ".sl-markdown-content h4",
+    "text": ".sl-markdown-content p, .sl-markdown-content li, .sl-markdown-content td"
+  },
+  "custom_settings": {
+    "attributesForFaceting": ["product", "version", "language"]
+  },
+  "conversation_id": []
+}

docs/administration/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Administration",
+  "position": 30,
+  "link": {
+    "type": "generated-index",
+    "slug": "/administration",
+    "title": "Administration"
+  }
+}

docs/administration/adding-legal-pages.md

@@ -12,10 +12,10 @@ Some jurisdictions (such as EU), requires certain legal pages (e.g. Privacy Poli
 
 ## Getting Pages
 
-Gitea source code ships with sample pages, available in `contrib/legal` directory. Copy them to `custom/public/assets/`. For example, to add Privacy Policy:
+Gitea source code ships with sample pages, available in `contrib/service/sample-page` directory. Copy them to `custom/public/assets/`. For example, to add Privacy Policy:
 
 ```bash
-wget -O /path/to/custom/public/assets/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/legal/privacy.html.sample
+wget -O /path/to/custom/public/assets/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/service/sample-page/privacy.html.sample
 ```
 
 Now you need to edit the page to meet your requirements. In particular you must change the email addresses, web addresses and references to "Your Gitea Instance" to match your situation.

docs/administration/audit-logging.md

@@ -0,0 +1,153 @@
+---
+date: "2026-09-12T00:00:00+00:00"
+slug: "audit-logging"
+sidebar_position: 41
+aliases:
+  - /en-us/audit-logging
+---
+
+# Audit Logging
+
+Gitea can record security-relevant events as structured audit records: each
+event has an `action`, `actor`, `scope`, `origin`, `message` and a JSON
+`metadata` blob. Recording is **off by default** and does not change request
+behavior when it is disabled.
+
+This is separate from the application, router and access logs described in
+[Logging Configuration](logging-config.md). Those logs are for operations and
+debugging. The audit log is a durable trail of who changed what.
+
+## Enable recording
+
+Set `[audit].RECORD_OUTPUT` to `database` in `app.ini` and restart Gitea:
+
+```ini
+[audit]
+RECORD_OUTPUT = database
+RETENTION_DAYS = 30
+```
+
+Invalid values of `RECORD_OUTPUT` fall back to `disabled`. See the
+[configuration cheat sheet](config-cheat-sheet.md#audit-audit) for every option.
+
+With Docker, the same settings can be applied as
+`GITEA__audit__RECORD_OUTPUT=database` and `GITEA__audit__RETENTION_DAYS=30`
+before Gitea writes them into `app.ini`.
+
+## View events
+
+The Audit Log pages are always available and still list any events that were
+stored earlier. When recording is disabled, the site administration page also
+shows a warning.
+
+| Audience | Location | Events shown |
+| --- | --- | --- |
+| Site administrators | Site administration → Monitoring → Audit Log (`/-/admin/monitor/audit_logs`) | Every event |
+| Signed-in users | User settings → Audit Log (`/user/settings/audit_logs`) | Events scoped to that user |
+| Organization owners | Organization settings → Audit Log (`/<org>/settings/audit_logs`) | Events scoped to that organization |
+| Repository administrators | Repository settings → Audit Log (`/<owner>/<repo>/settings/audit_logs`) | Events scoped to that repository |
+
+Each listing can be filtered by actor (username), action and origin, and sorted
+by timestamp. The actor filter does not match the
+[system actors](#actors-and-origins). Action filters accept an exact action or
+a family prefix such as `user:impersonation` or `repository:webhook`.
+
+Site administrators can download the current filtered result as JSONL
+(newline-delimited JSON) from **Export JSONL**. The file name is
+`gitea-audit-log-<timestamp>.jsonl`.
+
+## Event shape
+
+A recorded event contains:
+
+- **Action**: a stable, colon-separated identifier such as `repository:archive`
+  or `user:accesstoken:add`.
+- **Actor**: the user who performed the action. Actions taken while impersonating
+  a user record both the impersonator and the impersonated user.
+- **Actor credential**: when the request authenticated with a named credential,
+  the event stores its kind and id, never the secret. Typical values:
+  `access-token:<id>`, `oauth2-grant:<id>`, `gitea-actions:<task id>`,
+  `deploy-key:<key id>`.
+- **Scope**: the affected unit — `user`, `organization`, `repository` or
+  `system` (instance-wide).
+- **Origin**: how the action was initiated — `ui`, `api`, `cli` or `system`.
+- **Message**: a human-readable sentence rendered from a per-action template.
+- **Metadata**: extra fields that fill the message template (token name, new
+  visibility, and so on). Secrets and token values are not stored.
+- **IP address**: the client address of the request, when one exists. Events
+  triggered by a git push record the SSH client address for SSH pushes and
+  `127.0.0.1` for HTTP pushes.
+- **Timestamp**: when the event was recorded.
+
+An exported JSONL line looks like:
+
+```json
+{"action":"repository:archive","actor":{"type":"user","id":1,"name":"alice"},"scope":{"type":"repository","id":42,"name":"org/repo"},"message":"Archived repository org/repo.","time":"2026-09-12T11:00:00Z","ip_address":"203.0.113.10","origin":"ui"}
+```
+
+The `system:startup` message is kept stable across Gitea versions so operators
+can parse it: `System started [Gitea {version}]`.
+
+## Actors and origins
+
+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
+  `system:shutdown` events
+- `(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
+- `(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
+other background work use origin `system`.
+
+## What is recorded
+
+Events cover security-relevant changes, grouped by action family:
+
+- **User**: create and delete, admin, restricted and active status, name,
+  password and password reset requests, visibility, emails, authentication
+  source, 2FA, WebAuthn, OpenID, external logins, access tokens, OAuth2
+  applications and grants, SSH/GPG/principal keys, secrets, webhooks,
+  impersonation, failed two-factor authentication
+- **Organization**: create and delete, name, visibility, members, teams,
+  OAuth2 applications, secrets, webhooks
+- **Repository**: create, fork, archive, delete, rename, visibility, transfer,
+  mirrors, signing verification, collaborators and teams, default branch,
+  branch and tag protection, deploy keys, webhooks, secrets
+- **Issues and pull requests**: create, delete, comments and merges
+- **Projects and wiki pages**: create, update and delete
+- **Actions**: enable, disable and dispatch a workflow
+- **System**: startup and shutdown, instance-wide webhooks, authentication
+  sources, instance-wide OAuth2 applications
+
+Recording never fails the request that triggered it. A write error is logged
+and the original operation continues.
+
+## What is not recorded
+
+- Read-only access such as browsing, clone, fetch or API GET requests
+- Logins, successful or failed, other than failed two-factor authentication
+  (use the [access log](logging-config.md) and
+  [Fail2ban Setup](fail2ban-setup.md) for authentication traffic)
+- Edits to issues and pull requests
+- Token or secret values
+- Which SSH key a real user pushed with (deploy keys are named; ordinary SSH
+  user pushes are not)
+
+## Retention
+
+`RETENTION_DAYS` (default **30**) is the age after which recorded events are
+eligible for deletion. Set it to `0` to keep events forever.
+
+Cleanup is performed by the `cron.delete_old_audit_events` task (`SCHEDULE`
+defaults to `@every 24h`, `OLDER_THAN` defaults to `[audit].RETENTION_DAYS`).
+The task is registered only while `RECORD_OUTPUT` records events **and**
+`RETENTION_DAYS` is greater than `0`. Turning recording off therefore also
+stops pruning; existing rows stay until you delete them or turn recording back
+on.

docs/administration/authentication.md

@@ -349,3 +349,86 @@ ENABLE_REVERSE_PROXY_AUTHENTICATION_API = true
 :::note
 When this method is enabled for the API, the reverse proxy is responsible for handling CSRF protection.
 :::
+
+## OAuth2 and OpenID Connect
+
+Gitea can delegate the login to an external OAuth2 or OpenID Connect provider,
+which is what "Sign in with ..." on the login page uses. This is the client side
+of the protocol; for the other direction, using a Gitea instance as the provider
+for another application, see
+[Gitea as an OAuth2 provider](../development/oauth2-provider.md).
+
+A source is added under `Site Administration -> Identity & Access ->
+Authentication Sources -> Add Authentication Source`, with `OAuth2` as the
+authentication type, or on the command line with
+`gitea admin auth add-oauth`. The fields are:
+
+- **Authentication Name (required)**
+
+  - The name of the source. It is part of the callback URL, so it cannot be
+    changed later without registering a new callback URL at the provider.
+
+- **OAuth2 Provider (required)**
+
+  - `OpenID Connect` for any provider that implements OpenID Connect discovery
+    (Keycloak, Authentik, Authelia, Entra ID, Okta, Zitadel and others), or one
+    of the providers Gitea knows about directly: Gitea, GitHub, GitLab, Google,
+    Discord, Bitbucket, Dropbox, Facebook, Mastodon, Nextcloud, Twitter, Yandex
+    and Azure AD v2.
+
+- **Client ID (Key)** and **Client Secret (required)**
+
+  - The credentials of the application registered at the provider.
+
+- **OpenID Connect Auto Discovery URL**
+
+  - Only for the `OpenID Connect` provider: the discovery document of the
+    provider, usually `https://provider.example.com/.well-known/openid-configuration`.
+    Gitea reads the endpoints from it.
+
+- **Additional Scopes**
+
+  - Scopes to request on top of the ones the provider needs by default. For
+    OpenID Connect, `openid` is always added, and the scopes are taken from
+    `OPENID_CONNECT_SCOPES` in `app.ini` when it is set.
+
+- **Required Claim Name** and **Required Claim Value**
+
+  - Restrict the login to accounts whose token carries this claim, optionally
+    with this exact value.
+
+- **Claim name providing group names**, **Group Claim value for administrator
+  users**, **Group Claim value for restricted users** and **Map claimed groups
+  to Organization teams**
+
+  - Grant the administrator or the restricted flag, and organization team
+    membership, from the groups the provider reports. They all need the claim
+    name to be set.
+
+- **Icon URL**
+
+  - Image shown next to the button on the login page.
+
+Register `{ROOT_URL}/user/oauth2/{Authentication Name}/callback` as the
+redirect URI at the provider, for example
+`https://gitea.example.com/user/oauth2/keycloak/callback` for a source named
+`keycloak`. A wrong redirect URI is the most common reason for the login to
+fail at the provider.
+
+What happens to accounts that log in this way is configured in `app.ini`, see
+[OAuth2 Client](config-cheat-sheet.md#oauth2-client-oauth2_client):
+
+```ini title="app.ini"
+[oauth2_client]
+; create an account for a user who logs in for the first time
+ENABLE_AUTO_REGISTRATION = true
+; where the username of a new account comes from
+USERNAME = nickname
+; what to do when the username or email is already taken
+ACCOUNT_LINKING = login
+```
+
+:::note
+This is unrelated to `ENABLE_OPENID_SIGNIN` and the `[openid]` section, which
+configure the older OpenID 2.0 sign-in.
+:::

docs/administration/backup-and-restore.md

@@ -24,7 +24,7 @@ directory. There should be some output similar to the following:
 
 ```log
 2016/12/27 22:32:09 Creating tmp work dir: /tmp/gitea-dump-417443001
-2016/12/27 22:32:09 Dumping local repositories.../home/git/gitea-repositories
+2016/12/27 22:32:09 Dumping local repositories.../home/git/repositories
 2016/12/27 22:32:22 Dumping database...
 2016/12/27 22:32:22 Packing dump files...
 2016/12/27 22:32:34 Removing tmp work dir: /tmp/gitea-dump-417443001
@@ -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
@@ -119,7 +119,7 @@ cd gitea-dump-1610949662
 # restore the gitea data
 mv data/* /data/gitea
 # restore the repositories itself
-mv repos/* /data/git/gitea-repositories/
+mv repos/* /data/git/repositories/
 # adjust file permissions
 chown -R git:git /data
 # Regenerate Git Hooks
@@ -143,7 +143,7 @@ mv data/conf/app.ini /etc/gitea/app.ini
 # restore the gitea data
 mv data/* /var/lib/gitea
 # restore the repositories itself
-mv repos/* /var/lib/gitea/git/gitea-repositories
+mv repos/* /var/lib/gitea/git/repositories
 # adjust file permissions
 chown -R git:git /etc/gitea/app.ini /var/lib/gitea
 # Regenerate Git Hooks
@@ -173,4 +173,4 @@ gitea=# \i gitea-db.sql
 
 Disabling `synchronous_commit` makes PostgreSQL less resilient to crashes, but makes the import a lot faster. Since we already have a backup of the original database and we can check that the import completes successfully, it should be a good trade-off.
 
-After the import is completed, set up Gitea to use PostgreSQL and start the Gitea server again. Good luck!
+After the import is completed, set up Gitea to use PostgreSQL and start the Gitea server again. Good luck!

docs/administration/command-line.md

@@ -45,6 +45,9 @@ Starts the server:
   - Gitea should not be run as root. To bind to a port below 1024, you can use setcap on
     Linux: `sudo setcap 'cap_net_bind_service=+ep' /path/to/gitea`. This will need to be
     redone every time you update Gitea.
+    A systemd unit can grant the capability to the process instead, which survives an
+    upgrade and works with SELinux in enforcing mode, see
+    [running Gitea with SELinux](../installation/selinux.md).
 
 ### admin
 
@@ -325,6 +328,7 @@ in the current directory.
   - `--skip-attachment-data`: Skip dumping of attachment data. Optional.
   - `--skip-package-data`: Skip dumping of package data. Optional.
   - `--skip-log`: Skip dumping of log data. Optional.
+  - `--skip-index`: Skip dumping of Bleve indexer data. Optional. Applies only for bleve.
   - `--database`, `-d`: Specify the database SQL syntax. Optional (supported arguments: sqlite3, mysql, mssql, postgres).
   - `--verbose`, `-V`: If provided, shows additional details. Optional.
   - `--type`: Set the dump output format. Optional. (formats: zip, tar, tar.sz, tar.gz, tar.xz, tar.bz2, tar.br, tar.lz4, tar.zst default: zip).

docs/administration/customizing-gitea.md

@@ -9,7 +9,7 @@ aliases:
 # Customizing Gitea
 
 Customizing Gitea is typically done using the `CustomPath` folder - by default this is
-the `custom` folder from the working directory (WorkPath), but may be different if your build has
+the `custom` folder from the working directory (WorkPath), but may be different if your [installation](../installation/from-binary.md) has
 set this differently. This is the central place to override configuration settings,
 templates, etc. You can check the `CustomPath` using `gitea help`. You can also find
 the path on the _Configuration_ tab in the _Site Administration_ page. You can override
@@ -23,7 +23,7 @@ the Linux Filesystem Standard. Gitea will attempt to create required folders, in
 `custom/`. Distributions may provide a symlink for `custom` using `/etc/gitea/`.
 
 Application settings can be found in file `CustomConf` which is by default,
-`$GITEA_CUSTOM/conf/app.ini` but may be different if your build has set this differently.
+`$GITEA_CUSTOM/conf/app.ini` but may be different if your [installation](../installation/from-binary.md) has set this differently.
 Again `gitea help` will allow you review this variable and you can override it using the
 `--config` option on the `gitea` binary.
 
@@ -85,6 +85,8 @@ To obtain any embedded file (including templates), the [`gitea embedded` tool](.
 Be aware that any statement contained inside `{{` and `}}` are Gitea's template syntax and
 shouldn't be touched without fully understanding these components.
 
+Gitea pages are protected by Content-Security-Policy, use `<script nonce="{{ctx.CspScriptNonce}}">...</script>` for script tags.
+
 ### Customizing startpage / homepage
 
 Copy [`home.tmpl`](https://github.com/go-gitea/gitea/blob/main/templates/home.tmpl) for your version of Gitea from `templates` to `$GITEA_CUSTOM/templates`.
@@ -136,10 +138,10 @@ The data is encoded and sent to the PlantUML server which generates the picture.
 demo server at http://www.plantuml.com/plantuml, but if you (or your users) have sensitive data you
 can set up your own [PlantUML server](https://plantuml.com/server) instead. To set up PlantUML rendering,
 copy JavaScript files from https://gitea.com/davidsvantesson/plantuml-code-highlight and put them in your
-`$GITEA_CUSTOM/public/assets/` folder. Then add the following to `custom/footer.tmpl`:
+`$GITEA_CUSTOM/public/assets/` folder. Then add the following to `$GITEA_CUSTOM/templates/custom/footer.tmpl`:
 
 ```html
-<script>
+<script nonce="{{ctx.CspScriptNonce}}">
   $(async () => {
     if (!$('.language-plantuml').length) return;
     await Promise.all([
@@ -165,52 +167,186 @@ Alice <-- Bob: Another authentication Response
 
 The script will detect tags with `class="language-plantuml"`, but you can change this by providing a second argument to `parsePlantumlCodeBlocks`.
 
-### Example: STL Preview
+### Example: CAD Files Preview using Online 3D Viewer
 
-You can display STL file directly in Gitea by adding:
+You can implement CAD file preview inside your Gitea instance. This implemenation uses [`Online 3D Viewer`](https://github.com/kovacsv/Online3DViewer).
+
+Supports following 3D file formats:
+'3dm', '3ds', '3mf', 'amf', 'bim', 'brep', 'dae', 'fbx', 'fcstd', 'glb',
+'gltf', 'ifc', 'igs', 'iges', 'stp', 'step', 'stl', 'obj', 'off', 'ply', 'wrl'
+(Only v2 for .gltf files)
+
+#### Part 1: Add template
+
+In $GITEA_CUSTOM we need to add our template.
+This template needs to be saved in "$GITEA_CUSTOM/templates/custom/".
+Here create file "footer.tmpl" and add following text into it:
+
+```
+nano $GITEA_CUSTOM/templates/custom/footer.tmpl
+```
 
 ```html
-<script>
+<script nonce="{{ctx.CspScriptNonce}}">
-  function lS(src) {
+    function onPageChange() {
-    return new Promise(function (resolve, reject) {
+      // Supported 3D file types
-      let s = document.createElement("script");
+      const fileTypes = ['3dm', '3ds', '3mf', 'amf', 'bim', 'brep', 'dae', 'fbx', 'fcstd', 'glb', 'gltf', 'ifc', 'igs', 'iges', 'stp', 'step', 'stl', 'obj', 'off', 'ply', 'wrl'];
-      s.src = src;
-      s.addEventListener("load", () => {
-        resolve();
-      });
-      document.body.appendChild(s);
-    });
-  }
 
-  if ($('.view-raw>a[href$=".stl" i]').length) {
+      // Select matching link
-    $("body").append(
+      const links = Array.from(document.querySelectorAll('a.ui.mini.basic.button'));
-      '<link href="/assets/Madeleine.js/src/css/Madeleine.css" rel="stylesheet">'
+      const link3D = links.find(link => {
-    );
+        const href = link.href.toLowerCase();
-    Promise.all([
+        return href.includes('/raw/') && fileTypes.some(ext => href.endsWith(`.${ext}`));
-      lS("/assets/Madeleine.js/src/lib/stats.js"),
-      lS("/assets/Madeleine.js/src/lib/detector.js"),
-      lS("/assets/Madeleine.js/src/lib/three.min.js"),
-      lS("/assets/Madeleine.js/src/Madeleine.js"),
-    ]).then(function () {
-      $(".view-raw")
-        .attr("id", "view-raw")
-        .attr("style", "padding: 0;margin-bottom: -10px;");
-      new Madeleine({
-        target: "view-raw",
-        data: $('.view-raw>a[href$=".stl" i]').attr("href"),
-        path: "/assets/Madeleine.js/src",
       });
-      $('.view-raw>a[href$=".stl"]').remove();
+
+	if (link3D) {
+	  const existingScript = document.querySelector('script[src="/assets/o3dv/o3dv.min.js"]');
+
+	  const initializeViewer = () => {
+		const fileUrl = link3D.getAttribute('href');
+
+                const fileView = document.querySelector('.file-view');
+
+		if (!fileView) return;
+
+		// Remove only the old viewer container if it exists
+		const oldView3D = document.getElementById('view-3d');
+		if (oldView3D) {
+		  oldView3D.remove();  // safely remove old viewer container div
+		} else {
+		  // No #view-3d, so remove all children inside .file-view
+		  while (fileView.firstChild) {
+		    fileView.removeChild(fileView.firstChild);
+		  }
+		}
+
+		// Create a new container for the viewer
+		const newView3D = document.createElement('div');
+		  newView3D.id = 'view-3d';
+		  newView3D.style.padding = '0';
+		  newView3D.style.margin = '0';
+		  newView3D.style.flexGrow = '1';
+		  newView3D.style.minHeight = '0';
+		  newView3D.style.width = '100%';
+
+		const header = document.querySelector('header');
+		const headerHeight = header ? header.offsetHeight : 0;
+
+		newView3D.style.height = `calc(100vh - ${headerHeight}px)`;
+
+		// Append the new container inside fileView
+		fileView.appendChild(newView3D);
+
+		const parentDiv = document.getElementById('view-3d');
+		if (parentDiv) {
+		  const viewer = new OV.EmbeddedViewer(parentDiv, {
+			backgroundColor: new OV.RGBAColor(59, 68, 76, 0),
+			defaultColor: new OV.RGBColor(200, 200, 200),
+			edgeSettings: new OV.EdgeSettings(false, new OV.RGBColor(0, 0, 0), 1),
+			environmentSettings: new OV.EnvironmentSettings([
+			  '/assets/o3dv/envmaps/fishermans_bastion/negx.jpg',
+			  '/assets/o3dv/envmaps/fishermans_bastion/posx.jpg',
+			  '/assets/o3dv/envmaps/fishermans_bastion/posy.jpg',
+			  '/assets/o3dv/envmaps/fishermans_bastion/negy.jpg',
+			  '/assets/o3dv/envmaps/fishermans_bastion/posz.jpg',
+			  '/assets/o3dv/envmaps/fishermans_bastion/negz.jpg'
+			], false)
+		  });
+
+		  viewer.LoadModelFromUrlList([fileUrl]);
+		}
+	  };
+
+	  if (typeof OV === 'undefined') {
+		if (!existingScript) {
+		  const script = document.createElement('script');
+		  script.onload = initializeViewer;
+		  script.src = '/assets/o3dv/o3dv.min.js';
+		  document.head.appendChild(script);
+		} else {
+		  // Script is loading but OV not yet ready — wait for it
+		  existingScript.addEventListener('load', initializeViewer);
+		}
+	  } else {
+		// OV already loaded
+		initializeViewer();
+	  }
+	}
+    };
+
+    // Run when the page is fully loaded
+    document.addEventListener('DOMContentLoaded', onPageChange);
+
+    const targetSelector = 'a.ui.mini.basic.button[href*="/raw/"]';
+    let lastHref = null;
+    let timeoutId = null;
+
+    const checkAndRun = () => {
+      const rawLink = document.querySelector(targetSelector);
+      if (!rawLink) return;
+
+      const currentHref = rawLink.getAttribute('href');
+      if (currentHref !== lastHref) {
+        lastHref = currentHref;
+
+        const fileName = currentHref.split('/').pop();
+        console.log('New Raw file link detected after delay:', fileName);
+
+        onPageChange();
+      }
+    };
+
+    const observer = new MutationObserver(() => {
+      // Delay execution by 300ms after last mutation
+      clearTimeout(timeoutId);
+      timeoutId = setTimeout(checkAndRun, 300);
+    });
+
+    observer.observe(document.body, {
+      childList: true,
+      subtree: true,
     });
-  }
 </script>
 ```
 
-to the file `templates/custom/footer.tmpl`
+#### Part 2: Add public files
 
-You also need to download the content of the library [Madeleine.js](https://github.com/beige90/Madeleine.js) and place it under `$GITEA_CUSTOM/public/assets/` folder.
+Now we need to download latest version of O3DV. Go to "$GITEA_CUSTOM/public/assets/".
+Create folder using (and cd into it):
 
-You should end-up with a folder structure similar to:
+```
+mkdir o3dv
+cd o3dv
+```
+
+Copy latest release zip link from [`GitHub`](https://github.com/kovacsv/Online3DViewer/releases) (v0.18.0 as of now).
+Here use e.g. wget or curl to download the file:
+
+```
+wget https://github.com/kovacsv/Online3DViewer/releases/download/0.18.0/o3dv.zip
+```
+
+or
+
+```
+curl -L -O https://github.com/kovacsv/Online3DViewer/releases/download/0.18.0/o3dv.zip
+```
+
+Use e.g. unzip to unzip the archive:
+```
+unzip o3dv.zip
+```
+
+#### Part 3: Folder permissions
+
+Now the last thing. Change permissions on the public folder:
+```
+chown -R git:git $GITEA_CUSTOM/public
+```
+
+Now we have everything ready! Restart your gitea instance to apply these changes and test it in your browser.
+
+Sanity check. You should end-up with a folder structure similar to this:
 
 ```
 $GITEA_CUSTOM/templates
@@ -218,49 +354,14 @@ $GITEA_CUSTOM/templates
     `-- footer.tmpl
 
 $GITEA_CUSTOM/public/assets/
--- Madeleine.js
+-- o3dv
-   |-- LICENSE
+   |-- o3dv.zip
-   |-- README.md
+   |-- o3dv.license.md
-   |-- css
+   |-- o3dv.min.js
-   |   |-- pygment_trac.css
+   |-- envmaps
-   |   `-- stylesheet.css
+    \...
-   |-- examples
-   |   |-- ajax.html
-   |   |-- index.html
-   |   `-- upload.html
-   |-- images
-   |   |-- bg_hr.png
-   |   |-- blacktocat.png
-   |   |-- icon_download.png
-   |   `-- sprite_download.png
-   |-- models
-   |   |-- dino2.stl
-   |   |-- ducati.stl
-   |   |-- gallardo.stl
-   |   |-- lamp.stl
-   |   |-- octocat.stl
-   |   |-- skull.stl
-   |   `-- treefrog.stl
-   `-- src
-       |-- Madeleine.js
-       |-- css
-       |   `-- Madeleine.css
-       |-- icons
-       |   |-- logo.png
-       |   |-- madeleine.eot
-       |   |-- madeleine.svg
-       |   |-- madeleine.ttf
-       |   `-- madeleine.woff
-       `-- lib
-           |-- MadeleineConverter.js
-           |-- MadeleineLoader.js
-           |-- detector.js
-           |-- stats.js
-           `-- three.min.js
 ```
 
-Then restart Gitea and open a STL file on your Gitea instance.
-
 ## Customizing Gitea mails
 
 The `$GITEA_CUSTOM/templates/mail` folder allows changing the body of every mail of Gitea.
@@ -295,15 +396,16 @@ Starting with Gitea 1.20, you can customize the git configuration via the `git.c
 
 ### Enabling signed git pushes
 
-To enable signed git pushes, set these two options:
+[Signed pushes](https://git-scm.com/docs/git-push#Documentation/git-push.txt---signedtruefalseif-asked) allow clients to cryptographically sign the push operation itself (not just individual commits). To enable signed pushes, add the following to `app.ini`:
 
 ```ini
 [git.config]
-receive.advertisePushOptions = true
 receive.certNonceSeed = <randomstring>
 ```
 
-`certNonceSeed` should be set to a random string and be kept secret.
+`certNonceSeed` should be set to a random string and be kept secret. It is used to generate anti-replay nonces. Gitea already sets `receive.advertisePushOptions = true` by default, so no additional configuration is needed. Note that Gitea does not read `/etc/gitconfig`, so this option must be set via `app.ini` as shown above.
+
+On the client side, pushes can be signed via `git push --signed` or enabled permanently using `git config --global push.gpgSign if-asked`.
 
 ### Labels
 
@@ -321,7 +423,7 @@ The [legacy file format](https://github.com/go-gitea/gitea/blob/main/options/lab
 
 `#hex-color label name ; label description`
 
-For more information, see the [labels documentation](usage/labels.md).
+For more information, see the [labels documentation](../usage/issues-prs/labels.md).
 
 ### Licenses
 
@@ -380,13 +482,27 @@ To make a custom theme available to all users:
   The value of `$GITEA_CUSTOM` of your instance can be queried by calling `gitea help` and looking up the value of "CustomPath".
 2. Add `<theme-name>` to the comma-separated list of setting `THEMES` in `app.ini`, or leave `THEMES` empty to allow all themes.
 
+A custom theme file named `theme-my-theme.css` will be displayed as `my-theme` on the user's theme selection page.
+It could add theme meta information into the custom theme CSS file to provide more information about the theme.
+If a custom theme is a dark theme, please set the global css variable `--is-dark-theme: true` in the `:root` block.
+This allows Gitea to adjust the Monaco code editor's theme accordingly.
+An "auto" theme could be implemented by using "theme-gitea-auto.css" as a reference.
+
+```css
+gitea-theme-meta-info {
+  --theme-display-name: "My Awesome Theme"; /* this theme will be display as "My Awesome Theme" on the UI */
+}
+:root {
+  --is-dark-theme: true; /* if it is a dark theme */
+  --color-primary: #112233;
+  /* more custom theme variables ... */
+}
+```
+
 Community themes are listed in [gitea/awesome-gitea#themes](https://gitea.com/gitea/awesome-gitea#themes).
 
 The default theme sources can be found [here](https://github.com/go-gitea/gitea/blob/main/web_src/css/themes).
 
-If your custom theme is considered a dark theme, set the global css variable `--is-dark-theme` to `true`.
-This allows Gitea to adjust the Monaco code editor's theme accordingly.
-
 ## Customizing fonts
 
 Fonts can be customized using CSS variables:

docs/administration/email-setup.md

@@ -10,6 +10,10 @@ aliases:
 
 Gitea has mailer functionality for sending transactional emails (such as registration confirmation). It can be configured to either use Sendmail (or compatible MTAs like Postfix and msmtp) or directly use SMTP server.
 
+:::note
+Be sure to set ENABLE_NOTIFY_MAIL=true to allow Gitea to send email notifications. Check the [Config Cheat Sheet](../administration/config-cheat-sheet.md#service-service) for details.
+:::
+
 ## Using Sendmail
 
 Use `sendmail` command as mailer.
@@ -41,7 +45,7 @@ ENABLED        = true
 FROM           = [email protected]
 PROTOCOL       = smtps
 SMTP_ADDR      = mail.mydomain.com
-SMTP_PORT      = 587
+SMTP_PORT      = 465
 USER           = [email protected]
 PASSWD         = `password`
 ```
@@ -56,7 +60,7 @@ For the full list of options check the [Config Cheat Sheet](../administration/co
 Authentication is only supported when the SMTP server communication is encrypted with TLS or `HOST=localhost`. TLS encryption can be through:
 :::
 
-- STARTTLS (also known as Opportunistic TLS) via port 587. Initial connection is done over cleartext, but then be upgraded over TLS if the server supports it.
+- STARTTLS (also known as Opportunistic TLS) via port 587 with `PROTOCOL=smtp+starttls`. Initial connection is done over cleartext, but then be upgraded over TLS if the server supports it.
 - SMTPS connection (SMTP over TLS) via the default port 465. Connection to the server use TLS from the beginning.
 - Forced SMTPS connection with `PROTOCOL=smtps`. (These are both known as Implicit TLS.)
 This is due to protections imposed by the Go internal libraries against STRIPTLS attacks.
@@ -82,6 +86,21 @@ PROTOCOL       = smtps
 Note that you'll need to create and use an [App password](https://support.google.com/accounts/answer/185833?hl=en) by enabling 2FA on your Google
 account. You won't be able to use your Google account password directly.
 
+An app password is the only option: Google
+[turned off access for apps that sign in with a password alone](https://workspaceupdates.googleblog.com/2023/09/winding-down-google-sync-and-less-secure-apps-support.html)
+in 2024 and asks applications to use OAuth instead, which Gitea's mailer does
+not implement — it authenticates with `CRAM-MD5`, `PLAIN` or `LOGIN`.
+
+Two things to keep in mind:
+
+- app passwords require 2-step verification on the account, and a Google
+  Workspace administrator can switch them off for the whole domain. If they are
+  not available, send through the
+  [Workspace SMTP relay service](https://support.google.com/a/answer/2956491)
+  or through another mail provider.
+- port `587` works as well, with `SMTP_PORT = 587` and
+  `PROTOCOL = smtp+starttls`.
+
 ### ProtonMail
 
 This feature is currently only available for select Proton for Business customers and those with Visionary and Family plans with custom domain addresses. See [ProtonMail's SMTP documentation](https://proton.me/support/smtp-submission) for more information. This limitation can be circumvented by using the ProtonMail Bridge application.

docs/administration/external-renderers.md

@@ -23,7 +23,7 @@ In order to get file rendering through external binaries, their associated packa
 If you're using a Docker image, your `Dockerfile` should contain something along this lines:
 
 ```docker
-FROM docker.io/gitea/gitea:@dockerVersion@
+FROM docker.gitea.com/gitea:@dockerVersion@
 [...]
 
 COPY custom/app.ini /data/gitea/conf/app.ini

docs/administration/git-lfs-support.md

@@ -41,3 +41,24 @@ client that causes SSH transfers to hang: https://github.com/git-lfs/git-lfs/pul
 This can be worked around on all the client machines by setting the git config:
 `git config --global lfs.ssh.automultiplex false`
 :::
+
+# Changing LFS files through the API
+
+The [contents API](https://docs.gitea.com/api/operations/repo-change-files/)
+works on LFS tracked files as well: send the file content as usual and Gitea
+stores it as an LFS object and commits a pointer file, as long as the path is
+matched by a `filter=lfs` rule in `.gitattributes`.
+
+What is easy to get wrong is the `sha` of the file being changed, which
+`PUT`/`DELETE /repos/{owner}/{repo}/contents/{filepath}` and
+`POST /repos/{owner}/{repo}/contents` require for an existing file. Gitea
+compares it with the ID of the blob the commit has at that path, and for an LFS
+tracked file that blob is the **pointer file**, not the content:
+
+- use the `sha` returned by
+  [`GET /repos/{owner}/{repo}/contents/{filepath}`](https://docs.gitea.com/api/operations/repo-get-contents/)
+- do not use `lfs_oid` from the same response, which identifies the LFS object,
+  and do not use a checksum of the file itself
+
+Sending anything else fails with `sha does not match`, even though the request
+looks correct.

docs/administration/https-support.md

@@ -78,6 +78,28 @@ [email protected]
 
 To learn more about the config values, please checkout the [Config Cheat Sheet](./config-cheat-sheet.md#server-server).
 
+:::warning
+`ACME_DIRECTORY` is where the account key and the issued certificates are
+cached, and the default `https` is a relative path, resolved against the working
+directory of the Gitea process. In the official Docker image that working
+directory is `/app/gitea`, which is part of the container and not of the `/data`
+volume, so every recreated container starts without an account and without
+certificates and asks the CA for new ones. Let's Encrypt allows
+[5 certificates per week](https://letsencrypt.org/docs/rate-limits/) for the
+same set of domains, after which the instance is left without a working
+certificate until the limit expires.
+
+Point the setting at a path inside the volume when running in a container:
+
+```ini title="app.ini"
+[server]
+ACME_DIRECTORY=/data/gitea/https
+```
+
+The rootless image keeps its working directory (`/var/lib/gitea`) in a volume,
+so it is only affected when that volume is not persisted.
+:::
+
 ## Using a reverse proxy
 
 Setup up your reverse proxy as shown in the [reverse proxy guide](../administration/reverse-proxies.md).

docs/administration/logging-config.md

@@ -16,6 +16,8 @@ The logging configuration of Gitea mainly consists of 3 types of components:
 
 There is a fully functional log output by default, so it is not necessary to define one.
 
+Security-relevant events (repository transfers, token changes, impersonation, and similar) are recorded separately. See [Audit Logging](audit-logging.md).
+
 ## Collecting Logs for Help
 
 To collect logs for help and issue report, see [Support Options](help/support.md).

docs/administration/mail-templates.md

@@ -257,7 +257,6 @@ the messages. Here's a list of some of them:
 | `AppDomain`      | -           | Any       | Gitea's host name                                                   |
 | `EllipsisString` | string, int | Any       | Truncates a string to the specified length; adds ellipsis as needed |
 | `SanitizeHTML`   | string      | Body only | Sanitizes text by removing any dangerous HTML tags from it          |
-| `SafeHTML`       | string      | Body only | Takes the input as HTML, can be used for outputing raw HTML content |
 
 These are _functions_, not metadata, so they have to be used:
 

docs/administration/repo-indexer.md

@@ -32,7 +32,7 @@ Please bear in mind that indexing the contents can consume a lot of system resou
 
 ### Choosing the files for indexing by size
 
-The `MAX_FILE_SIZE` option will make the indexer skip all files larger than the specified value.
+The `MAX_FILE_SIZE` option will make the indexer skip all files larger than the specified value in bytes.
 
 ### Choosing the files for indexing by path
 

docs/administration/reverse-proxies.md

@@ -13,7 +13,9 @@ aliases:
 1. Set `[server] ROOT_URL = https://git.example.com/` in your `app.ini` file.
 2. Make the reverse-proxy pass `https://git.example.com/foo` to `http://gitea:3000/foo`.
 3. Make sure the reverse-proxy does not decode the URI. The request `https://git.example.com/a%2Fb` should be passed as `http://gitea:3000/a%2Fb`.
-4. Make sure `Host` and `X-Fowarded-Proto` headers are correctly passed to Gitea to make Gitea see the real URL being visited.
+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.
 
 ### Use a sub-path
 
@@ -40,6 +42,7 @@ server {
     location / {
         client_max_body_size 512M;
         proxy_pass http://localhost:3000;
+        proxy_http_version 1.1;
         proxy_set_header Connection $http_connection;
         proxy_set_header Upgrade $http_upgrade;
         proxy_set_header Host $host;
@@ -66,6 +69,7 @@ server {
         rewrite ^ $request_uri;
         rewrite ^/(gitea($|/))?(.*) /$3 break;
         proxy_pass http://127.0.0.1:3000$uri;
+        proxy_http_version 1.1;
 
         # other common HTTP headers, see the "Nginx" config section above
         proxy_set_header Connection $http_connection;
@@ -112,6 +116,7 @@ server {
     }
 
     location / {
+        # other directives, see the "Nginx" config section above
         proxy_pass http://localhost:3000;
     }
 }
@@ -128,6 +133,7 @@ server {
     server_name git.example.com;
 
     location / {
+        # other directives, see the "Nginx" config section above
         proxy_pass http://localhost:3000;
     }
 }
@@ -149,6 +155,20 @@ server {
 }
 ```
 
+## Nginx Proxy Manager
+
+If you are using Nginx Proxy Manager to serve your Gitea instance it differs slighly from the raw Nginx.
+
+It is [adding some directives](https://github.com/NginxProxyManager/nginx-proxy-manager/blob/master/docker/rootfs/etc/nginx/conf.d/include/proxy.conf) for a custom location by default, so you have to skip these from the above mentioned Nginx config. Otherwise Nginx will produce `400 bad request` error due to duplicated directives (`proxy_set_header Host $host` is the particularly problematic one).
+
+So while creating the `/` Custom location, just add the following line to it's configuration:
+
+```nginx
+client_max_body_size 512M;
+```
+
+Enable `Websockets Support` on the proxy host, Nginx Proxy Manager then adds the WebSocket directives itself. Adding `proxy_http_version` on top of that makes Nginx refuse to start.
+
 ## Apache HTTPD
 
 If you want Apache HTTPD to serve your Gitea instance, you can add the following to your Apache HTTPD configuration (usually located at `/etc/apache2/httpd.conf` in Ubuntu):
@@ -159,13 +179,15 @@ If you want Apache HTTPD to serve your Gitea instance, you can add the following
     ProxyPreserveHost On
     ProxyRequests off
     AllowEncodedSlashes NoDecode
-    ProxyPass / http://localhost:3000/ nocanon
+    ProxyPass / http://localhost:3000/ nocanon upgrade=websocket
     RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
 </VirtualHost>
 ```
 
 :::note
 The following Apache HTTPD mods must be enabled: `proxy`, `proxy_http`.
+
+`upgrade=websocket` requires Apache HTTPD 2.4.48 or later. On older versions you **MUST** remove it, otherwise Apache HTTPD will not start.
 :::
 
 If you wish to use Let's Encrypt with webroot validation, add the line `ProxyPass /.well-known !` before `ProxyPass` to disable proxying these requests to Gitea.
@@ -183,7 +205,7 @@ In case you already have a site, and you want Gitea to share the domain name, yo
     </Proxy>
     AllowEncodedSlashes NoDecode
     # Note: no trailing slash after either /git or port
-    ProxyPass /git http://localhost:3000 nocanon
+    ProxyPass /git http://localhost:3000 nocanon upgrade=websocket
     ProxyPreserveHost On
     RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
 </VirtualHost>
@@ -192,7 +214,55 @@ In case you already have a site, and you want Gitea to share the domain name, yo
 Then you **MUST** set something like `[server] ROOT_URL = http://git.example.com/git/` correctly in your configuration.
 
 :::note
-The following Apache HTTPD mods must be enabled: `proxy`, `proxy_http`.
+The following Apache HTTPD mods must be enabled: `proxy`, `proxy_http`. `upgrade=websocket` requires Apache HTTPD 2.4.48 or later, remove it on older versions.
+:::
+
+## Apache HTTPD and serve static resources directly
+
+We can tune the performance in splitting requests into categories static and dynamic.
+
+CSS files, JavaScript files, images and web fonts are static content.
+The front page, a repository view or issue list is dynamic content.
+
+Apache HTTPD can serve static resources directly and proxy only the dynamic requests to Gitea.
+
+Download a snapshot of the Gitea source repository to `/path/to/gitea/`.
+After this, run `make frontend` in the repository directory to generate the static resources. We are only interested in the `public/` directory for this task, so you can delete the rest.
+(You will need to have [Node with npm](https://nodejs.org/en/download/) and `make` installed to generate the static resources)
+
+Depending on the scale of your user base, you might want to split the traffic to two distinct servers,
+or use a cdn for the static files.
+
+### Single node and single domain
+
+Set `[server] STATIC_URL_PREFIX = /_/static` in your configuration.
+
+```apacheconf
+<VirtualHost *:80>
+    ...
+    <Proxy *>
+         Order allow,deny
+         Allow from all
+    </Proxy>
+
+    ProxyPass /_/static/ !
+    Alias /_/static/ /path/to/gitea/public/
+    <Directory /path/to/gitea/public/>
+        Options FollowSymlinks
+		AllowOverride None
+		Require all granted
+    </Directory>
+
+    AllowEncodedSlashes NoDecode
+    # Note: no trailing slash after either /git or port
+    ProxyPass / http://localhost:3000/ nocanon upgrade=websocket
+    ProxyPreserveHost On
+    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
+</VirtualHost>
+```
+
+:::note
+The following Apache HTTPD mods must be enabled: `proxy`, `proxy_http`. `upgrade=websocket` requires Apache HTTPD 2.4.48 or later, remove it on older versions.
 :::
 
 ## Caddy
@@ -229,11 +299,13 @@ If you wish to run Gitea with IIS. You will need to setup IIS with URL Rewrite a
 
 - Install Application Request Routing (ARR for short) either by using the Microsoft Web Platform Installer 5.1 (WebPI) or downloading the extension from [IIS.net](https://www.iis.net/downloads/microsoft/application-request-routing)
 - Once the module is installed in IIS, you will see a new Icon in the IIS Administration Console called URL Rewrite.
+- Install the `WebSocket Protocol` Windows feature, otherwise ARR cannot proxy Gitea's WebSocket endpoint.
 - Open the IIS Manager Console and click on the `Gitea Proxy` Website from the tree view on the left. Select and double click the URL Rewrite Icon from the middle pane to load the URL Rewrite interface.
 - Choose the `Add Rule` action from the right pane of the management console and select the `Reverse Proxy Rule` from the `Inbound and Outbound Rules` category.
 - In the Inbound Rules section, set the server name to be the host that Gitea is running on with its port. e.g. if you are running Gitea on the localhost with port 3000, the following should work: `127.0.0.1:3000`
 - Enable SSL Offloading
 - In the Outbound Rules, ensure `Rewrite the domain names of the links in HTTP response` is set and set the `From:` field as above and the `To:` to your external hostname, say: `git.example.com`
+- Turn `Reverse rewrite host in response headers` off, in the `Server Proxy Settings` of Application Request Routing (select the server node in the IIS Manager, open `Application Request Routing Cache`, then `Server Proxy Settings` in the right pane). While it is on, ARR rewrites the host of the `Location` header back to the internal one, so the redirects Gitea sends after a sign-in or a form submission send the browser to `127.0.0.1:3000` instead of `git.example.com`.
 - Now edit the `web.config` for your website to match the following: (changing `127.0.0.1:3000` and `git.example.com` as appropriate)
 
 ```xml

docs/administration/signing.md

@@ -6,12 +6,14 @@ aliases:
   - /en-us/signing
 ---
 
-# GPG Commit Signatures
+# GPG/SSH Commit Signatures
 
-Gitea will verify GPG commit signatures in the provided tree by
+Gitea will verify gpg/ssh commit signatures in the provided tree by
 checking if the commits are signed by a key within the Gitea database,
 or if the commit matches the default key for Git.
 
+Additionally Gitea will verify commits signed by ssh keys, which public keys are part of [`TRUSTED_SSH_KEYS`](#general-configuration).
+
 Keys are not checked to determine if they have expired or revoked.
 Keys are also not checked with keyservers.
 
@@ -46,6 +48,11 @@ for GPG - in particular it is probably advisable to only install a
 signing secret subkey without the master signing and certifying secret
 key.
 
+## Installing and generating a SSH key for Gitea
+
+You can run `ssh-keygen -t ed25519 -f gitea-signing-key` to generate the private/public keypair for commit signing without any password. Usually you would store the key next to the gitea configuration, then point `SIGNING_KEY` to the generated public key `/path/to/gitea-signing-key.pub`. Gitea generates all its commits using the server `git` command at present - and therefore the server `ssh-keygen` will be used for
+signing (if configured.)
+
 ## General Configuration
 
 Gitea's configuration for signing can be found with the
@@ -65,16 +72,41 @@ MERGES = pubkey, twofa, basesigned, commitssigned
 ...
 ```
 
+---
+
+For SSH commit signing, you need to specify the `SIGNING_FORMAT` to `ssh` instead of the default `openpgp`. `SIGNING_NAME` and `SIGNING_EMAIL` are required for verifing the signatures.
+
+This looks like this:
+
+```ini
+...
+[repository.signing]
+SIGNING_KEY = /path/to/gitea-signing-key.pub
+SIGNING_NAME =
+SIGNING_EMAIL =
+SIGNING_FORMAT = ssh
+INITIAL_COMMIT = always
+CRUD_ACTIONS = pubkey, twofa, parentsigned
+WIKI = never
+MERGES = pubkey, twofa, basesigned, commitssigned
+...
+```
+
+- `/path/to/gitea-signing-key` is expected to be the private key for `/path/to/gitea-signing-key.pub` [see here how to generate a new ssh keypair](#installing-and-generating-a-ssh-key-for-gitea).
+- `TRUSTED_SSH_KEYS = ssh-<algorithm> <key>` or `TRUSTED_SSH_KEYS = ssh-<algorithm> <key1>, ssh-<algorithm> <key2>` can be used for rotating the global ssh signing key to continue verifying commits signed by the previous keys.
+
 ### `SIGNING_KEY`
 
 The first option to discuss is the `SIGNING_KEY`. There are three main
 options:
 
 - `none` - this prevents Gitea from signing any commits
-- `default` - Gitea will default to the key configured within `git config`
+- `default` - Gitea will default to the gpg key configured within `git config`
 - `KEYID` - Gitea will sign commits with the gpg key with the ID
   `KEYID`. In this case you should provide a `SIGNING_NAME` and
   `SIGNING_EMAIL` to be displayed for this key.
+- `/path/to/gitea-signing-key.pub` - Gitea will sign commits with the ssh key without the `.pub` suffix `/path/to/gitea-signing-key`. In this case you should provide a `SIGNING_NAME` and
+  `SIGNING_EMAIL` to be displayed for this key and set `SIGNING_FORMAT` to `ssh`.
 
 The `default` option will interrogate `git config` for
 `commit.gpgsign` option - if this is set, then it will use the results
@@ -97,6 +129,10 @@ Related home files for git command (like `.gnupg`) should also be put in Gitea's
 If you like to keep the `.gnupg` directory outside of `{[git].HOME_PATH}/`, consider setting the `$GNUPGHOME` environment variable to your preferred location, otherwise Gitea will use the gpg keys only under `{[git].HOME_PATH}/.gnupg`.
 :::
 
+:::warning
+The default option and repository specific signing keys are not supported for ssh keys
+:::
+
 ### `INITIAL_COMMIT`
 
 This option determines whether Gitea should sign the initial commit
@@ -168,3 +204,9 @@ In cases where there is a repository specific key this can be obtained from:
 ```sh
 /api/v1/repos/:username/:reponame/signing-key.gpg
 ```
+
+For ssh commit signing the default ssh public key can be obtained via the API at:
+
+```sh
+/api/v1/signing-key.pub
+```

docs/development/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Development",
+  "position": 40,
+  "link": {
+    "type": "generated-index",
+    "slug": "/development",
+    "title": "Development"
+  }
+}

docs/development/api-usage.md

@@ -20,14 +20,33 @@ Gitea supports these methods of API authentication:
 - `token=...` parameter in URL query string
 - `access_token=...` parameter in URL query string
 - `Authorization: token ...` header in HTTP headers
+- HTTP signatures using an SSH public key or SSH certificate
 
 All of these methods accept the same API key token type. You can
 better understand this by looking at the code -- as of this writing,
 Gitea parses queries and headers to find the token in
 [modules/auth/auth.go](https://github.com/go-gitea/gitea/blob/6efdcaed86565c91a3dc77631372a9cc45a58e89/modules/auth/auth.go#L47).
 
+Gitea can also authenticate API requests using an SSH key or SSH certificate via
+HTTP signatures. The SSH public key (or certificate) must be registered to the
+user account in Gitea, and the client signs requests with the corresponding
+private key. The client signs requests using the SSH private key following the
+[draft-cavage-http-signatures](https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures)
+specification (not RFC 9421). The signature is sent in the `Signature` header,
+and SSH certificates additionally include an `x-ssh-certificate` header. The
+official [go-sdk](https://gitea.com/gitea/go-sdk) implements this flow if you
+need a reference implementation.
+
 ## Generating and listing API tokens
 
+API tokens can be created either in the user interface or via the API. Tokens have by default limited permissions and it is important to create tokens with the correct permissions for your task.
+### User Interface
+Tokens can be created via the `Manage Access Tokens` dialog, accessed via `User Settings` / `Applications` or via the link `gitea-domain.example/user/settings/applications`. The interface allows you to create tokens and manage their permissions via the `Select permissions` sub-menu.
+
+Once created, the token is displayed in a toast message above the `Manage Access Tokens` dialog. Please note, that you can view this toast only once and it is not possible to redisplay the token for security reasons.
+
+### Token API
+
 A new token can be generated with a `POST` request to
 `/users/:name/tokens`.
 
@@ -35,8 +54,10 @@ Note that `/users/:name/tokens` is a special endpoint and requires you
 to authenticate using `BasicAuth` and a password, as follows:
 
 ```sh
-$ curl -H "Content-Type: application/json" -d '{"name":"test"}' -u username:password https://gitea.your.host/api/v1/users/<username>/tokens
+$ curl -H "Content-Type: application/json" \
-{"id":1,"name":"test","sha1":"9fcb1158165773dd010fca5f0cf7174316c3e37d","token_last_eight":"16c3e37d"}
+-d '{"name":"test_token","scopes":["read:activitypub","read:issue", "write:misc", "read:notification", "read:organization", "read:package", "read:repository", "read:user"]}' \
+-u 'username:password' "https://gitea.your.host/api/v1/users/{username}/tokens"
+{"id":1,"name":"test_token","sha1":"9fcb1158165773dd010fca5f0cf7174316c3e37d","token_last_eight":"16c3e37d"}
 ```
 
 The ``sha1`` (the token) is only returned once and is not stored in
@@ -48,6 +69,25 @@ $ curl --url https://yourusername:[email protected]/api/v1/users/<usernam
 [{"name":"test","sha1":"","token_last_eight:"........":},{"name":"dev","sha1":"","token_last_eight":"........"}]
 ```
 
+By default, this creates a token with very limited permissions. To complete your tasks, your token may require extra permissions. These permissions are created via the json variable `scopes`, which takes an array of permissions as strings. Eg.: `"scopes":["all"]`. Possible permissions, as reflected in the user interface are:
+
+- `activitypub`
+- `admin`
+- `issue`
+- `misc`
+- `notification`
+- `organization`
+- `package`
+- `repository`
+- `user`
+
+Each permission may be set to `read` or `write`. `write` implies both Read & Write. To set permissions you write the permissions string as `<read or write>:<permission name>`, eg.: `write:package` or `read:notification`. A properly formatted API call may look like:
+
+```sh
+$ curl -H "Content-Type: application/json" -d '{"name":"test", "scopes":["write:package", "read:notification"]}' -u username:password https://gitea.your.host/api/v1/users/<username>/tokens
+```
+Special permissions `all` may be specified as `"scopes":["all"]`, which sets all permissions to both Read & Write.
+
 To use the API with basic authentication with two factor authentication
 enabled, you'll need to send an additional header that contains the one
 time password (6 digitrotating token).

docs/development/oauth2-provider.md

@@ -80,6 +80,7 @@ The approval page displayed to the user shows the list of scopes requested by th
 | OpenID Connect Discovery | `/.well-known/openid-configuration` |
 | Authorization Endpoint   | `/login/oauth/authorize`            |
 | Access Token Endpoint    | `/login/oauth/access_token`         |
+| Token Introspection Endpoint | `/login/oauth/introspect`           |
 | OpenID Connect UserInfo  | `/login/oauth/userinfo`             |
 | JSON Web Key Set         | `/login/oauth/keys`                 |
 

docs/help/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Help",
+  "position": 5,
+  "link": {
+    "type": "generated-index",
+    "slug": "/help",
+    "title": "Help"
+  }
+}

docs/help/faq.md

@@ -33,7 +33,7 @@ then the config file (app.ini) should exists in the "custom/conf" directory of y
 Some package vendors might use "/etc/gitea" to store the config file, while some others don't.
 
 You could manually find the config file (app.ini) by checking Gitea's startup logs
-or reading the Gitea Web's Site Administrator -> Confugiraton Summary.
+or reading the Gitea Web's Site Administrator -> Configuration Summary.
 
 If you are using some isolated enviroments like container (docker),
 the path you see usually is not what it is in the host's filesystem.
@@ -330,9 +330,9 @@ It is highly recommended to back-up your database before running these commands.
 
 - Add your (bare) repositories to the correct spot for your configuration (`repository.ROOT`), ensuring they are in the correct layout `<REPO_ROOT>/[user]/[repo].git`.
   - **Note:** the directory names must be lowercase.
-  - You can also check `<ROOT_URL>/admin/config` for the repository root path.
+  - You can also check `<ROOT_URL>/-/admin/config` for the repository root path.
 - Ensure that the user/org exists that you want to adopt repositories for.
-- As an admin, go to `<ROOT_URL>/admin/repos/unadopted` and search.
+- As an admin, go to `<ROOT_URL>/-/admin/repos/unadopted` and search.
   - Users can also be given similar permissions via config [`ALLOW_ADOPTION_OF_UNADOPTED_REPOSITORIES`](../administration/config-cheat-sheet.md#repository-repository).
 - If the above steps are done correctly, you should be able to select repositories to adopt.
   - If no repositories are found, enable [debug logging](../administration/config-cheat-sheet.md#repository-repository) to check for any specific errors.

docs/index.md

@@ -13,7 +13,7 @@ Gitea was originally forked from [Gogs](https://gogs.io) and almost all the code
 
 :::warning
 
-Gitea does not sent or cherry-picked commits from upstream, so there is no guarantee it will work if you upgrade from Gogs to Gitea. The recommended method is to migrate repositories from Gogs to Gitea.
+Gitea does not send commits to upstream or cherry-pick commits from it, so there is no guarantee it will work if you upgrade from Gogs to Gitea. The recommended method is to migrate repositories from Gogs to Gitea.
 
 :::
 
@@ -31,11 +31,11 @@ You can try it out using [the online demo](https://demo.gitea.com).
 
 - **Code Hosting**
 
-  Gitea supports creating and managing repositories, browsing commit history and code files, reviewing and merging code submissions, managing collaborators, handling branches, and more. It also supports many common Git features such as tags, Cherry-pick, hooks, integrated collaboration tools, and more.
+  Gitea supports creating and managing repositories, browsing commit history and code files, reviewing and merging code submissions, managing collaborators, handling branches, and more. It also supports many common Git features such as tags, cherry-picking, hooks, integrated collaboration tools, and more.
 
 - **Lightweight and Fast**
 
-  One of Gitea's design goals is to be lightweight and fast in response. Unlike some large code hosting platforms, it remains lean, performs well in terms of speed, and is suitable for resource-limited server environments. Due to its lightweight design, Gitea has relatively low resource consumption and performs well in resource-constrained environments.
+  One of Gitea's design goals is to be lightweight and fast in response. Unlike some large code hosting platforms, it remains lean, performs well in terms of speed, and is suitable for resource-limited server environments.
 
 - **Easy Deployment and Maintenance**
 
@@ -43,7 +43,7 @@ You can try it out using [the online demo](https://demo.gitea.com).
 
 - **Security**
 
-  Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, and more to ensure the security of code and data.
+  Gitea places a strong emphasis on security, offering features such as user permission management, access control lists, [audit logging](administration/audit-logging.md), and more to ensure the security of code and data.
 
 - **Code Review**
 
@@ -105,6 +105,6 @@ For more detailed information, please refer to: https://docs.gitea.com/installat
   - [github.com/mattn/go-sqlite3](https://github.com/mattn/go-sqlite3)
   - [github.com/denisenkom/go-mssqldb](https://github.com/denisenkom/go-mssqldb)
 
-## Integrated support
+## Integrated Support
 
  Please visit [Awesome Gitea](https://gitea.com/gitea/awesome-gitea/) to get more third-party integrated support

docs/installation/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Installation",
+  "position": 10,
+  "link": {
+    "type": "generated-index",
+    "slug": "/installation",
+    "title": "Installation"
+  }
+}

docs/installation/comparison.md

@@ -34,6 +34,7 @@ _Symbols used in table:_
 | Telemetry                                        | **✘**                                               | ✓         | ✓         | ✓         | ✓         | ✘            | ✘            |
 | Third-party render tool support                  | ✓                                                   | ✘         | ✘         | ✘         | ✓         | ✘            | ✘            |
 | WebAuthn (2FA)                                   | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✘            | ✓            |
+| Audit log                                        | ✓                                                   | ✓         | ⁄         | ✓         | ✓         | ?            | ?            |
 | Extensive API                                    | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
 | Built-in Package/Container Registry              | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
 | Sync commits to an external repo (push mirror)   | ✓                                                   | ✘         | ✓         | ✓         | ✘         | ✓            | ✓            |

docs/installation/database-preparation.md

@@ -24,9 +24,10 @@ All steps below requires that the database engine of your choice is installed on
 
 ## MySQL/MariaDB
 
-1. For remote database setup, you will need to make MySQL listen to your IP address. Edit `bind-address` option on `/etc/mysql/my.cnf` on database instance to:
+1. For remote database setup, you will need to make MySQL listen to your IP address. Configure the `bind-address` option in `/etc/mysql/my.cnf` on database instance by adding the following lines:
 
     ```ini
+    [mysqld]
     bind-address = 203.0.113.3
     ```
 

docs/installation/from-binary.md

@@ -40,19 +40,37 @@ chmod +x gitea
 
 Note that the above command will download Gitea @version@ for 64-bit Linux.
 
-## Verify GPG signature
+## Verify signature
+
+### Sigstore
+
+Starting with v1.27 Gitea signs all binaries using [sigstore](https://sigstore.dev/) to prevent against unwanted modification of binaries.
+To validate the binary, download the bundle file which ends in `sigstore.json` for the binary you downloaded and use the [cosign](https://docs.sigstore.dev/cosign/system_config/installation/) command line tool.
+
+```sh
+cosign verify-blob gitea-@version@-linux-amd64 --bundle gitea-@[email protected] --certificate-oidc-issuer=https://token.actions.githubusercontent.com --certificate-identity-regexp="https://github.com/go-gitea/gitea/.github/workflows/release-.*"
+```
+
+If the command outputs `Verified OK`, binary was not modified.
+
+:::note
+The above command will match any release workflow. You may choose to restrict the identity further by requiring a specific branch or workflow to be matched. For example this url will match only nightly builds made on main branch: `https://github.com/go-gitea/gitea/.github/workflows/release-nightly.yml@refs/heads/main`
+:::
+
+### GPG
 
 Gitea signs all binaries with a [GPG key](https://keys.openpgp.org/search?q=teabot%40gitea.io) to prevent against unwanted modification of binaries.
 To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the GPG command line tool.
 
 ```sh
-gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
+gpg --keyserver hkps://keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
 gpg --verify gitea-@[email protected] gitea-@version@-linux-amd64
 ```
 
 Look for the text `Good signature from "Teabot <[email protected]>"` to assert a good binary,
 despite warnings like `This key is not certified with a trusted signature!`.
 
+
 ## Recommended server configuration
 
 :::note
@@ -139,20 +157,27 @@ export GITEA_WORK_DIR=/var/lib/gitea/
 cp gitea /usr/local/bin/gitea
 ```
 
-### Adding bash/zsh autocompletion (from 1.19)
 
-A script to enable bash-completion can be found at [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete). This can be copied to `/usr/share/bash-completion/completions/gitea`
+### Adding shell autocompletion (from 1.25)
-or sourced within your `.bashrc`.
 
-Similarly a script for zsh-completion can be found at [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete). This can be copied to `/usr/share/zsh/_gitea` or sourced within your
+Shell completion can be generated directly from binary with:
-`.zshrc`.
+```sh
+gitea completion <shell>
+```
 
-YMMV and these scripts may need further improvement.
+Supported values for `<shell>` are `bash`, `fish`, `pwsh` and `zsh`. Details on how to load the completion for your shell can be found in the completion command help.
 
 ## Running Gitea
 
 After you complete the above steps, you can run Gitea two ways:
 
+:::note
+On a distribution with SELinux in enforcing mode (Fedora, RHEL, CentOS Stream,
+Rocky Linux, AlmaLinux and others), the binary and the data directory need
+labels the default policy does not give them, and binding to a port below 1024
+takes an extra step. See [running Gitea with SELinux](selinux.md).
+:::
+
 ### 1. Creating a service file to start Gitea automatically (recommended)
 
 See how to create [Linux service](installation/run-as-service-in-ubuntu.md)
@@ -214,9 +239,7 @@ As of v1.8, there is a problem with the arm7 version of Gitea, and it doesn't ru
 
 It is recommended to switch to the arm6 version, which has been tested and shown to work on Raspberry Pis and similar devices.
 
-<!---
+{/* please remove after fixing the arm7 bug */}
-please remove after fixing the arm7 bug
---->
 ### Git error after updating to a new version of Gitea
 
 If during the update, the binary file name has been changed to a new version of Gitea,

docs/installation/from-source.md

@@ -6,6 +6,8 @@ aliases:
   - /en-us/install-from-source
 ---
 
+:::warning This document is outdated, pleaes refer to [build-source.md](https://github.com/go-gitea/gitea/tree/main/docs/build-source.md):::
+
 # Installation from source
 
 You should [install go](https://go.dev/doc/install) and set up your go
@@ -125,6 +127,12 @@ launched manually from command line, it can be killed by pressing `Ctrl + C`.
 ./gitea web
 ```
 
+:::note
+A binary built this way carries no SELinux label of its own. On a distribution
+with SELinux in enforcing mode, see
+[running Gitea with SELinux](selinux.md) before installing it as a service.
+:::
+
 ## Changing default paths
 
 Gitea will search for a number of things from the _`CustomPath`_. By default this is
@@ -178,15 +186,14 @@ LDFLAGS="-linkmode external -extldflags '-static' $LDFLAGS" TAGS="netgo osusergo
 
 This can be combined with `CC`, `GOOS`, and `GOARCH` as above.
 
-### Adding bash/zsh autocompletion (from 1.19)
+### Adding shell autocompletion (from 1.25)
 
-A script to enable bash-completion can be found at [`contrib/autocompletion/bash_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/bash_autocomplete). This should be altered as appropriate and can be `source` in your `.bashrc`
+Shell completion can be generated directly from binary with:
-or copied as `/usr/share/bash-completion/completions/gitea`.
+```sh
+gitea completion <shell>
+```
 
-Similarly, a script for zsh-completion can be found at [`contrib/autocompletion/zsh_autocomplete`](https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/autocompletion/zsh_autocomplete). This can be copied to `/usr/share/zsh/_gitea` or sourced within your
+Supported values for `<shell>` are `bash`, `fish`, `pwsh` and `zsh`. Details on how to load the completion for your shell can be found in the completion command help.
-`.zshrc`.
-
-YMMV and these scripts may need further improvement.
 
 ## Compile or cross-compile using Linux with Zig
 

docs/installation/on-cloud-provider.md

@@ -41,3 +41,9 @@ 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).

docs/installation/run-as-service-in-ubuntu.md

@@ -12,7 +12,7 @@ You can run Gitea as a Linux service, using either systemd or supervisor. The st
 
 ## Using systemd
 
-Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) to `/etc/systemd/system/gitea.service`, then edit the file with your favorite editor.
+Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/service/systemd/gitea.service) to `/etc/systemd/system/gitea.service`, then edit the file with your favorite editor.
 
 Uncomment any service that needs to be enabled on this host, such as MySQL.
 
@@ -48,7 +48,7 @@ mkdir /home/git/gitea/log/supervisor
 ```
 
 Append the configuration from the sample
-[supervisord config](https://github.com/go-gitea/gitea/blob/main/contrib/supervisor/gitea) to `/etc/supervisor/supervisord.conf`.
+[supervisord config](https://github.com/go-gitea/gitea/blob/main/contrib/service/supervisor/gitea) to `/etc/supervisor/supervisord.conf`.
 
 Using your favorite editor, change the user (`git`) and home
 (`/home/git`) settings to match the deployment environment. Change the PORT

docs/installation/selinux.md

@@ -0,0 +1,109 @@
+---
+date: "2026-08-13T00:00:00+00:00"
+slug: "selinux"
+sidebar_position: 45
+---
+
+# Running Gitea with SELinux
+
+Distributions such as Fedora, RHEL, CentOS Stream, Rocky Linux and AlmaLinux
+ship SELinux in enforcing mode. Packages from a distribution repository come
+with a policy that fits them, but an installation
+[from binary](from-binary.md) or [from source](from-source.md) puts the binary
+and the data in paths the policy knows nothing about, so the labels have to be
+set by hand. The same applies to any other distribution where SELinux is
+enabled.
+
+Do not turn SELinux off to work around the problems below. `setenforce 0` is
+useful to confirm that a failure really comes from SELinux, but switch it back
+on with `setenforce 1` afterwards.
+
+## Binding to a port below 1024
+
+Gitea should not run as root, and an unprivileged process may not bind to a
+port below 1024. Granting the capability to the binary with
+`setcap 'cap_net_bind_service=+ep' /usr/local/bin/gitea` is often suggested,
+but it is the least robust option:
+
+- file capabilities are stored in an extended attribute of the binary, so they
+  are lost every time the binary is replaced, which happens on every upgrade.
+- the SELinux policy has to allow the capability for the label of the binary,
+  and a binary in a path such as `/opt` usually does not carry a label that
+  allows it.
+
+Let systemd grant the capability to the process instead. It works with SELinux
+in enforcing mode and survives upgrades, the sample unit file has the two lines
+commented out:
+
+```ini title="/etc/systemd/system/gitea.service"
+[Service]
+CapabilityBoundingSet=CAP_NET_BIND_SERVICE
+AmbientCapabilities=CAP_NET_BIND_SERVICE
+```
+
+Reload and restart the service afterwards:
+
+```sh
+sudo systemctl daemon-reload
+sudo systemctl restart gitea
+```
+
+If the capability still does not reach the process, add `PrivateUsers=false` to
+the unit: the sandboxing runs the service in a user namespace where the
+capability does not apply to the host.
+
+Two alternatives avoid the privileged port altogether, and are what most
+installations end up doing:
+
+- put a [reverse proxy](../administration/reverse-proxies.md) in front of Gitea
+  and let it own ports `80` and `443`.
+- redirect the port in the firewall, for example with
+  `firewall-cmd --permanent --add-forward-port=port=80:proto=tcp:toport=3000`.
+
+## Labelling the binary and the data directory
+
+If Gitea starts but cannot read its own files, or fails in ways that are not
+explained by the file permissions, the labels are usually wrong. The tools come
+from the `policycoreutils-python-utils` package.
+
+Label the binary as an executable and the data directory as application state:
+
+```sh
+sudo semanage fcontext -a -t bin_t '/usr/local/bin/gitea'
+sudo restorecon -v /usr/local/bin/gitea
+
+sudo semanage fcontext -a -t var_lib_t '/var/lib/gitea(/.*)?'
+sudo restorecon -Rv /var/lib/gitea
+```
+
+`semanage fcontext` records the rule, `restorecon` applies it to the files that
+are already there. Use the two together rather than `chcon`, whose labels are
+reverted by the next relabel of the file system.
+
+Adjust the paths if the installation does not follow
+[installation from binary](from-binary.md); the configuration in `/etc/gitea`
+is read with the label distributions give to `/etc`, so it normally needs
+nothing.
+
+## Finding out what was denied
+
+SELinux denials are written to the audit log, not to the Gitea log, so a
+failure often looks like a permission problem without any further explanation:
+
+```sh
+sudo ausearch -m AVC -c gitea --start recent
+```
+
+If a denial shows up that the rules above do not cover, turn it into a local
+policy module. Read what it allows before installing it, `audit2allow` writes
+down whatever was denied, including the things that were denied for a good
+reason:
+
+```sh
+sudo ausearch -c gitea --raw | audit2allow -M gitea-local
+cat gitea-local.te
+sudo semodule -i gitea-local.pp
+```
+
+If the denials point at a path Gitea should not be using at all, fix the path
+instead of allowing the access.

docs/installation/with-docker-rootless.md

@@ -8,19 +8,23 @@ aliases:
 
 # Installation with Docker (rootless)
 
-Gitea provides automatically updated Docker images within its Docker Hub organization. It is
+## Relation to rootful image
-possible to always use the latest stable tag or to use another service that handles updating
-Docker images.
 
-The rootless image uses Gitea internal SSH to provide Git protocol and doesn't support OpenSSH.
+* Rootless image doesn't require "root" privilege on the host, while it may have stricter UID/GID requirement.
+* Rootless image must use its bulitin SSH server, while the rootful one must its managed standalone OpenSSH server.
+* The volume mapping and directory layout is different between them.
 
-This reference setup guides users through the setup based on `docker-compose`, but the installation
+Except the differences above, the rootless image shares the same mechanism with rootful image,
-of `docker-compose` is out of scope of this documentation. To install `docker-compose` itself, follow
+including: port mapping, custimzation, upgrading, environment variables, etc.
-the official [install instructions](https://docs.docker.com/compose/install/).
+Read more in "[Installation with Docker (rootful)](./with-docker.md)"
+
+ATTENTION: the rootful/rootless images are not compatible with the other.
+If you have chosen one, you should always use the same one,
+don't switch to the other one by changing the compose file's `image` value.
 
 ## Basics
 
-The most simple setup just creates a volume and a network and starts the `docker.io/gitea/gitea:latest-rootless`
+The most simple setup just creates a volume and a network and starts the `docker.gitea.com/gitea:latest-rootless`
 image as a service. Since there is no database available, one can be initialized using SQLite3.
 
 Create a directory for `data` and `config`:
@@ -34,11 +38,9 @@ touch docker-compose.yml
 Then paste the following content into a file named `docker-compose.yml`:
 
 ```yaml
-version: "2"
-
 services:
   server:
-    image: docker.io/gitea/gitea:@dockerVersion@-rootless
+    image: docker.gitea.com/gitea:@dockerVersion@-rootless
     restart: always
     volumes:
       - ./data:/var/lib/gitea
@@ -56,115 +58,15 @@ Note that the volume should be owned by the user/group with the UID/GID specifie
 sudo chown 1000:1000 config/ data/
 ```
 
-> If you don't give the volume correct permissions, the container may not start.
+> If you don't give the volume correct permissions, the container may present the following errors in the logs:
 
-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`)
+```sh
-
+server-1  | 2026-03-11T12:57:50.794102045Z mkdir: can't create directory '/var/lib/gitea/git': Permission denied
-## Custom port
+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
-To bind the integrated ssh and the webserver on a different port, adjust
-the port section. It's common to just change the host port and keep the ports within
-the container like they are.
-
-```diff
-version: "2"
-
-services:
-  server:
-    image: docker.io/gitea/gitea:@dockerVersion@-rootless
-    restart: always
-    volumes:
-      - ./data:/var/lib/gitea
-      - ./config:/etc/gitea
-      - /etc/timezone:/etc/timezone:ro
-      - /etc/localtime:/etc/localtime:ro
-    ports:
--      - "3000:3000"
--      - "2222:2222"
-+      - "80:3000"
-+      - "22:2222"
 ```
 
-## MySQL database
+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`)
-
-To start Gitea in combination with a MySQL database, apply these changes to the
-`docker-compose.yml` file created above.
-
-```diff
-version: "2"
-
-services:
-  server:
-    image: docker.io/gitea/gitea:@dockerVersion@-rootless
-+    environment:
-+      - GITEA__database__DB_TYPE=mysql
-+      - GITEA__database__HOST=db:3306
-+      - GITEA__database__NAME=gitea
-+      - GITEA__database__USER=gitea
-+      - GITEA__database__PASSWD=gitea
-    restart: always
-    volumes:
-      - ./data:/var/lib/gitea
-      - ./config:/etc/gitea
-      - /etc/timezone:/etc/timezone:ro
-      - /etc/localtime:/etc/localtime:ro
-    ports:
-      - "3000:3000"
-      - "2222:2222"
-+    depends_on:
-+      - db
-+
-+  db:
-+    image: docker.io/library/mysql:8
-+    restart: always
-+    environment:
-+      - MYSQL_ROOT_PASSWORD=gitea
-+      - MYSQL_USER=gitea
-+      - MYSQL_PASSWORD=gitea
-+      - MYSQL_DATABASE=gitea
-+    volumes:
-+      - ./mysql:/var/lib/mysql
-```
-
-## PostgreSQL database
-
-To start Gitea in combination with a PostgreSQL database, apply these changes to
-the `docker-compose.yml` file created above.
-
-```diff
-version: "2"
-
-services:
-  server:
-    image: docker.io/gitea/gitea:@dockerVersion@-rootless
-    environment:
-+      - GITEA__database__DB_TYPE=postgres
-+      - GITEA__database__HOST=db:5432
-+      - GITEA__database__NAME=gitea
-+      - GITEA__database__USER=gitea
-+      - GITEA__database__PASSWD=gitea
-    restart: always
-    volumes:
-      - ./data:/var/lib/gitea
-      - ./config:/etc/gitea
-      - /etc/timezone:/etc/timezone:ro
-      - /etc/localtime:/etc/localtime:ro
-    ports:
-      - "3000:3000"
-      - "2222:2222"
-+    depends_on:
-+      - db
-+
-+  db:
-+    image: docker.io/library/postgres:14
-+    restart: always
-+    environment:
-+      - POSTGRES_USER=gitea
-+      - POSTGRES_PASSWORD=gitea
-+      - POSTGRES_DB=gitea
-+    volumes:
-+      - ./postgres:/var/lib/postgresql/data
-```
 
 ## Named volumes
 
@@ -174,8 +76,6 @@ create the required volume. You don't need to worry about permissions with
 named volumes; Docker will deal with that automatically.
 
 ```diff
-version: "2"
-
 +volumes:
 +  gitea-data:
 +    driver: local
@@ -184,7 +84,7 @@ version: "2"
 +
 services:
   server:
-    image: docker.io/gitea/gitea:@dockerVersion@-rootless
+    image: docker.gitea.com/gitea:@dockerVersion@-rootless
     restart: always
     volumes:
 -      - ./data:/var/lib/gitea
@@ -207,11 +107,9 @@ As an example to clone the host user `git` definition use the command `id -u git
 Please make sure that the mounted folders are writable by the user.
 
 ```diff
-version: "2"
-
 services:
   server:
-    image: docker.io/gitea/gitea:@dockerVersion@-rootless
+    image: docker.gitea.com/gitea:@dockerVersion@-rootless
     restart: always
 +    user: 1001
     volumes:
@@ -223,143 +121,3 @@ services:
       - "3000:3000"
       - "2222:2222"
 ```
-
-## Startup
-
-:::note
-From July 2023 Compose V1 stopped receiving updates. It's also no longer available in new releases of Docker Desktop.
-
-Compose V2 is included with all currently supported versions of Docker Desktop. Please use V2 to do below operations.
-:::
-
-To start this setup based on `docker-compose`, execute `docker-compose up -d`,
-to launch Gitea in the background. Using `docker-compose ps` will show if Gitea
-started properly. Logs can be viewed with `docker-compose logs`.
-
-To shut down the setup, execute `docker-compose down`. This will stop
-and kill the containers. The volumes will still exist.
-
-:::note
-If using a non-3000 port on http, change app.ini to match
-`LOCAL_ROOT_URL = http://localhost:3000/`.
-:::
-
-## Install
-
-After starting the Docker setup via `docker-compose`, Gitea should be available using a
-favorite browser to finalize the installation. Visit http://server-ip:3000 and follow the
-installation wizard. If the database was started with the `docker-compose` setup as
-documented above, please note that `db` must be used as the database hostname.
-
-## Customization
-
-Customization files described [here](../administration/customizing-gitea.md) should
-be placed in `/var/lib/gitea/custom` directory. If using host volumes, it's quite easy to access these
-files; for named volumes, this is done through another container or by direct access at
-`/var/lib/docker/volumes/gitea_gitea/_/var_lib_gitea`. The configuration file will be saved at
-`/etc/gitea/app.ini` after the installation.
-
-## Upgrading
-
-:::warning
-:exclamation::exclamation: **Make sure you have volumed data to somewhere outside Docker container** :exclamation::exclamation:
-:::
-
-To upgrade your installation to the latest release:
-
-```bash
-# Edit `docker-compose.yml` to update the version, if you have one specified
-# Pull new images
-docker-compose pull
-# Start a new container, automatically removes old one
-docker-compose up -d
-```
-
-## Upgrading from standard image
-
-- Backup your setup
-- Change volume mountpoint from /data to /var/lib/gitea
-- If you used a custom app.ini move it to a new volume mounted to /etc/gitea
-- Rename folder (inside volume) gitea to custom
-- Edit app.ini if needed
-  - Set START_SSH_SERVER = true
-- Use image docker.io/gitea/gitea:@dockerVersion@-rootless
-
-## Managing Deployments With Environment Variables
-
-In addition to the environment variables above, any settings in `app.ini` can be set
-or overridden with an environment variable of the form: `GITEA__SECTION_NAME__KEY_NAME`.
-These settings are applied each time the docker container starts, and won't be passed into Gitea's sub-processes.
-Full information [here](https://github.com/go-gitea/gitea/tree/main/contrib/environment-to-ini).
-
-These environment variables can be passed to the docker container in `docker-compose.yml`.
-The following example will enable a smtp mail server if the required env variables
-`GITEA__mailer__FROM`, `GITEA__mailer__HOST`, `GITEA__mailer__PASSWD` are set on the host
-or in a `.env` file in the same directory as `docker-compose.yml`.
-
-The settings can be also set or overridden with the content of a file by defining an environment variable of the form:
-`GITEA__section_name__KEY_NAME__FILE` that points to a file.
-
-```bash
-...
-services:
-  server:
-    environment:
-      - GITEA__mailer__ENABLED=true
-      - GITEA__mailer__FROM=${GITEA__mailer__FROM:?GITEA__mailer__FROM not set}
-      - GITEA__mailer__PROTOCOL=smtp
-      - GITEA__mailer__HOST=${GITEA__mailer__HOST:?GITEA__mailer__HOST not set}
-      - GITEA__mailer__IS_TLS_ENABLED=true
-      - GITEA__mailer__USER=${GITEA__mailer__USER:-apikey}
-      - GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
-```
-
-To set required TOKEN and SECRET values, consider using Gitea's built-in [generate utility functions](../administration/command-line.md#generate).
-
-# SSH Container Passthrough
-
-Since SSH is running inside the container, SSH needs to be passed through from the host to the container if SSH support is desired. One option would be to run the container SSH on a non-standard port (or moving the host port to a non-standard port). Another option which might be more straightforward is to forward SSH commands from the host to the container. This setup is explained in the following.
-
-This guide assumes that you have created a user on the host called `git` with permission to run `docker exec`, and that the Gitea container is called `gitea`. You will need to modify that user's shell to forward the commands to the `sh` executable inside the container, using `docker exec`.
-
-First, create the file `/usr/local/bin/gitea-shell` on the host, with the following contents:
-
-```bash
-#!/bin/sh
-/usr/bin/docker exec -i --env SSH_ORIGINAL_COMMAND="$SSH_ORIGINAL_COMMAND" gitea sh "$@"
-```
-
-Note that `gitea` in the docker command above is the name of the container. If you named yours differently, don't forget to change that.
-
-You should also make sure that you’ve set the permissions of the shell wrapper correctly:
-
-```bash
-sudo chmod +x /usr/local/bin/gitea-shell
-```
-
-Once the wrapper is in place, you can make it the shell for the `git` user:
-
-```bash
-sudo usermod -s /usr/local/bin/gitea-shell git
-```
-
-Now that all the SSH commands are forwarded to the container, you need to set up the SSH authentication on the host. This is done by leveraging the [SSH AuthorizedKeysCommand](../administration/command-line.md#keys) to match the keys against those accepted by Gitea. Add the following block to `/etc/ssh/sshd_config`, on the host:
-
-```bash
-Match User git
-  AuthorizedKeysCommandUser git
-  AuthorizedKeysCommand /usr/bin/docker exec -i gitea /usr/local/bin/gitea keys -c /etc/gitea/app.ini -e git -u %u -t %t -k %k
-```
-
-(From 1.16.0 you will not need to set the `-c /etc/gitea/app.ini` option.)
-
-All that is left to do is restart the SSH server:
-
-```bash
-sudo systemctl restart sshd
-```
-
-**Notes**
-
-This isn't actually using the docker SSH - it is simply using the commands around it.
-You could theoretically not run the internal SSH server.

docs/installation/with-podman-quadlet.md

@@ -0,0 +1,166 @@
+---
+date: "2026-09-03T20:00:00+02:00"
+slug: "install-with-podman-quadlet"
+sidebar_position: 65
+aliases:
+  - /en-us/install-with-podman-quadlet
+---
+
+# Installation with Podman Quadlet
+
+Similarly to [Docker](with-docker.md), [Podman](https://podman.io/) can be used to deploy Gitea.
+
+This reference setup guides users through the setup based on Podman Quadlet.
+Podman Quadlet is the native integration of Podman through systemd.
+
+To learn more about Podman Quadlet, see [systemd units using Podman Quadlet](https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html).
+
+This setup installs the quadlets in `~/.config/containers/systemd/`, the directory for rootless quadlets, and uses the rootless images.
+If you install them in a rootful directory such as `/etc/containers/systemd/`, use the rootful images instead.
+
+## Basics
+
+Since Podman v6.0 a single `gitea.quadlets` file can hold multiple quadlets separated by the `---` delimiter.
+
+Paste the following content into a file named `gitea.quadlets`
+
+```ini
+# FileName=gitea-data
+[Volume]
+VolumeName=gitea-data
+---
+# FileName=gitea-config
+[Volume]
+VolumeName=gitea-config
+---
+# FileName=gitea
+[Container]
+PublishPort=2222:2222
+PublishPort=3000:3000
+Image=docker.gitea.com/gitea:@dockerVersion@-rootless
+ContainerName=gitea
+Mount=type=volume,src=gitea-data.volume,destination=/var/lib/gitea
+Mount=type=volume,src=gitea-config.volume,destination=/etc/gitea
+
+[Service]
+Restart=always
+
+[Install]
+# Start with the user session
+WantedBy=default.target
+```
+
+You can run the installation command
+
+```sh
+$ podman quadlet install ./gitea.quadlets --application=gitea
+/home/user/.config/containers/systemd/gitea/gitea-data.volume
+/home/user/.config/containers/systemd/gitea/gitea-config.volume
+/home/user/.config/containers/systemd/gitea/gitea.container
+```
+
+The `--application=gitea` flag allows us to tell podman to group the quadlets together, this can help for managing and organizing the quadlets files.
+
+You can validate the quadlets are properly installed by looking at the list command
+
+```sh
+$ podman quadlet list
+NAME                 UNIT NAME                    PATH ON DISK                                                     STATUS         APPLICATION  POD
+gitea-config.volume  gitea-config-volume.service  /home/user/.config/containers/systemd/gitea/gitea-config.volume  active/exited  gitea
+gitea-data.volume    gitea-data-volume.service    /home/user/.config/containers/systemd/gitea/gitea-data.volume    active/exited  gitea
+gitea.container      gitea.service                /home/user/.config/containers/systemd/gitea/gitea.container      failed/failed  gitea
+```
+
+You can start the application by running `systemctl --user start gitea` command.
+
+`WantedBy=default.target` starts the service when the user session starts.
+Rootless user services do not run without a session, so to start Gitea at boot, enable lingering for the user with `loginctl enable-linger $USER`.
+
+## Databases
+
+### PostgreSQL database
+
+To start Gitea in combination with a PostgreSQL database, apply these changes to the
+`gitea.quadlets` file created above.
+
+To start Gitea with a database, we need to create a network, so the database and Gitea container can communicate.
+
+```diff
+# FileName=gitea-data
+[Volume]
+VolumeName=gitea-data
+---
+# FileName=gitea-config
+[Volume]
+VolumeName=gitea-config
+---
++ # FileName=gitea-postgres-data
++ [Volume]
++ VolumeName=gitea-postgres-data
++ ---
++ # FileName=gitea
++ [Network]
++ NetworkName=gitea
++ ---
++ # FileName=gitea-postgres
++ [Container]
++ Image=docker.io/library/postgres:18
++ ContainerName=gitea-postgres
++ Network=gitea.network
++ Mount=type=volume,src=gitea-postgres-data.volume,destination=/var/lib/postgresql
++ Environment=POSTGRES_USER=gitea
++ Environment=POSTGRES_PASSWORD=gitea
++ Environment=POSTGRES_DB=gitea
++
++ [Service]
++ Restart=always
++
++ [Install]
++ # Start with the user session
++ WantedBy=default.target
++ ---
+# FileName=gitea
++ [Unit]
++ Requires=gitea-postgres.service
++ After=gitea-postgres.service
++
+[Container]
+PublishPort=2222:2222
+PublishPort=3000:3000
+Image=docker.gitea.com/gitea:@dockerVersion@-rootless
+ContainerName=gitea
+Mount=type=volume,src=gitea-data.volume,destination=/var/lib/gitea
+Mount=type=volume,src=gitea-config.volume,destination=/etc/gitea
++ Network=gitea.network
++ Environment=GITEA__database__DB_TYPE=postgres
++ Environment=GITEA__database__HOST=gitea-postgres:5432
++ Environment=GITEA__database__NAME=gitea
++ Environment=GITEA__database__USER=gitea
++ Environment=GITEA__database__PASSWD=gitea
+
+[Service]
+Restart=always
+
+[Install]
+# Start with the user session
+WantedBy=default.target
+```
+
+## Logs
+
+As systemd manages the container we can use `journalctl` to access the logs
+
+```sh
+$ journalctl --user --follow --unit=gitea.service
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:263:runWeb() [I] Starting Gitea on PID: 2
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:115:showWebStartupMessage() [I] Gitea version: 1.27.3 built with go1.26.7-X:jsonv2 : bindata, timetzdata,
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:116:showWebStartupMessage() [I] * RunMode: prod
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:117:showWebStartupMessage() [I] * AppPath: /usr/local/bin/gitea
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:118:showWebStartupMessage() [I] * WorkPath: /var/lib/gitea
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:119:showWebStartupMessage() [I] * CustomPath: /var/lib/gitea/custom
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:120:showWebStartupMessage() [I] * ConfigFile: /etc/gitea/app.ini
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:121:showWebStartupMessage() [I] Prepare to run install page
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:329:listen() [I] Listen: http://0.0.0.0:3000
+gitea[5967]: 2026/09/03 14:50:42 cmd/web.go:333:listen() [I] AppURL(ROOT_URL): http://localhost:3000/
+gitea[5967]: 2026/09/03 14:50:42 modules/graceful/server.go:52:NewServer() [I] Starting new Web server: tcp:0.0.0.0:3000 on PID: 2
+```

docs/usage/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Usage",
+  "position": 35,
+  "link": {
+    "type": "generated-index",
+    "slug": "/usage",
+    "title": "Usage"
+  }
+}

docs/usage/access-control/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Access Control",
+  "position": 100,
+  "link": {
+    "type": "generated-index",
+    "slug": "/usage/access-control",
+    "description": "Permissions, security, and access control features"
+  }
+}

docs/usage/access-control/blocking-users.md

@@ -0,0 +1,47 @@
+---
+date: "2024-01-31T00:00:00+00:00"
+slug: "blocking-user"
+sidebar_position: 25
+aliases:
+  - /blocking-user
+---
+
+# Blocking a user
+
+Gitea supports blocking of users to restrict how they can interact with you and your content.
+
+You can block a user in your account settings, from the user's profile or from comments created by the user.
+The user is not directly notified about the block, but they can notice they are blocked when they attempt to interact with you.
+Organization owners can block anyone who is not a member of the organization too.
+If a blocked user has admin permissions, they can still perform all actions even if blocked.
+
+### When you block a user
+
+- the user stops following you
+- you stop following the user
+- the user's stars are removed from your repositories
+- your stars are removed from their repositories
+- the user stops watching your repositories
+- you stop watching their repositories
+- the user's issue assignments are removed from your repositories
+- your issue assignments are removed from their repositories
+- the user is removed as a collaborator on your repositories
+- you are removed as a collaborator on their repositories
+- any pending repository transfers to or from the blocked user are canceled
+
+### When you block a user, the user cannot
+
+- follow you
+- watch your repositories
+- star your repositories
+- fork your repositories
+- transfer repositories to you
+- open issues or pull requests on your repositories
+- comment on issues or pull requests you've created
+- comment on issues or pull requests on your repositories
+- react to your comments on issues or pull requests
+- react to comments on issues or pull requests on your repositories
+- assign you to issues or pull requests
+- add you as a collaborator on their repositories
+- send you notifications by @mentioning your username
+- be added as team member (if blocked by an organization)