docs: clarify that team package permissions cover the whole org (#605)

Packages belong to the owner, so a team's packages permission covers every package of the organization, regardless of the team's repositories. State that in the access restrictions section, matching the team settings change in https://github.com/go-gitea/gitea/pull/39953.

The old note announced a dedicated team permission for finer control, which has existed since the packages unit was added, so it is replaced.

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

.editorconfig

@@ -0,0 +1,13 @@
+root = true
+
+[*]
+indent_style = space
+indent_size = 2
+tab_width = 2
+end_of_line = lf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = true
+
+[Makefile]
+indent_style = tab

.gitattributes

@@ -0,0 +1 @@
+* text=auto eol=lf

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

@@ -0,0 +1,48 @@
+name: Build and Publish Docs site
+run-name: astro build docs site
+
+on:
+  push:
+    branches:
+      - main
+
+jobs:
+  build-docs:
+    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@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+      - uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6
+      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7
+        with:
+          node-version: 24
+          cache: pnpm
+      - name: prepare awesome list
+        run: |
+          make prepare-awesome-latest prepare-awesome\#27 prepare-awesome\#26 prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22 prepare-awesome-v28
+      - name: Install dependencies
+        run: pnpm install --frozen-lockfile
+
+      - 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: |
+          # cloudflare/_headers and cloudflare/_redirects are only meaningful for
+          # the Cloudflare Pages deployment, so they are copied into the build
+          # right before the deploy.
+          cp cloudflare/_headers sites/docs/dist/_headers
+          cp cloudflare/_redirects sites/docs/dist/_redirects
+          test -f sites/docs/dist/_headers -a -f sites/docs/dist/_redirects || exit 1
+          pnpm dlx wrangler@4 pages deploy sites/docs/dist \
+            --project-name docs-gitea-com \
+            --branch main

.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

@@ -0,0 +1,103 @@
+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@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+      - uses: pnpm/action-setup@0977fd99725f1db4007ccb2928dbb4e90d06cc86 # v6
+      - uses: actions/setup-node@949feb2413d6458794dcd2491c4babbbce0c15c1 # v7
+        with:
+          node-version: 24
+          cache: pnpm
+      - name: prepare awesome list
+        run: |
+          make prepare-awesome-latest prepare-awesome\#27 prepare-awesome\#26 prepare-awesome\#25 prepare-awesome\#24 prepare-awesome\#23 prepare-awesome\#22 prepare-awesome-v28
+
+      - name: install dependencies
+        run: pnpm install --frozen-lockfile
+
+      - 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: |
+          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 "::notice::no Cloudflare credentials available (pull request from a fork?), 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

@@ -0,0 +1,110 @@
+name: update api spec files
+
+on:
+  schedule:
+    - cron: '0 3 * * 1' # every Monday at 03:00
+  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@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7
+        with:
+          ref: main
+          # pushing uses DEPLOY_TOKEN, keep the ephemeral job token out of .git/config
+          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
+
+          if git diff --quiet -- $LATEST_FILES; then
+            echo "the api documents are 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 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

@@ -0,0 +1,23 @@
+# Dependencies
+node_modules
+
+# Build output
+sites/*/dist
+sites/*/.astro
+sites/*/.cache
+build/
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*
+
+.tmp/
+awesome/
+awesome.md

LICENSE

@@ -0,0 +1,202 @@
+
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

Makefile

@@ -0,0 +1,100 @@
+GITEA_AWESOME_REMOTE := https://gitea.com/gitea/awesome-gitea.git
+GITEA_AWESOME_BRANCH := main
+
+.PHONY: all
+all: build
+
+.PHONY: create_dir
+create_dir:
+	mkdir -p .tmp
+
+.PHONY: clone_awesome
+clone_awesome: create_dir
+	git clone --branch=$(GITEA_AWESOME_BRANCH) $(GITEA_AWESOME_REMOTE) .tmp/upstream-awesome || true
+
+# the contributing guide moved to the gitea repository, the readme of
+# awesome-gitea still links to it with a relative path
+AWESOME_CONTRIBUTING_URL := https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md
+FIX_AWESOME_LINKS := sed 's|](contributing.md)|]($(AWESOME_CONTRIBUTING_URL))|'
+
+.PHONY: prepare-awesome-latest
+prepare-awesome-latest: clone_awesome
+	$(FIX_AWESOME_LINKS) .tmp/upstream-awesome/README.md > docs/awesome.md
+
+.PHONY: prepare-awesome\#%
+prepare-awesome\#%:
+	$(FIX_AWESOME_LINKS) .tmp/upstream-awesome/README.md > versioned_docs/version-1.$*/awesome.md
+
+# versions numbered without the 1. prefix, like 28
+.PHONY: prepare-awesome-v%
+prepare-awesome-v%:
+	$(FIX_AWESOME_LINKS) .tmp/upstream-awesome/README.md > versioned_docs/version-$*/awesome.md
+
+.PHONY: install
+install:
+	pnpm install
+
+.PHONY: prepare-docs
+prepare-docs: install prepare-awesome-latest prepare-awesome\#22 prepare-awesome\#23 prepare-awesome\#24 prepare-awesome\#25 prepare-awesome\#26 prepare-awesome\#27 prepare-awesome-v28
+
+.PHONY: build
+build:
+	pnpm run build
+
+# type checks the astro site and its components
+.PHONY: check
+check:
+	pnpm run check
+
+.PHONY: serve
+serve: prepare-docs
+	pnpm run dev
+
+# only the english docs of the version served at the root, plus the runner:
+# starts in a few seconds instead of loading the whole matrix
+.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 sites/docs/dist
+	rm -rf sites/docs/.cache
+	rm -rf sites/docs/node_modules/.astro
+
+# static/swagger-*.json and static/openapi3-*.json are committed files, use
+# 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

@@ -0,0 +1,127 @@
+# Gitea Docs ![badge](https://gitea.com/gitea/docs/actions/workflows/build-and-publish.yaml/badge.svg)
+
+The sources of [docs.gitea.com](https://docs.gitea.com), built with
+[Astro](https://astro.build) and [Starlight](https://starlight.astro.build).
+
+The site covers three products, all served from this repository:
+
+| Product | Content | Versions | Languages |
+| --- | --- | --- | --- |
+| Docs | `docs/`, `versioned_docs/`, `i18n/` | next, 28, 1.27 … 1.22 | English, 简体中文, 繁體中文 |
+| API | `static/swagger-*.json`, `static/openapi3-*.json` | next, 28, 1.27 … 1.22 | English |
+| Runner | `runner-docs/`, `runner-docs_versioned_docs/` | develop, 5 … 0 | English |
+
+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 install       # pnpm install
+make serve-fast    # english, the version served at the root, starts in seconds
+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
+```
+
+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
+make cut-version PRODUCT=docs VERSION=1.28
+make cut-version PRODUCT=runner VERSION=6
+```
+
+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 weekly 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-5/` | `/runner/` |
+| older series | `runner-docs_versioned_docs/version-4/` | `/runner/4/` |
+
+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 `config generate`
+(`generate-config` before 3.1):
+
+```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.

administration/environment-variables.zh-cn.md

@@ -1,57 +0,0 @@
----
-date: "2017-04-08T11:34:00+02:00"
-title: "环境变量清单"
-slug: "environment-variables"
-sidebar_position: 10
-toc: false
-draft: false
-aliases:
-  - /zh-cn/environment-variables
-menu:
-  sidebar:
-    parent: "administration"
-    name: "环境变量清单"
-    sidebar_position: 10
-    identifier: "environment-variables"
----
-
-# 环境变量清单
-
-这里是用来控制 Gitea 行为表现的的环境变量清单，您需要在执行如下 Gitea 启动命令前设置它们来确保配置生效：
-
-```
-GITEA_CUSTOM=/home/gitea/custom ./gitea web
-```
-
-## Go 的配置
-
-因为 Gitea 使用 Go 语言编写，因此它使用了一些相关的 Go 的配置参数：
-
-* `GOOS`
-* `GOARCH`
-* [`GOPATH`](https://go.dev/cmd/go/#hdr-GOPATH_environment_variable)
-
-您可以在[官方文档](https://go.dev/cmd/go/#hdr-Environment_variables)中查阅这些配置参数的详细信息。
-
-## Gitea 的文件目录
-
-* `GITEA_WORK_DIR`：工作目录的绝对路径
-* `GITEA_CUSTOM`：默认情况下 Gitea 使用默认目录 `GITEA_WORK_DIR`/custom，您可以使用这个参数来配置 *custom* 目录
-* `GOGS_WORK_DIR`： 已废弃，请使用 `GITEA_WORK_DIR` 替代
-* `GOGS_CUSTOM`： 已废弃，请使用 `GITEA_CUSTOM` 替代
-
-## 操作系统配置
-
-* `USER`：Gitea 运行时使用的系统用户，它将作为一些 repository 的访问地址的一部分
-* `USERNAME`： 如果没有配置 `USER`， Gitea 将使用 `USERNAME`
-* `HOME`： 用户的 home 目录，在 Windows 中会使用 `USERPROFILE` 环境变量
-
-### 仅限于 Windows 的配置
-
-* `USERPROFILE`： 用户的主目录，如果未配置则会使用 `HOMEDRIVE` + `HOMEPATH`
-* `HOMEDRIVE`: 用于访问 home 目录的主驱动器路径（C盘）
-* `HOMEPATH`：在指定主驱动器下的 home 目录相对路径
-
-## Miscellaneous
-
-* `SKIP_MINWINSVC`：如果设置为 1，在 Windows 上不会以 service 的形式运行。

administration/mail-templates.zh-cn.md

@@ -1,261 +0,0 @@
----
-date: "2023-05-23T09:00:00+08:00"
-title: "邮件模板"
-slug: "mail-templates"
-sidebar_position: 45
-toc: false
-draft: false
-aliases:
-  - /zh-cn/mail-templates
-menu:
-  sidebar:
-    parent: "administration"
-    name: "邮件模板"
-    sidebar_position: 45
-    identifier: "mail-templates"
----
-
-# 邮件模板
-
-为了定制特定操作的电子邮件主题和内容，可以使用模板来自定义 Gitea。这些功能的模板位于 [`custom` 目录](administration/customizing-gitea.md) 下。
-如果没有自定义的替代方案，Gitea 将使用内部模板作为默认模板。
-
-自定义模板在 Gitea 启动时加载。对它们的更改在 Gitea 重新启动之前不会被识别。
-
-## 支持模板的邮件通知
-
-目前，以下通知事件使用模板：
-
-| 操作名称   | 用途                                                                                    |
-| ----------- | ------------------------------------------------------------------------------------------------------------ |
-| `new`       | 创建了新的工单或合并请求。                                                                    |
-| `comment`   | 在现有工单或合并请求中创建了新的评论。                                                          |
-| `close`     | 关闭了工单或合并请求。                                                                         |
-| `reopen`    | 重新打开了工单或合并请求。                                                                       |
-| `review`    | 在合并请求中进行审查的首要评论。                                                               |
-| `approve`   | 对合并请求进行批准的首要评论。                                                                 |
-| `reject`    | 对合并请求提出更改请求的审查的首要评论。                                                       |
-| `code`      | 关于合并请求的代码的单个评论。                                                                 |
-| `assigned`  | 用户被分配到工单或合并请求。                                                                    |
-| `default`   | 未包括在上述类别中的任何操作，或者当对应类别的模板不存在时使用的模板。                              |
-
-特定消息类型的模板路径为：
-
-```sh
-custom/templates/mail/{操作类型}/{操作名称}.tmpl
-```
-
-其中 `{操作类型}` 是 `issue` 或 `pull`（针对合并请求），`{操作名称}` 是上述列出的操作名称之一。
-
-例如，有关合并请求中的评论的电子邮件的特定模板是：
-
-```sh
-custom/templates/mail/pull/comment.tmpl
-```
-
-然而，并不需要为每个操作类型/名称组合创建模板。
-使用回退系统来选择适当的模板。在此列表中，将使用 _第一个存在的_ 模板：
-
-- 所需**操作类型**和**操作名称**的特定模板。
-- 操作类型为 `issue` 和所需**操作名称**的模板。
-- 所需**操作类型**和操作名称为 `default` 的模板。
-- 操作类型为` issue` 和操作名称为 `default` 的模板。
-
-唯一必需的模板是操作类型为 `issue` 操作名称为 `default` 的模板，除非用户在 `custom` 目录中覆盖了它。
-
-## 模板语法
-
-邮件模板是 UTF-8 编码的文本文件，需要遵循以下格式之一：
-
-```
-用于主题行的文本和宏
-------------
-用于邮件正文的文本和宏
-```
-
-或者
-
-```
-用于邮件正文的文本和宏
-```
-
-指定 _主题_ 部分是可选的（因此也是虚线分隔符）。在使用时，_主题_ 和 _邮件正文_ 模板之间的分隔符需要至少三个虚线；分隔符行中不允许使用其他字符。
-
-_主题_ 和 _邮件正文_ 由 [Golang的模板引擎](https://go.dev/pkg/text/template/) 解析，并提供了为每个通知组装的 _元数据上下文_。上下文包含以下元素：
-
-| 名称                 | 类型               | 可用性            | 用途                                                                                                                                                                                                                                             |
-| -------------------- | ------------------ | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `.FallbackSubject`   | string             | 始终可用        | 默认主题行。参见下文。                                                                                                                                                                                                                            |
-| `.Subject`           | string             | 仅在正文中可用  | 解析后的 _主题_。                                                                                                                                                                                                                                 |
-| `.Body`              | string             | 始终可用        | 工单、合并请求或评论的消息，从 Markdown 解析为 HTML 并进行了清理。请勿与 _邮件正文_ 混淆。                                                                                                                                                                 |
-| `.Link`              | string             | 始终可用        | 源工单、合并请求或评论的地址。                                                                                                                                                                                                                    |
-| `.Issue`             | models.Issue       | 始终可用        | 产生通知的工单（或合并请求）。要获取特定于合并请求的数据（例如 `HasMerged`），可以使用 `.Issue.PullRequest`，但需要注意，如果工单 _不是_ 合并请求，则该字段将为 `nil`。                                                                       |
-| `.Comment`           | models.Comment     | 如果适用        | 如果通知是针对添加到工单或合并请求的评论，则其中包含有关评论的信息。                                                                                                                                                                             |
-| `.IsPull`            | bool               | 始终可用        | 如果邮件通知与合并请求关联（即 `.Issue.PullRequest` 不为 `nil` ），则为 `true`。                                                                                                                                                                       |
-| `.Repo`              | string         | 始终可用        | 仓库的名称，包括所有者名称（例如 `mike/stuff`）                                                                                                                                                                                                    |
-| `.User`              | models.User        | 始终可用        | 事件来源仓库的所有者。要获取用户名（例如 `mike`），可以使用 `.User.Name`。                                                                                                                                                                           |
-| `.Doer`              | models.User        | 始终可用        | 执行触发通知事件的操作的用户。要获取用户名（例如 `rhonda`），可以使用 `.Doer.Name`。                                                                                                                                                                |
-| `.IsMention`         | bool               | 始终可用        | 如果此通知仅是因为在评论中提到了用户而生成的，并且收件人未订阅源，则为 `true`。如果收件人已订阅工单或仓库，则为 `false`。                                                                                                                            |
-| `.SubjectPrefix`     | string             | 始终可用        | 如果通知是关于除工单或合并请求创建之外的其他内容，则为 `Re：`；否则为空字符串。                                                                                                                                                                      |
-| `.ActionType`        | string             | 始终可用        | `"issue"` 或 `"pull"`。它将与实际的 _操作类型_ 对应，与选择的模板无关。                                                                                                                                                                                 |
-| `.ActionName`        | string             | 始终可用        | 它将是上述操作类型之一（`new` ，`comment` 等），并与选择的模板对应。                                                                                                                                                                                 |
-| `.ReviewComments`    | []models.Comment   | 始终可用        | 审查中的代码评论列表。评论文本将在 `.RenderedContent` 中，引用的代码将在 `.Patch` 中。                                                                                                                                                                |
-
-所有名称区分大小写。
-
-### 模板中的主题部分
-
-用于邮件主题的模板引擎是 Golang 的 [`text/template`](https://go.dev/pkg/text/template/)。
-有关语法的详细信息，请参阅链接的文档。
-
-主题构建的步骤如下：
-
-- 根据通知类型和可用的模板选择一个模板。
-- 解析并解析模板（例如，将 `{{.Issue.Index}}` 转换为工单或合并请求的编号）。
-- 将所有空格字符（例如 `TAB`，`LF` 等）转换为普通空格。
-- 删除所有前导、尾随和多余的空格。
-- 将字符串截断为前 256 个字母（字符）。
-
-如果最终结果为空字符串，**或者**没有可用的主题模板（即所选模板不包含主题部分），将使用Gitea的**内部默认值**。
-
-内部默认（回退）主题相当于：
-
-```
-{{.SubjectPrefix}}[{{.Repo}}] {{.Issue.Title}} (#{{.Issue.Index}})
-```
-
-例如：`Re: [mike/stuff] New color palette (#38)`
-
-即使存在有效的主题模板，Gitea的默认主题也可以在模板的元数据中作为 `.FallbackSubject` 找到。
-
-### 模板中的邮件正文部分
-
-用于邮件正文的模板引擎是 Golang 的 [`html/template`](https://go.dev/pkg/html/template/)。
-有关语法的详细信息，请参阅链接的文档。
-
-邮件正文在邮件主题之后进行解析，因此还有一个额外的 _元数据_ 字段，即在考虑所有情况之后实际呈现的主题。
-
-期望的结果是 HTML（包括结构元素，如`<html>`，`<body>`等）。可以通过 `<style>` 块、`class` 和 `style` 属性进行样式设置。但是，`html/template` 会进行一些 [自动转义](https://go.dev/pkg/html/template/#hdr-Contexts)，需要考虑这一点。
-
-不支持附件（例如图像或外部样式表）。但是，也可以引用其他模板，例如以集中方式提供 `<style>` 元素的内容。外部模板必须放置在 `custom/mail` 下，并相对于该目录引用。例如，可以使用 `{{template styles/base}}` 包含 `custom/mail/styles/base.tmpl`。
-
-邮件以 `Content-Type: multipart/alternative` 发送，因此正文以 HTML 和文本格式发送。通过剥离 HTML 标记来获取文本版本。
-
-## 故障排除
-
-邮件的呈现方式直接取决于邮件应用程序的功能。许多邮件客户端甚至不支持 HTML，因此显示生成邮件中包含的文本版本。
-
-如果模板无法呈现，则只有在发送邮件时才会注意到。
-如果主题模板失败，将使用默认主题，如果从 _邮件正文_ 中成功呈现了任何内容，则将使用该内容，忽略其他内容。
-
-如果遇到问题，请检查 [Gitea的日志](administration/logging-config.md) 以获取错误消息。
-
-## 示例
-
-`custom/templates/mail/issue/default.tmpl`:
-
-```html
-[{{.Repo}}] @{{.Doer.Name}}
-{{if eq .ActionName "new"}}
-    创建了
-{{else if eq .ActionName "comment"}}
-    评论了
-{{else if eq .ActionName "close"}}
-    关闭了
-{{else if eq .ActionName "reopen"}}
-    重新打开了
-{{else}}
-    更新了
-{{end}}
-{{if eq .ActionType "issue"}}
-    工单
-{{else}}
-    合并请求
-{{end}}
-#{{.Issue.Index}}: {{.Issue.Title}}
-------------
-<!DOCTYPE html>
-<html>
-<head>
-    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
-    <title>{{.Subject}}</title>
-</head>
-
-<body>
-    {{if .IsMention}}
-    <p>
-        您收到此邮件是因为 @{{.Doer.Name}} 提到了您。
-    </p>
-    {{end}}
-    <p>
-        <p>
-        <a href="{{AppUrl}}/{{.Doer.LowerName}}">@{{.Doer.Name}}</a>
-        {{if not (eq .Doer.FullName "")}}
-            ({{.Doer.FullName}})
-        {{end}}
-        {{if eq .ActionName "new"}}
-            创建了
-        {{else if eq .ActionName "close"}}
-            关闭了
-        {{else if eq .ActionName "reopen"}}
-            重新打开了
-        {{else}}
-            更新了
-        {{end}}
-        <a href="{{.Link}}">{{.Repo}}#{{.Issue.Index}}</a>。
-        </p>
-        {{if not (eq .Body "")}}
-            <h3>消息内容：</h3>
-            <hr>
-            {{.Body}}
-        {{end}}
-    </p>
-    <hr>
-    <p>
-        <a href="{{.Link}}">在 Gitea 上查看</a>。
-    </p>
-</body>
-</html>
-```
-
-该模板将生成以下内容：
-
-### 主题
-
-> [mike/stuff] @rhonda 在合并请求 #38 上进行了评论：New color palette
-
-### 邮件正文
-
-> [@rhonda](#)（Rhonda Myers）更新了 [mike/stuff#38](#)。
->
-> #### 消息内容
->
-> \_********************************\_********************************
->
-> Mike, I think we should tone down the blues a little.
->
-> \_********************************\_********************************
->
-> [在 Gitea 上查看](#)。
-
-## 高级用法
-
-模板系统包含一些函数，可用于进一步处理和格式化消息。以下是其中一些函数的列表：
-
-| 函数名              | 参数        | 可用于       | 用法                             |
-|------------------| ----------- | ------------ | ------------------------------ |
-| `AppUrl`         | -           | 任何地方     | Gitea 的 URL                    |
-| `AppName`        | -           | 任何地方     | 从 `app.ini` 中设置，通常为 "Gitea"    |
-| `AppDomain`      | -           | 任何地方     | Gitea 的主机名                     |
-| `EllipsisString` | string, int | 任何地方     | 将字符串截断为指定长度；根据需要添加省略号          |
-| `SanitizeHTML`   | string      | 仅正文部分   | 通过删除其中的危险 HTML 标签对文本进行清理       |
-| `SafeHTML`       | string      | 仅正文部分   | 将输入作为 HTML 处理；可用于输出原始的 HTML 内容 |
-
-这些都是 _函数_，而不是元数据，因此必须按以下方式使用：
-
-```html
-像这样使用：         {{SanitizeHTML "Escape<my>text"}}
-或者这样使用：       {{"Escape<my>text" | SanitizeHTML}}
-或者这样使用：       {{AppUrl}}
-但不要像这样使用：   {{.AppUrl}}
-```

administration/reverse-proxies.zh-cn.md

@@ -1,136 +0,0 @@
----
-date: "2018-05-22T11:00:00+00:00"
-title: "反向代理"
-slug: "reverse-proxies"
-sidebar_position: 16
-toc: false
-draft: false
-aliases:
-  - /zh-cn/reverse-proxies
-menu:
-  sidebar:
-    parent: "administration"
-    name: "反向代理"
-    sidebar_position: 16
-    identifier: "reverse-proxies"
----
-
-# 反向代理
-
-## 使用 Nginx 作为反向代理服务
-
-如果您想使用 Nginx 作为 Gitea 的反向代理服务，您可以参照以下 `nginx.conf` 配置中 `server` 的 `http` 部分：
-
-```
-server {
-    listen 80;
-    server_name git.example.com;
-
-    location / {
-        proxy_pass http://localhost:3000;
-        proxy_set_header Host $host;
-        proxy_set_header X-Real-IP $remote_addr;
-        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-        proxy_set_header X-Forwarded-Proto $scheme;
-    }
-}
-```
-
-## 使用 Nginx 作为反向代理服务并将 Gitea 路由至一个子路径
-
-如果您已经有一个域名并且想与 Gitea 共享该域名，您可以增加以下 `nginx.conf` 配置中 `server` 的 `http` 部分，为 Gitea 添加路由规则：
-
-```
-server {
-    listen 80;
-    server_name git.example.com;
-
-    # 注意: /git/ 最后需要有一个路径符号
-    location /git/ {
-        # 注意: 反向代理后端 URL 的最后需要有一个路径符号
-        proxy_pass http://localhost:3000/;
-        proxy_set_header Host $host;
-        proxy_set_header X-Real-IP $remote_addr;
-        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-        proxy_set_header X-Forwarded-Proto $scheme;
-    }
-}
-```
-
-然后您**必须**在 Gitea 的配置文件中正确的添加类似 `[server] ROOT_URL = http://git.example.com/git/` 的配置项。
-
-## 使用 Apache HTTPD 作为反向代理服务
-
-如果您想使用 Apache HTTPD 作为 Gitea 的反向代理服务，您可以为您的 Apache HTTPD 作如下配置（在 Ubuntu 中，配置文件通常在 `/etc/apache2/httpd.conf` 目录下）：
-
-```
-<VirtualHost *:80>
-    ...
-    ProxyPreserveHost On
-    ProxyRequests off
-    AllowEncodedSlashes NoDecode
-    ProxyPass / http://localhost:3000/ nocanon
-</VirtualHost>
-```
-
-注：必须启用以下 Apache HTTPD 组件：`proxy`， `proxy_http`
-
-## 使用 Apache HTTPD 作为反向代理服务并将 Gitea 路由至一个子路径
-
-如果您已经有一个域名并且想与 Gitea 共享该域名，您可以增加以下配置为 Gitea 添加路由规则（在 Ubuntu 中，配置文件通常在 `/etc/apache2/httpd.conf` 目录下）：
-
-```
-<VirtualHost *:80>
-    ...
-    <Proxy *>
-         Order allow,deny
-         Allow from all
-    </Proxy>
-    AllowEncodedSlashes NoDecode
-    # 注意: 路径和 URL 后面都不要写路径符号 '/'
-    ProxyPass /git http://localhost:3000 nocanon
-</VirtualHost>
-```
-
-然后您**必须**在 Gitea 的配置文件中正确的添加类似 `[server] ROOT_URL = http://git.example.com/git/` 的配置项。
-
-注：必须启用以下 Apache HTTPD 组件：`proxy`， `proxy_http`
-
-## 使用 Caddy 作为反向代理服务
-
-如果您想使用 Caddy 作为 Gitea 的反向代理服务，您可以在 `Caddyfile` 中添加如下配置：
-
-```
-git.example.com {
-    proxy / http://localhost:3000
-}
-```
-
-## 使用 Caddy 作为反向代理服务并将 Gitea 路由至一个子路径
-
-如果您已经有一个域名并且想与 Gitea 共享该域名，您可以在您的 `Caddyfile` 文件中增加以下配置，为 Gitea 添加路由规则：
-
-```
-git.example.com {
-    # 注意: 路径 /git/ 最后需要有路径符号
-    proxy /git/ http://localhost:3000
-}
-```
-
-然后您**必须**在 Gitea 的配置文件中正确的添加类似 `[server] ROOT_URL = http://git.example.com/git/` 的配置项。
-
-## 使用 Traefik 作为反向代理服务
-
-如果您想使用 traefik 作为 Gitea 的反向代理服务，您可以在 `docker-compose.yaml` 中添加 label 部分（假设使用 docker 作为 traefik 的 provider）：
-
-```yaml
-gitea:
-  image: gitea/gitea
-  ...
-  labels:
-    - "traefik.enable=true"
-    - "traefik.http.routers.gitea.rule=Host(`example.com`)"
-    - "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000"
-```
-
-这份配置假设您使用 traefik 来处理 HTTPS 服务，并在其和 Gitea 之间使用 HTTP 进行通信。

check_outdated.sh

@@ -0,0 +1,37 @@
+#!/bin/bash
+
+# This script takes `locale` as a param and checks if a specific locale version of document is up to date with English version
+# If latest commit timestamp of English version is greater than the specific locale version,
+# The specific locale version document will be marked as outdated
+
+set -xe
+
+SED_INPLACE() {
+  if sed --version 2>/dev/null | grep -q GNU; then
+    sed -i "$@"
+  else
+    sed -i '' "$@"
+  fi
+}
+
+locale="$1"
+cur_path=`pwd`
+cd .tmp/upstream-docs
+
+for file in `find ./docs/content -name "*.${locale}.md"`; do
+    file_en="${file/.${locale}/.en-us}"
+    if [ ! -f "$file_en" ]; then
+        continue
+    fi
+    latest_commit_time_en=$(git log -1 --format=%ct "$file_en")
+    latest_commit_time_locale=$(git log -1 --format=%ct "$file")
+    if [ -z "$latest_commit_time_locale" ]; then
+        continue
+    fi
+    if [[ "$latest_commit_time_en" -gt "$latest_commit_time_locale" ]]; then
+        echo "file: $file, lastest commit timestamp: $latest_commit_time_en (en ver), $latest_commit_time_locale ($locale ver)"
+        SED_INPLACE '1s/---/---\nisOutdated: true/' $file
+    fi
+done
+
+cd "$cur_path"

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.
+#
+# The build 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, so they have no localized copy.
+/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/28/* /api/:splat 301
+/runner/3/* /runner/:splat 301
+/28/* /: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": []
+}

contributing/guidelines-refactoring.zh-cn.md

@@ -1,49 +0,0 @@
----
-date: "2023-05-25T00:00:00+00:00"
-title: "重构指南"
-slug: "guidelines-refactoring"
-sidebar_position: 20
-toc: false
-draft: false
-aliases:
-  - /zh-cn/guidelines-refactoring
-menu:
-  sidebar:
-    parent: "contributing"
-    name: "重构指南"
-    sidebar_position: 20
-    identifier: "guidelines-refactoring"
----
-
-# 重构指南
-
-## 背景
-
-自2014年2月12日编写了第一行代码以来，Gitea已经发展成为一个庞大的项目。
-因此，代码库变得越来越大。代码库越大，维护就越困难。
-存在许多过时的机制，许多框架混合在一起，一些遗留代码可能会导致错误并阻碍新功能的开发。
-为了使代码库更易于维护，使Gitea变得更好，开发人员应牢记使用现代机制来重构旧代码。
-
-本文档是关于重构代码库的指南集合。
-
-## 重构建议
-
-* 设计更多关于未来的内容，而不仅仅解决当前问题。
-* 减少模糊性，减少冲突，提高可维护性。
-* 描述重构，例如：
-  * 为什么需要重构。
-  * 如何解决旧问题。
-  * 重构的优点/缺点是什么。
-* 只做必要的更改，尽量保留旧逻辑。
-* 引入一些中间步骤，使重构更容易审查，完整的重构计划可以在几个PR中完成。
-* 如果存在分歧，应该请TOC（技术监督委员会）参与决策。
-* 添加必要的测试以确保重构的正确性。
-* 非错误重构优先在里程碑的开始时进行，这样可以更容易地在发布之前发现问题。
-
-## 审查和合并建议
-
-* 重构的PR不应该长时间保持打开状态（通常为7天），应尽快进行审查。
-* 重构的PR应尽快合并，不应被其他PR阻塞。
-* 如果TOC没有异议，重构的PR可以在7天后由一名核心成员（非作者）批准后合并。
-* 如果最终结果良好，容忍一些不完美/临时的步骤。
-* 如果重构是必要的，容忍一些回归错误，并尽快修复错误。

contributing/localization.de-de.md

@@ -1,64 +0,0 @@
----
-date: "2021-01-22T00:00:00+02:00"
-title: "Übersetzungs Richtlinien"
-slug: "localization"
-sidebar_position: 70
-toc: false
-draft: false
-menu:
-  sidebar:
-    parent: "contributing"
-    name: "Übersetzungsrichtlinien"
-    sidebar_position: 70
-    identifier: "localization"
----
-
-## Allgemeines
-
-Anrede: Wenig förmlich:
-
-* "Du"-Form
-* Keine "Amtsdeusch"-Umschreibungen, einfach so als ob man den Nutzer direkt persönlich ansprechen würde
-
-Genauer definiert:
-
-* "falsch" anstatt "nicht korrekt/inkorrekt"
-* Benutzerkonto oder Konto? Oder Account?
-* "Wende dich an ..." anstatt "kontaktiere ..."
-* In der selben Zeit übersetzen (sonst wird aus "is" "war")
-* Richtige Anführungszeichen verwenden. Also `"` statt `''` oder `'` oder \` oder `´`
-  * `„` für beginnende Anführungszeichen, `“` für schließende Anführungszeichen
-
-Es gelten Artikel und Worttrennungen aus dem Duden.
-
-## Formulierungen in Modals und Buttons
-
-Es sollten die gleichen Formulierungen auf Buttons und Modals verwendet werden.
-
-Beispiel: Wenn der Button mit `löschen` beschriftet ist, sollte im Modal die Frage lauten `Willst du das wirklich löschen?` und nicht `Willst du das wirklich entfernen?`. Gleiches gilt für Success/Errormeldungen nach der Aktion.
-
-## Trennungen
-
-* Pull-Request
-* Time-Tracker
-* E-Mail-Adresse (siehe Duden)
-
-## Artikeldefinitionen für Anglizismen
-
-* _Der_ Commit (m.)
-* _Der_ Branch (m.), plural: die Branches
-* _Das_ Issue (n.)
-* _Der_ Fork (m.)
-* _Das_ Repository (n.), plural: die Repositories
-* _Der_ Pull-Request (m.)
-* _Der_ Token (m.), plural: die Token
-* _Das_ Review (n.)
-* _Der_ Key (m.)
-* _Der_ Committer (m.), plural: die Committer
-
-## Weiterführende Links
-
-Diese beiden Links sind sehr empfehlenswert:
-
-* http://docs.translatehouse.org/projects/localization-guide/en/latest/guide/translation_guidelines_german.html
-* https://docs.qgis.org/2.18/en/docs/documentation_guidelines/do_translations.html

contributing/translation.zh-cn.md

@@ -1,17 +0,0 @@
----
-date: "2023-05-25T00:00:00+02:00"
-title: "翻译指南"
-sidebar_position: 70
-toc: true
-draft: false
-menu:
-  sidebar:
-    parent: "contributing"
-    name: "翻译指南"
-    sidebar_position: 70
-    identifier: "translation-guidelines"
----
-
-本页面用于提供一套通用规则，以确保翻译的一致性。
-
-* [German](/de-de/übersetzungs-richtlinien/)

development/migrations.zh-cn.md

@@ -1,40 +0,0 @@
----
-date: "2023-05-25T17:29:00+08:00"
-title: "迁移界面"
-slug: "migrations-interfaces"
-sidebar_position: 55
-toc: false
-draft: false
-aliases:
-  - /zh-cn/migrations-interfaces
-menu:
-  sidebar:
-    parent: "development"
-    name: "迁移界面"
-    sidebar_position: 55
-    identifier: "migrations-interfaces"
----
-
-# 迁移功能
-
-完整迁移功能在Gitea 1.9.0版本中引入。它定义了两个接口，用于支持从其他Git托管平台迁移存储库数据到Gitea，或者在将来将Gitea数据迁移到其他Git托管平台。
-
-目前已实现了从GitHub、GitLab和其他Gitea实例的迁移。
-
-首先，Gitea在包[modules/migration](https://github.com/go-gitea/gitea/tree/main/modules/migration)中定义了一些标准对象。它们是`Repository`、`Milestone`、`Release`、`ReleaseAsset`、`Label`、`Issue`、`Comment`、`PullRequest`、`Reaction`、`Review`、`ReviewComment`。
-
-## 下载器接口
-
-要从新的Git托管平台迁移，需要进行两个步骤的更新。
-
-- 您应该实现一个`Downloader`，用于获取存储库信息。
-- 您应该实现一个`DownloaderFactory`，用于检测URL是否匹配，并创建上述的`Downloader`。
-  - 您需要在`init()`中通过`RegisterDownloaderFactory`注册`DownloaderFactory`。
-
-您可以在[downloader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/downloader.go)中找到这些接口。
-
-## 上传器接口
-
-目前，只实现了`GiteaLocalUploader`，因此我们只能通过此Uploader将下载的数据保存到本地的Gitea实例。目前不支持其他上传器。
-
-您可以在[uploader.go](https://github.com/go-gitea/gitea/blob/main/modules/migration/uploader.go)中找到这些接口。

development/oauth2-provider.zh-cn.md

@@ -1,137 +0,0 @@
----
-date: "2019-04-19:44:00+01:00"
-title: "OAuth2 提供者"
-slug: "oauth2-provider"
-sidebar_position: 41
-toc: false
-draft: false
-aliases:
-  - /zh-cn/oauth2-provider
-menu:
-  sidebar:
-    parent: "development"
-    name: "OAuth2 提供者"
-    sidebar_position: 41
-    identifier: "oauth2-provider"
----
-
-# OAuth2 提供者
-
-Gitea 支持作为 OAuth2 提供者，允许第三方应用程序在用户同意的情况下访问其资源。此功能自 1.8.0 版起可用。
-
-## 端点
-
-| 端点                     | URL                                 |
-| ------------------------ | ----------------------------------- |
-| OpenID Connect Discovery | `/.well-known/openid-configuration` |
-| Authorization Endpoint   | `/login/oauth/authorize`            |
-| Access Token Endpoint    | `/login/oauth/access_token`         |
-| OpenID Connect UserInfo  | `/login/oauth/userinfo`             |
-| JSON Web Key Set         | `/login/oauth/keys`                 |
-
-## 支持的 OAuth2 授权
-
-目前 Gitea 仅支持 [**Authorization Code Grant**](https://tools.ietf.org/html/rfc6749#section-1.3.1) 标准，并额外支持以下扩展：
-
-- [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636)
-- [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth)
-
-要将 Authorization Code Grant 作为第三方应用程序，您需要通过在设置中添加一个新的 "应用程序" (`/user/settings/applications`)。
-
-## 范围
-
-Gitea 支持以下令牌范围:
-
-| 名称 | 介绍 |
-| ---- | ----------- |
-| **(no scope)** | 授予对公共用户配置文件和公共存储库的只读访问权限 |
-| **repo** | 完全控制所有存储库 |
-|     **repo:status** | 授予对所有存储库中提交状态的读/写访问权限 |
-|     **public_repo** | 仅授予对公共存储库的读/写访问权限 |
-| **admin:repo_hook** | 授予对所有存储库的 Hooks 访问权限，该权限已包含在 `repo` 范围中 |
-|     **write:repo_hook** | 授予对存储库 Hooks 的读/写访问权限 |
-|     **read:repo_hook** | 授予对存储库 Hooks 的只读访问权限 |
-| **admin:org** | 授予对组织设置的完全访问权限 |
-|     **write:org** | 授予对组织设置的读/写访问权限 |
-|     **read:org** | 授予对组织设置的只读访问权限 |
-| **admin:public_key** | 授予公钥管理的完全访问权限 |
-|     **write:public_key** | 授予对公钥的读/写访问权限 |
-|     **read:public_key** | 授予对公钥的只读访问权限 |
-| **admin:org_hook** | 授予对组织级别 Hooks 的完全访问权限 |
-| **admin:user_hook** | 授予对用户级别 Hooks 的完全访问权限 |
-| **notification** | 授予对通知的完全访问权限 |
-| **user** | 授予对用户个人资料信息的完全访问权限 |
-|     **read:user** | 授予对用户个人资料的读取权限 |
-|     **user:email** | 授予对用户电子邮件地址的读取权限 |
-|     **user:follow** | 授予访问权限以关注/取消关注用户 |
-| **delete_repo** | 授予删除存储库的权限 |
-| **package** | 授予对托管包的完全访问权限 |
-|     **write:package** | 授予对包的读/写访问权限 |
-|     **read:package** | 授予对包的读取权限 |
-|     **delete:package** | 授予对包的删除权限 |
-| **admin:gpg_key** | 授予 GPG 密钥管理的完全访问权限 |
-|     **write:gpg_key** | 授予对 GPG 密钥的读/写访问权限 |
-|     **read:gpg_key** | 授予对 GPG 密钥的只读访问权限 |
-| **admin:application** | 授予应用程序管理的完全访问权限 |
-|     **write:application** | 授予应用程序管理的读/写访问权限 |
-|     **read:application** | 授予应用程序管理的读取权限 |
-| **sudo** | 允许以站点管理员身份执行操作 |
-
-## 客户端类型
-
-Gitea 支持私密和公共客户端类型，[参见 RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1).
-
-对于公共客户端, 允许在本地回环地址的重定向 URI 中使用任意端口，例如 `http://127.0.0.1/`。根据 [RFC 8252 的建议](https://datatracker.ietf.org/doc/html/rfc8252#section-8.3)，请避免使用 `localhost`。
-
-## 示例
-
-**注意：** 该示例中尚未使用 PKCE。
-
-1. 将用户重定向到授权端点，以获得他们的访问资源授权:
-
-   ```curl
-   https://[YOUR-GITEA-URL]/login/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI& response_type=code&state=STATE
-   ```
-
-   在设置中注册应用程序以获得 `CLIENT_ID`。`STATE` 是一个随机字符串，它将在获得用户授权后发送回您的应用程序。`state` 参数是可选的，但您应该使用它来防止 CSRF 攻击。
-
-   ![Authorization Page](/authorize.png)
-
-   用户将会被询问是否授权给您的应用程序。如果他们同意了授权，用户将会被重定向到 `REDIRECT_URL`，例如：
-
-   ```curl
-   https://[REDIRECT_URI]?code=RETURNED_CODE&state=STATE
-   ```
-
-2. 使用重定向提供的 `code`，您可以请求一个新的应用程序和 Refresh Token。Access Token Endpoint 接受 `application/json` 或 `application/x-www-form-urlencoded` 类型的 POST 请求，例如：
-
-   ```curl
-   POST https://[YOUR-GITEA-URL]/login/oauth/access_token
-   ```
-
-   ```json
-   {
-     "client_id": "YOUR_CLIENT_ID",
-     "client_secret": "YOUR_CLIENT_SECRET",
-     "code": "RETURNED_CODE",
-     "grant_type": "authorization_code",
-     "redirect_uri": "REDIRECT_URI"
-   }
-   ```
-
-   返回：
-
-   ```json
-   {
-     "access_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjowLCJleHAiOjE1NTUxNzk5MTIsImlhdCI6MTU1NTE3NjMxMn0.0-iFsAwBtxuckA0sNZ6QpBQmywVPz129u75vOM7wPJecw5wqGyBkmstfJHAjEOqrAf_V5Z-1QYeCh_Cz4RiKug",
-     "token_type": "bearer",
-     "expires_in": 3600,
-     "refresh_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjoxLCJjbnQiOjEsImV4cCI6MTU1NzgwNDMxMiwiaWF0IjoxNTU1MTc2MzEyfQ.S_HZQBy4q9r5SEzNGNIoFClT43HPNDbUdHH-GYNYYdkRfft6XptJBkUQscZsGxOW975Yk6RbgtGvq1nkEcklOw"
-   }
-   ```
-
-   `CLIENT_SECRET` 是生成给应用程序的唯一密钥。请注意，该密钥只会在您使用 Gitea 创建/注册应用程序后出现一次。如果您丢失了密钥，您必须在应用程序设置中重新生成密钥。
-
-   `access_token` 请求中的 `REDIRECT_URI` 必须与 `authorize` 请求中的 `REDIRECT_URI` 相符。
-
-3. 使用 `access_token` 来构造 [API 请求](development/api-usage.md#oauth2-provider) 以读写用户的资源。

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

@@ -0,0 +1,33 @@
+---
+date: "2019-12-28"
+slug: adding-legal-pages
+sidebar_position: 110
+aliases:
+  - /en-us/adding-legal-pages
+---
+
+# Adding Legal Pages
+
+Some jurisdictions (such as EU), requires certain legal pages (e.g. Privacy Policy) to be added to website. Follow these steps to add them to your Gitea instance.
+
+## Getting Pages
+
+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/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.
+
+You absolutely must not place a general ToS or privacy statement that implies that the Gitea project is responsible for your server.
+
+## Make it Visible
+
+Create or append to `/path/to/custom/templates/custom/extra_links_footer.tmpl`:
+
+```go
+<a class="item" href="{{AppSubUrl}}/assets/privacy.html">Privacy Policy</a>
+```
+
+Restart Gitea to see the changes.

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
+- `gitea: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

@@ -0,0 +1,438 @@
+---
+date: "2016-12-01T16:00:00+02:00"
+slug: "authentication"
+sidebar_position: 10
+aliases:
+  - /en-us/authentication
+---
+
+# Authentication
+
+## LDAP (Lightweight Directory Access Protocol)
+
+Both the LDAP via BindDN and the simple auth LDAP share the following fields:
+
+- Authorization Name **(required)**
+
+  - A name to assign to the new method of authorization.
+
+- Host **(required)**
+
+  - The address where the LDAP server can be reached.
+  - Example: `mydomain.com`
+
+- Port **(required)**
+
+  - The port to use when connecting to the server.
+  - Example: `389` for LDAP or `636` for LDAP SSL
+
+- Enable TLS Encryption (optional)
+
+  - Whether to use TLS when connecting to the LDAP server.
+
+- Admin Filter (optional)
+
+  - An LDAP filter specifying if a user should be given administrator
+    privileges. If a user account passes the filter, the user will be
+    privileged as an administrator.
+  - Example: `(objectClass=adminAccount)`
+  - Example for Microsoft Active Directory (AD): `(memberOf=CN=admin-group,OU=example,DC=example,DC=org)`
+
+- Username attribute (optional)
+
+  - The attribute of the user's LDAP record containing the user name. Given
+    attribute value will be used for new Gitea account user name after first
+    successful sign-in. Leave empty to use login name given on sign-in form.
+  - This is useful when supplied login name is matched against multiple
+    attributes, but only single specific attribute should be used for Gitea
+    account name, see "User Filter".
+  - Example: `uid`
+  - Example for Microsoft Active Directory (AD): `sAMAccountName`
+
+- First name attribute (optional)
+
+  - The attribute of the user's LDAP record containing the user's first name.
+    This will be used to populate their account information.
+  - Example: `givenName`
+
+- Surname attribute (optional)
+
+  - The attribute of the user's LDAP record containing the user's surname.
+    This will be used to populate their account information.
+  - Example: `sn`
+
+- E-mail attribute **(required)**
+  - The attribute of the user's LDAP record containing the user's email
+    address. This will be used to populate their account information.
+  - Example: `mail`
+
+### LDAP via BindDN
+
+Adds the following fields:
+
+- Bind DN (optional)
+
+  - The DN to bind to the LDAP server with when searching for the user. This
+    may be left blank to perform an anonymous search.
+  - Example: `cn=Search,dc=mydomain,dc=com`
+
+- Bind Password (optional)
+
+  - The password for the Bind DN specified above, if any. _Note: The password
+    is stored encrypted with the SECRET_KEY on the server. It is still recommended
+    to ensure that the Bind DN has as few privileges as possible._
+
+- User Search Base **(required)**
+
+  - The LDAP base at which user accounts will be searched for.
+  - Example: `ou=Users,dc=mydomain,dc=com`
+
+- User Filter **(required)**
+  - An LDAP filter declaring how to find the user record that is attempting to
+    authenticate. The `%[1]s` matching parameter will be substituted with login
+    name given on sign-in form.
+  - Example: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))`
+  - Example for Microsoft Active Directory (AD): `(&(objectCategory=Person)(memberOf=CN=user-group,OU=example,DC=example,DC=org)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))`
+  - To substitute more than once, `%[1]s` should be used instead, e.g. when
+    matching supplied login name against multiple attributes such as user
+    identifier, email or even phone number.
+  - Example: `(&(objectClass=Person)(|(uid=%[1]s)(mail=%[1]s)(mobile=%[1]s)))`
+- Enable user synchronization
+  - This option enables a periodic task that synchronizes the Gitea users with
+    the LDAP server. The default period is every 24 hours but that can be
+    changed in the app.ini file. See the _cron.sync_external_users_ section in
+    the [sample
+    app.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
+    for detailed comments about that section. The _User Search Base_ and _User
+    Filter_ settings described above will limit which users can use Gitea and
+    which users will be synchronized. When initially run the task will create
+    all LDAP users that match the given settings so take care if working with
+    large Enterprise LDAP directories.
+
+### LDAP using simple auth
+
+Adds the following fields:
+
+- User DN **(required)**
+
+  - A template to use as the user's DN. The `%s` matching parameter will be
+    substituted with login name given on sign-in form.
+  - Example: `cn=%s,ou=Users,dc=mydomain,dc=com`
+  - Example: `uid=%s,ou=Users,dc=mydomain,dc=com`
+
+- User Search Base (optional)
+
+  - The LDAP base at which user accounts will be searched for.
+  - Example: `ou=Users,dc=mydomain,dc=com`
+
+- User Filter **(required)**
+  - An LDAP filter declaring when a user should be allowed to log in. The `%[1]s`
+    matching parameter will be substituted with login name given on sign-in
+    form.
+  - Example: `(&(objectClass=posixAccount)(|(cn=%[1]s)(mail=%[1]s)))`
+  - Example: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))`
+
+### Verify group membership in LDAP
+
+Uses the following fields:
+
+- Group Search Base DN (optional)
+
+  - The LDAP DN used for groups.
+  - Example: `ou=group,dc=mydomain,dc=com`
+
+- Group Attribute Containing List Of Users (optional)
+  - The attribute of the group object that lists/contains the group members.
+  - Example: `memberUid` or `member`
+
+- User Attribute Listed in Group (optional)
+
+  - The user attribute that is used to reference a user in the group object.
+  - Example: `uid` if the group objects contains a `member: bender` and the user object contains a `uid: bender`.
+  - Example: `dn` if the group object contains a `member: uid=bender,ou=users,dc=planetexpress,dc=com`.
+
+- Verify group membership in LDAP (optional)
+
+  - An LDAP filter declaring how to find valid groups in the above DN.
+  - Example: `(|(cn=gitea_users)(cn=admins))`
+
+## PAM (Pluggable Authentication Module)
+
+This procedure enables PAM authentication.  Users may still be added to the
+system manually using the user administration.  PAM provides a mechanism to
+automatically add users to the current database by testing them against PAM
+authentication.  To work with normal Linux passwords, the user running Gitea
+must also have read access to `/etc/shadow` in order to check the validity of
+the account when logging in using a public key.
+
+**Note**: If a user has added SSH public keys into Gitea, the use of these
+keys _may_ bypass the login check system.  Therefore, if you wish to disable a user who
+authenticates with PAM, you _should_ also manually disable the account in Gitea using the
+built-in user manager.
+
+1. Configure and prepare the installation.
+    - It is recommended that you create an administrative user.
+    - Deselecting automatic sign-up may also be desired.
+1. Once the database has been initialized, log in as the newly created
+administrative user.
+1. Navigate to the user setting (icon in top-right corner), and select
+`Site Administration` -> `Authentication Sources`, and select
+`Add Authentication Source`.
+1. Fill out the field as follows:
+    - `Authentication Type` : `PAM`
+    - `Name` : Any value should be valid here, use "System Authentication" if
+    you'd like.
+    - `PAM Service Name` : Select the appropriate file listed under `/etc/pam.d/`
+    that performs the authentication desired.[^1]
+    - `PAM Email Domain` : The e-mail suffix to append to user authentication.
+    For example, if the login system expects a user called `gituser`, and this
+    field is set to `mail.com`, then Gitea will expect the `user email` field
+    for an authenticated GIT instance to be `[email protected]`.[^2]
+
+**Note**: PAM support is added via [build-time flags](installation/from-source.md#build),
+and the official binaries provided do not have this enabled.  PAM requires that
+the necessary libpam dynamic library be available and the necessary PAM
+development headers be accessible to the compiler.
+
+[^1]: For example, using standard Linux log-in on Debian "Bullseye" use
+`common-session-noninteractive` - this value may be valid for other flavors of
+Debian including Ubuntu and Mint, consult your distribution's documentation.
+[^2]: **This is a required field for PAM**.  Be aware: In the above example, the
+user will log into the Gitea web interface as `gituser` and not `[email protected]`
+
+## SMTP (Simple Mail Transfer Protocol)
+
+This option allows Gitea to log in to an SMTP host as a Gitea user. To
+configure this, set the fields below:
+
+- Authentication Name **(required)**
+
+  - A name to assign to the new method of authorization.
+
+- SMTP Authentication Type **(required)**
+
+  - Type of authentication to use to connect to SMTP host, PLAIN or LOGIN.
+
+- Host **(required)**
+
+  - The address where the SMTP host can be reached.
+  - Example: `smtp.mydomain.com`
+
+- Port **(required)**
+
+  - The port to use when connecting to the server.
+  - Example: `587`
+
+- Allowed Domains
+
+  - Restrict what domains can log in if using a public SMTP host or SMTP host
+    with multiple domains.
+  - Example: `gitea.com,mydomain.com,mydomain2.com`
+
+- Force SMTPS
+
+  - SMTPS will be used by default for connections to port 465, if you wish to use SMTPS
+  for other ports. Set this value.
+  - Otherwise if the server provides the `STARTTLS` extension this will be used.
+
+- Skip TLS Verify
+
+  - Disable TLS verify on authentication.
+
+- This Authentication Source is Activated
+  - Enable or disable this authentication source.
+
+## FreeIPA
+
+- In order to log in to Gitea using FreeIPA credentials, a bind account needs to
+  be created for Gitea:
+
+- On the FreeIPA server, create a `gitea.ldif` file, replacing `dc=example,dc=com`
+  with your DN, and provide an appropriately secure password:
+
+  ```sh
+  dn: uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com
+  changetype: add
+  objectclass: account
+  objectclass: simplesecurityobject
+  uid: gitea
+  userPassword: secure password
+  passwordExpirationTime: 20380119031407Z
+  nsIdleTimeout: 0
+  ```
+
+- Import the LDIF (change localhost to an IPA server if needed). A prompt for
+  Directory Manager password will be presented:
+
+  ```sh
+  ldapmodify -h localhost -p 389 -x -D \
+  "cn=Directory Manager" -W -f gitea.ldif
+  ```
+
+- Add an IPA group for gitea_users :
+
+  ```sh
+  ipa group-add --desc="Gitea Users" gitea_users
+  ```
+
+- Note: For errors about IPA credentials, run `kinit admin` and provide the
+  domain admin account password.
+
+- Log in to Gitea as an Administrator and click on "Authentication" under Admin Panel.
+  Then click `Add New Source` and fill in the details, changing all where appropriate.
+
+## SPNEGO with SSPI (Kerberos/NTLM, for Windows only)
+
+Gitea supports SPNEGO single sign-on authentication (the scheme defined by RFC4559) for the web part of the server via the Security Support Provider Interface (SSPI) built in Windows. SSPI works only in Windows environments - when both the server and the clients are running Windows.
+
+Before activating SSPI single sign-on authentication (SSO) you have to prepare your environment:
+
+- Create a separate user account in active directory, under which the `gitea.exe` process will be running (eg. `user` under domain `domain.local`):
+
+- Create a service principal name for the host where `gitea.exe` is running with class `HTTP`:
+
+  - Start `Command Prompt` or `PowerShell` as a privileged domain user (eg. Domain Administrator)
+  - Run the command below, replacing `host.domain.local` with the fully qualified domain name (FQDN) of the server where the web application will be running, and `domain\user` with the name of the account created in the previous step:
+
+  ```sh
+  setspn -A HTTP/host.domain.local domain\user
+  ```
+
+- Sign in (_sign out if you were already signed in_) with the user created
+
+- Make sure that `ROOT_URL` in the `[server]` section of `custom/conf/app.ini` is the fully qualified domain name of the server where the web application will be running - the same you used when creating the service principal name (eg. `host.domain.local`)
+
+- Start the web server (`gitea.exe web`)
+
+- Enable SSPI authentication by adding an `SPNEGO with SSPI` authentication source in `Site Administration -> Authentication Sources`
+
+- Sign in to a client computer in the same domain with any domain user (client computer, different from the server running `gitea.exe`)
+
+- If you are using Chrome or Edge, add the URL of the web app to the Local intranet sites (`Internet Options -> Security -> Local intranet -> Sites`)
+
+- Start Chrome or Edge and navigate to the FQDN URL of Gitea (eg. `http://host.domain.local:3000`)
+
+- Click the `Sign In` button on the dashboard and choose SSPI to be automatically logged in with the same user that is currently logged on to the computer
+
+- If it does not work, make sure that:
+  - You are not running the web browser on the same server where Gitea is running. You should be running the web browser on a domain joined computer (client) that is different from the server. If both the client and server are running on the same computer NTLM will be preferred over Kerberos.
+  - There is only one `HTTP/...` SPN for the host
+  - The SPN contains only the hostname, without the port
+  - You have added the URL of the web app to the `Local intranet zone`
+  - The clocks of the server and client should not differ with more than 5 minutes (depends on group policy)
+  - `Integrated Windows Authentication` should be enabled in Internet Explorer (under `Advanced settings`)
+
+## Reverse Proxy
+
+Gitea supports Reverse Proxy Header authentication, it will read headers as a trusted login user name or user email address. This hasn't been enabled by default, you can enable it with
+
+```ini
+[service]
+ENABLE_REVERSE_PROXY_AUTHENTICATION = true
+```
+
+The default login user name is in the `X-WEBAUTH-USER` header, you can change it via changing `REVERSE_PROXY_AUTHENTICATION_USER` in app.ini. If the user doesn't exist, you can enable automatic registration with `ENABLE_REVERSE_PROXY_AUTO_REGISTRATION=true`.
+
+The default login user email is `X-WEBAUTH-EMAIL`, you can change it via changing `REVERSE_PROXY_AUTHENTICATION_EMAIL` in app.ini, this could also be disabled with `ENABLE_REVERSE_PROXY_EMAIL`
+
+If set `ENABLE_REVERSE_PROXY_FULL_NAME=true`, a user full name expected in `X-WEBAUTH-FULLNAME` will be assigned to the user when auto creating the user. You can also change the header name with `REVERSE_PROXY_AUTHENTICATION_FULL_NAME`.
+
+It applies to the web interface, Git over HTTP, Git LFS and the package registry.
+
+:::warning
+Gitea trusts these headers on every request it receives. Make sure Gitea is only reachable through your authenticating proxy, and that the proxy sets or removes these headers on every request, including on paths you exempt from authentication, for example for Git or package clients. `REVERSE_PROXY_TRUSTED_PROXIES` does not restrict them.
+:::
+
+To also accept them on the REST API under `/api/v1`, enable:
+
+```ini
+[service]
+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

@@ -0,0 +1,176 @@
+---
+date: "2017-01-01T16:00:00+02:00"
+slug: "backup-and-restore"
+sidebar_position: 11
+aliases:
+  - /en-us/backup-and-restore
+---
+
+# Backup and Restore
+
+Gitea currently has a `dump` command that will save the installation to a ZIP file. This
+file can be unpacked and used to restore an instance.
+
+## Backup Consistency
+
+To ensure the consistency of the Gitea instance, it must be shutdown during backup.
+
+Gitea consists of a database, files and git repositories, all of which change when it is used. For instance, when a migration is in progress, a transaction is created in the database while the git repository is being copied over. If the backup happens in the middle of the migration, the git repository may be incomplete although the database claims otherwise because it was dumped afterwards. The only way to avoid such race conditions is by stopping the Gitea instance during the backups.
+
+## Backup Command (`dump`)
+
+Switch to the user running Gitea: `su git`. Run `./gitea dump -c /path/to/app.ini` in the Gitea installation
+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/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
+2016/12/27 22:32:34 Finish dumping in file gitea-dump-1482906742.zip
+```
+
+Inside the `gitea-dump-1482906742.zip` file, will be the following:
+
+- `app.ini` - Optional copy of configuration file if originally stored outside the default `custom/` directory
+- `custom/` - All config or customization files in `custom/`.
+- `data/` - Data directory (APP_DATA_PATH), except sessions if you are using file session. This directory includes `attachments`, `avatars`, `lfs`, `indexers`, SQLite file if you are using SQLite.
+- `repos/` - Complete copy of the repository directory.
+- `gitea-db.sql` - SQL dump of database
+- `log/` - Various logs. They are not needed for a recovery or migration.
+
+Intermediate backup files are created in a temporary directory specified either with the
+`--tempdir` command-line parameter or the `TMPDIR` environment variable.
+
+## Backup the database
+
+The SQL dump created by `gitea dump` uses XORM and Gitea admins may prefer to use the native the MySQL and PostgreSQL dump tools instead. There are still open issues when using XORM for dumping the database that may cause problems when attempting to restore it.
+
+```sh
+# mysql
+mysqldump -u$USER -p$PASS --database $DATABASE > gitea-db.sql
+# postgres
+pg_dump -U $USER $DATABASE > gitea-db.sql
+```
+
+### Using Docker (`dump`)
+
+There are a few caveats for using the `dump` command with Docker.
+
+The command has to be executed with the `RUN_USER = <OS_USERNAME>` specified in `gitea/conf/app.ini`; and, for the zipping of the backup folder to occur without permission error the command `docker exec` must be executed inside of the `--tempdir`.
+
+Example:
+
+```bash
+docker exec -u <OS_USERNAME> -it -w <--tempdir> $(docker ps -qf 'name=^<NAME_OF_DOCKER_CONTAINER>$') bash -c '/usr/local/bin/gitea dump -c </path/to/app.ini>'
+```
+
+\*Note: `--tempdir` refers to the temporary directory of the docker environment used by Gitea; if you have not specified a custom `--tempdir`, then Gitea uses `/tmp` or the `TMPDIR` environment variable of the docker container. For `--tempdir` adjust your `docker exec` command options accordingly.
+
+The result should be a file, stored in the `--tempdir` specified, along the lines of: `gitea-dump-1482906742.zip`
+
+## Restore Command (`restore`)
+
+There is currently no support for a recovery command. It is a manual process that mostly
+involves moving files to their correct locations and restoring a database dump.
+
+Example:
+
+```sh
+unzip gitea-dump-1610949662.zip
+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/
+chown -R gitea:gitea /etc/gitea/conf/app.ini /var/lib/gitea
+
+# mysql
+mysql --default-character-set=utf8mb4 -u$USER -p$PASS $DATABASE <gitea-db.sql
+# sqlite3
+sqlite3 $DATABASE_PATH <gitea-db.sql
+# postgres
+psql -U $USER -d $DATABASE < gitea-db.sql
+
+service gitea restart
+```
+
+Repository Git Hooks should be regenerated if installation method is changed (eg. binary -> Docker), or if Gitea is installed to a different directory than the previous installation.
+
+With Gitea running, and from the directory Gitea's binary is located, execute: `./gitea admin regenerate hooks`
+
+This ensures that application and configuration file paths in repository Git Hooks are consistent and applicable to the current installation. If these paths are not updated, repository `push` actions will fail.
+
+If you still have issues, consider running `./gitea doctor check` to inspect possible errors (or run with `--fix`).
+
+### Using Docker (`restore`)
+
+There is also no support for a recovery command in a Docker-based gitea instance. The restore process contains the same steps as described in the previous section but with different paths.
+
+Example:
+
+```sh
+# open bash session in container
+docker exec --user git -it 2a83b293548e bash
+# unzip your backup file within the container
+unzip gitea-dump-1610949662.zip
+cd gitea-dump-1610949662
+# restore the gitea data
+mv data/* /data/gitea
+# restore the repositories itself
+mv repos/* /data/git/repositories/
+# adjust file permissions
+chown -R git:git /data
+# Regenerate Git Hooks
+/usr/local/bin/gitea -c '/data/gitea/conf/app.ini' admin regenerate hooks
+```
+
+The default user in the gitea container is `git` (1000:1000). Please replace `2a83b293548e` with your gitea container id or name.
+
+### Using Docker-rootless (`restore`)
+
+The restore workflow in Docker-rootless containers differs only in the directories to be used:
+
+```sh
+# open bash session in container
+docker exec --user git -it 2a83b293548e bash
+# unzip your backup file within the container
+unzip gitea-dump-1610949662.zip
+cd gitea-dump-1610949662
+# restore the app.ini
+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/repositories
+# adjust file permissions
+chown -R git:git /etc/gitea/app.ini /var/lib/gitea
+# Regenerate Git Hooks
+/usr/local/bin/gitea -c '/etc/gitea/app.ini' admin regenerate hooks
+```
+
+### Using `gitea dump` to convert database types
+
+The `gitea dump` command can produce a SQL file that can be read by another database type, which is useful to convert the database to another in case you did not choose the correct one during the first installation.
+
+Note that this conversion process is not well-tested, which is why it is recommended to choose the final database type during the first installation without attempting to change it afterwards.
+
+Stop the Gitea server, then make sure you have a full backup of your original database.
+
+Before attempting the conversion, ensure that the original database is clean. Run `gitea doctor check --all --fix` and `gitea doctor recreate-table` to address common issues.
+
+Use the `--database` flag to get a Gitea dump with the SQL file in the target format, in this example PostgreSQL: `gitea dump --database postgres`, then extract the file `gitea-db.sql` from the generated ZIP file.
+
+Create the PostgreSQL Gitea user and Gitea database. Then, import the SQL file as the Gitea user into the Gitea database, using commands such as:
+
+```sh
+sudo -u postgres psql -d gitea
+gitea=# SET synchronous_commit TO off
+gitea=# SET on_error_stop TO on
+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!

docs/administration/cmd-embedded.md

@@ -1,30 +1,23 @@
 ---
 date: "2020-01-25T21:00:00-03:00"
-title: "Embedded data extraction tool"
 slug: "cmd-embedded"
 sidebar_position: 20
-toc: false
-draft: false
 aliases:
   - /en-us/cmd-embedded
-menu:
-  sidebar:
-    parent: "administration"
-    name: "Embedded data extraction tool"
-    sidebar_position: 20
-    identifier: "cmd-embedded"
 ---
 
 # Embedded data extraction tool
 
 Gitea's executable contains all the resources required to run: templates, images, style-sheets
 and translations. Any of them can be overridden by placing a replacement in a matching path
-inside the `custom` directory (see [Customizing Gitea](administration/customizing-gitea.md)).
+inside the `custom` directory (see [Customizing Gitea](../administration/customizing-gitea.md)).
 
 To obtain a copy of the embedded resources ready for editing, the `embedded` command from the CLI
 can be used from the OS shell interface.
 
-**NOTE:** The embedded data extraction tool is included in Gitea versions 1.12 and above.
+:::note
+The embedded data extraction tool is included in Gitea versions 1.12 and above.
+:::
 
 ## Listing resources
 
@@ -83,7 +76,7 @@ The default is the current directory.
 The `--custom` flag tells Gitea to extract the files directly into the `custom` directory.
 For this to work, the command needs to know the location of the `app.ini` configuration
 file (`--config`) and, depending of the configuration, be ran from the directory where
-Gitea normally starts. See [Customizing Gitea](administration/customizing-gitea.md) for details.
+Gitea normally starts. See [Customizing Gitea](../administration/customizing-gitea.md) for details.
 
 The `--overwrite` flag allows any existing files in the destination directory to be overwritten.
 

docs/administration/command-line.md

@@ -0,0 +1,567 @@
+---
+date: "2017-01-01T16:00:00+02:00"
+slug: "command-line"
+sidebar_position: 1
+aliases:
+  - /en-us/command-line
+---
+
+# Gitea Command Line
+
+## Usage
+
+`gitea [global options] command [command or global options] [arguments...]`
+
+## Global options
+
+All global options can be placed at the command level.
+
+- `--help`, `-h`: Show help text and exit. Optional.
+- `--version`, `-v`: Show version and exit. Optional. (example: `Gitea version 1.1.0+218-g7b907ed built with: bindata, sqlite`).
+- `--work-path path`, `-w path`: Gitea's work path. Optional. (default: the binary's path or `$GITEA_WORK_DIR`)
+- `--custom-path path`, `-C path`: Gitea's custom folder path. Optional. (default: `WorkPath`/custom or `$GITEA_CUSTOM`).
+- `--config path`, `-c path`: Gitea configuration file path. Optional. (default: `CustomPath`/conf/app.ini).
+
+NB: The defaults custom-path, config and work-path can also be
+changed at build time (if preferred).
+
+## Commands
+
+### web
+
+Starts the server:
+
+- Options:
+  - `--port number`, `-p number`: Port number. Optional. (default: 3000). Overrides configuration file.
+  - `--install-port number`: Port number to run the install page on. Optional. (default: 3000). Overrides configuration file.
+  - `--pid path`, `-P path`: Pidfile path. Optional.
+  - `--quiet`, `-q`: Only emit Fatal logs on the console for logs emitted before logging set up.
+  - `--verbose`: Emit tracing logs on the console for logs emitted before logging is set-up.
+- Examples:
+  - `gitea web`
+  - `gitea web --port 80`
+  - `gitea web --config /etc/gitea.ini --pid /some/custom/gitea.pid`
+- Notes:
+  - 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
+
+Admin operations:
+
+- Commands:
+  - `user`:
+    - `list`:
+      - Options:
+        - `--admin`: List only admin users. Optional.
+      - Description: lists all users that exist
+      - Examples:
+        - `gitea admin user list`
+    - `delete`:
+      - Options:
+        - `--email`: Email of the user to be deleted.
+        - `--username`: Username of user to be deleted.
+        - `--id`: ID of user to be deleted.
+        - One of `--id`, `--username` or `--email` is required. If more than one is provided then all have to match.
+      - Examples:
+        - `gitea admin user delete --id 1`
+    - `create`:
+      - Options:
+        - `--name value`: Username. Required. As of Gitea 1.9.0, use the `--username` flag instead.
+        - `--username value`: Username. Required. New in Gitea 1.9.0.
+        - `--password value`: Password. Required.
+        - `--email value`: Email. Required.
+        - `--admin`: If provided, this makes the user an admin. Optional.
+        - `--access-token`: If provided, an access token will be created for the user. Optional. (default: false).
+        - `--must-change-password`: The created user will be required to set a new password after the initial login, default: true. It could be disabled by `--must-change-password=false`.
+        - `--random-password`: If provided, a randomly generated password will be used as the password of the created
+          user. The value of `--password` will be discarded. Optional.
+        - `--random-password-length`: If provided, it will be used to configure the length of the randomly generated
+          password. Optional. (default: 12)
+      - Examples:
+        - `gitea admin user create --username myname --password asecurepassword --email [email protected]`
+    - `change-password`:
+      - Options:
+        - `--username value`, `-u value`: Username. Required.
+        - `--password value`, `-p value`: New password. Required.
+        - `--must-change-password`: The user is required to set a new password after the login, default: true. It could be disabled by `--must-change-password=false`.
+      - Examples:
+        - `gitea admin user change-password --username myname --password asecurepassword`
+    - `must-change-password`:
+      - Args:
+        - `[username...]`: Users that must change their passwords
+      - Options:
+        - `--all`, `-A`: Force a password change for all users
+        - `--exclude username`, `-e username`: Exclude the given user. Can be set multiple times.
+        - `--unset`: Revoke forced password change for the given users
+    - `generate-access-token`:
+      - Options:
+        - `--username value`, `-u value`: Username. Required.
+        - `--token-name value`, `-t value`: Token name. Required.
+        - `--scopes value`: Comma-separated list of scopes. Scopes follow the format `[read|write]:<block>` or `all` where `<block>` is one of the available visual groups you can see when opening the API page showing the available routes (for example `repo`).
+      - Examples:
+        - `gitea admin user generate-access-token --username myname --token-name mytoken`
+        - `gitea admin user generate-access-token --help`
+  - `regenerate`
+    - Options:
+      - `hooks`: Regenerate Git Hooks for all repositories
+      - `keys`: Regenerate authorized_keys file
+    - Examples:
+      - `gitea admin regenerate hooks`
+      - `gitea admin regenerate keys`
+  - `auth`:
+    - `list`:
+      - Description: lists all external authentication sources that exist
+      - Examples:
+        - `gitea admin auth list`
+    - `delete`:
+      - Options:
+        - `--id`: ID of source to be deleted. Required.
+      - Examples:
+        - `gitea admin auth delete --id 1`
+    - `add-oauth`:
+      - Options:
+        - `--name`: Application Name.
+        - `--provider`: OAuth2 Provider.
+        - `--key`: Client ID (Key).
+        - `--secret`: Client Secret.
+        - `--auto-discover-url`: OpenID Connect Auto Discovery URL (only required when using OpenID Connect as provider).
+        - `--use-custom-urls`: Use custom URLs for GitLab/GitHub OAuth endpoints.
+        - `--custom-tenant-id`: Use custom Tenant ID for OAuth endpoints.
+        - `--custom-auth-url`: Use a custom Authorization URL (option for GitLab/GitHub).
+        - `--custom-token-url`: Use a custom Token URL (option for GitLab/GitHub).
+        - `--custom-profile-url`: Use a custom Profile URL (option for GitLab/GitHub).
+        - `--custom-email-url`: Use a custom Email URL (option for GitHub).
+        - `--icon-url`: Custom icon URL for OAuth2 login source.
+        - `--skip-local-2fa`: Allow source to override local 2FA. (Optional)
+        - `--scopes`: Additional scopes to request for this OAuth2 source. (Optional)
+        - `--required-claim-name`: Claim name that has to be set to allow users to login with this source. (Optional)
+        - `--required-claim-value`: Claim value that has to be set to allow users to login with this source. (Optional)
+        - `--group-claim-name`: Claim name providing group names for this source. (Optional)
+        - `--admin-group`: Group Claim value for administrator users. (Optional)
+        - `--restricted-group`: Group Claim value for restricted users. (Optional)
+        - `--group-team-map`: JSON mapping between groups and org teams. (Optional)
+        - `--group-team-map-removal`: Activate automatic team membership removal depending on groups. (Optional)
+      - Examples:
+        - `gitea admin auth add-oauth --name external-github --provider github --key OBTAIN_FROM_SOURCE --secret OBTAIN_FROM_SOURCE`
+    - `update-oauth`:
+      - Options:
+        - `--id`: ID of source to be updated. Required.
+        - `--name`: Application Name.
+        - `--provider`: OAuth2 Provider.
+        - `--key`: Client ID (Key).
+        - `--secret`: Client Secret.
+        - `--auto-discover-url`: OpenID Connect Auto Discovery URL (only required when using OpenID Connect as provider).
+        - `--use-custom-urls`: Use custom URLs for GitLab/GitHub OAuth endpoints.
+        - `--custom-tenant-id`: Use custom Tenant ID for OAuth endpoints.
+        - `--custom-auth-url`: Use a custom Authorization URL (option for GitLab/GitHub).
+        - `--custom-token-url`: Use a custom Token URL (option for GitLab/GitHub).
+        - `--custom-profile-url`: Use a custom Profile URL (option for GitLab/GitHub).
+        - `--custom-email-url`: Use a custom Email URL (option for GitHub).
+        - `--icon-url`: Custom icon URL for OAuth2 login source.
+        - `--skip-local-2fa`: Allow source to override local 2FA. (Optional)
+        - `--scopes`: Additional scopes to request for this OAuth2 source.
+        - `--required-claim-name`: Claim name that has to be set to allow users to login with this source. (Optional)
+        - `--required-claim-value`: Claim value that has to be set to allow users to login with this source. (Optional)
+        - `--group-claim-name`: Claim name providing group names for this source. (Optional)
+        - `--admin-group`: Group Claim value for administrator users. (Optional)
+        - `--restricted-group`: Group Claim value for restricted users. (Optional)
+      - Examples:
+        - `gitea admin auth update-oauth --id 1 --name external-github-updated`
+    - `add-smtp`:
+      - Options:
+        - `--name`: Application Name. Required.
+        - `--auth-type`: SMTP Authentication Type (PLAIN/LOGIN/CRAM-MD5). Default to PLAIN.
+        - `--host`: SMTP host. Required.
+        - `--port`: SMTP port. Required.
+        - `--force-smtps`: SMTPS is always used on port 465. Set this to force SMTPS on other ports.
+        - `--skip-verify`: Skip TLS verify.
+        - `--helo-hostname`: Hostname sent with HELO. Leave blank to send current hostname.
+        - `--disable-helo`: Disable SMTP helo.
+        - `--allowed-domains`: Leave empty to allow all domains. Separate multiple domains with a comma (',').
+        - `--skip-local-2fa`: Skip 2FA to log on.
+        - `--active`: This Authentication Source is Activated.
+        Remarks:
+        `--force-smtps`, `--skip-verify`, `--disable-helo`, `--skip-loca-2fs` and `--active` options can be used in form:
+        - `--option`, `--option=true` to enable
+        - `--option=false` to disable
+        If those options are not specified value would not be changed in `update-smtp` or would use default `false` value in `add-smtp`
+      - Examples:
+        - `gitea admin auth add-smtp --name ldap --host smtp.mydomain.org --port 587 --skip-verify --active`
+    - `update-smtp`:
+      - Options:
+        - `--id`: ID of source to be updated. Required.
+        - other options are shared with `add-smtp`
+      - Examples:
+        - `gitea admin auth update-smtp --id 1 --host smtp.mydomain.org --port 587 --skip-verify=false`
+        - `gitea admin auth update-smtp --id 1 --active=false`
+    - `add-ldap`: Add new LDAP (via Bind DN) authentication source
+      - Options:
+        - `--name value`: Authentication name. Required.
+        - `--not-active`: Deactivate the authentication source.
+        - `--security-protocol value`: Security protocol name. Required.
+        - `--skip-tls-verify`: Disable TLS verification.
+        - `--host value`: The address where the LDAP server can be reached. Required.
+        - `--port value`: The port to use when connecting to the LDAP server. Required.
+        - `--user-search-base value`: The LDAP base at which user accounts will be searched for. Required.
+        - `--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate. Required.
+        - `--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges.
+        - `--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status.
+        - `--username-attribute value`: The attribute of the user’s LDAP record containing the user name.
+        - `--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name.
+        - `--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname.
+        - `--email-attribute value`: The attribute of the user’s LDAP record containing the user’s email address. Required.
+        - `--public-ssh-key-attribute value`: The attribute of the user’s LDAP record containing the user’s public ssh key.
+        - `--avatar-attribute value`: The attribute of the user’s LDAP record containing the user’s avatar.
+        - `--bind-dn value`: The DN to bind to the LDAP server with when searching for the user.
+        - `--bind-password value`: The password for the Bind DN, if any.
+        - `--attributes-in-bind`: Fetch attributes in bind DN context.
+        - `--synchronize-users`: Enable user synchronization.
+        - `--page-size value`: Search page size.
+      - Examples:
+        - `gitea admin auth add-ldap --name ldap --security-protocol unencrypted --host mydomain.org --port 389 --user-search-base "ou=Users,dc=mydomain,dc=org" --user-filter "(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))" --email-attribute mail`
+    - `update-ldap`: Update existing LDAP (via Bind DN) authentication source
+      - Options:
+        - `--id value`: ID of authentication source. Required.
+        - `--name value`: Authentication name.
+        - `--not-active`: Deactivate the authentication source.
+        - `--security-protocol value`: Security protocol name.
+        - `--skip-tls-verify`: Disable TLS verification.
+        - `--host value`: The address where the LDAP server can be reached.
+        - `--port value`: The port to use when connecting to the LDAP server.
+        - `--user-search-base value`: The LDAP base at which user accounts will be searched for.
+        - `--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate.
+        - `--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges.
+        - `--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status.
+        - `--username-attribute value`: The attribute of the user’s LDAP record containing the user name.
+        - `--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name.
+        - `--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname.
+        - `--email-attribute value`: The attribute of the user’s LDAP record containing the user’s email address.
+        - `--public-ssh-key-attribute value`: The attribute of the user’s LDAP record containing the user’s public ssh key.
+        - `--avatar-attribute value`: The attribute of the user’s LDAP record containing the user’s avatar.
+        - `--bind-dn value`: The DN to bind to the LDAP server with when searching for the user.
+        - `--bind-password value`: The password for the Bind DN, if any.
+        - `--attributes-in-bind`: Fetch attributes in bind DN context.
+        - `--synchronize-users`: Enable user synchronization.
+        - `--page-size value`: Search page size.
+      - Examples:
+        - `gitea admin auth update-ldap --id 1 --name "my ldap auth source"`
+        - `gitea admin auth update-ldap --id 1 --username-attribute uid --firstname-attribute givenName --surname-attribute sn`
+    - `add-ldap-simple`: Add new LDAP (simple auth) authentication source
+      - Options:
+        - `--name value`: Authentication name. Required.
+        - `--not-active`: Deactivate the authentication source.
+        - `--security-protocol value`: Security protocol name. Required.
+        - `--skip-tls-verify`: Disable TLS verification.
+        - `--host value`: The address where the LDAP server can be reached. Required.
+        - `--port value`: The port to use when connecting to the LDAP server. Required.
+        - `--user-search-base value`: The LDAP base at which user accounts will be searched for.
+        - `--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate. Required.
+        - `--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges.
+        - `--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status.
+        - `--username-attribute value`: The attribute of the user’s LDAP record containing the user name.
+        - `--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name.
+        - `--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname.
+        - `--email-attribute value`: The attribute of the user’s LDAP record containing the user’s email address. Required.
+        - `--public-ssh-key-attribute value`: The attribute of the user’s LDAP record containing the user’s public ssh key.
+        - `--avatar-attribute value`: The attribute of the user’s LDAP record containing the user’s avatar.
+        - `--user-dn value`: The user’s DN. Required.
+      - Examples:
+        - `gitea admin auth add-ldap-simple --name ldap --security-protocol unencrypted --host mydomain.org --port 389 --user-dn "cn=%s,ou=Users,dc=mydomain,dc=org" --user-filter "(&(objectClass=posixAccount)(cn=%s))" --email-attribute mail`
+    - `update-ldap-simple`: Update existing LDAP (simple auth) authentication source
+      - Options:
+        - `--id value`: ID of authentication source. Required.
+        - `--name value`: Authentication name.
+        - `--not-active`: Deactivate the authentication source.
+        - `--security-protocol value`: Security protocol name.
+        - `--skip-tls-verify`: Disable TLS verification.
+        - `--host value`: The address where the LDAP server can be reached.
+        - `--port value`: The port to use when connecting to the LDAP server.
+        - `--user-search-base value`: The LDAP base at which user accounts will be searched for.
+        - `--user-filter value`: An LDAP filter declaring how to find the user record that is attempting to authenticate.
+        - `--admin-filter value`: An LDAP filter specifying if a user should be given administrator privileges.
+        - `--restricted-filter value`: An LDAP filter specifying if a user should be given restricted status.
+        - `--username-attribute value`: The attribute of the user’s LDAP record containing the user name.
+        - `--firstname-attribute value`: The attribute of the user’s LDAP record containing the user’s first name.
+        - `--surname-attribute value`: The attribute of the user’s LDAP record containing the user’s surname.
+        - `--email-attribute value`: The attribute of the user’s LDAP record containing the user’s email address.
+        - `--public-ssh-key-attribute value`: The attribute of the user’s LDAP record containing the user’s public ssh key.
+        - `--avatar-attribute value`: The attribute of the user’s LDAP record containing the user’s avatar.
+        - `--user-dn value`: The user’s DN.
+      - Examples:
+        - `gitea admin auth update-ldap-simple --id 1 --name "my ldap auth source"`
+        - `gitea admin auth update-ldap-simple --id 1 --username-attribute uid --firstname-attribute givenName --surname-attribute sn`
+
+### cert
+
+Generates a self-signed SSL certificate. Outputs to `cert.pem` and `key.pem` in the current
+directory and will overwrite any existing files.
+
+- Options:
+  - `--host value`: Comma separated hostnames and ips which this certificate is valid for.
+    Wildcards are supported. Required.
+  - `--ecdsa-curve value`: ECDSA curve to use to generate a key. Optional. Valid options
+    are P224, P256, P384, P521.
+  - `--rsa-bits value`: Size of RSA key to generate. Optional. Ignored if --ecdsa-curve is
+    set. (default: 3072).
+  - `--start-date value`: Creation date. Optional. (format: `Jan 1 15:04:05 2011`).
+  - `--duration value`: Duration which the certificate is valid for. Optional. (default: 8760h0m0s)
+  - `--ca`: If provided, this cert generates it's own certificate authority. Optional.
+- Examples:
+  - `gitea cert --host git.example.com,example.com,www.example.com --ca`
+
+### dump
+
+Dumps all files and databases into a zip file. Outputs into a file like `gitea-dump-1482906742.zip`
+in the current directory.
+
+- Options:
+  - `--file name`, `-f name`: Name of the dump file with will be created. Optional. (default: gitea-dump-[timestamp].zip).
+  - `--tempdir path`, `-t path`: Path to the temporary directory used. Optional. (default: /tmp).
+  - `--skip-repository`, `-R`: Skip the repository dumping. Optional.
+  - `--skip-custom-dir`: Skip dumping of the custom dir. Optional.
+  - `--skip-lfs-data`: Skip dumping of LFS data. Optional.
+  - `--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).
+- Examples:
+  - `gitea dump`
+  - `gitea dump --verbose`
+
+### generate
+
+Generates random values and tokens for usage in configuration file. Useful for generating values
+for automatic deployments.
+
+- Commands:
+  - `secret`:
+    - Options:
+      - `INTERNAL_TOKEN`: Token used for an internal API call authentication.
+      - `JWT_SECRET`: LFS & OAUTH2 JWT authentication secret (LFS_JWT_SECRET is aliased to this option for backwards compatibility).
+      - `SECRET_KEY`: Global secret key.
+    - Examples:
+      - `gitea generate secret INTERNAL_TOKEN`
+      - `gitea generate secret JWT_SECRET`
+      - `gitea generate secret SECRET_KEY`
+
+### keys
+
+Provides an SSHD AuthorizedKeysCommand. Needs to be configured in the sshd config file:
+
+```ini
+# The value of -e and the AuthorizedKeysCommandUser should match the
+# username running Gitea
+AuthorizedKeysCommandUser git
+AuthorizedKeysCommand /path/to/gitea keys -e git -u %u -t %t -k %k
+```
+
+The command will return the appropriate authorized_keys line for the
+provided key. You should also set the value
+`SSH_CREATE_AUTHORIZED_KEYS_FILE=false` in the `[server]` section of
+`app.ini`.
+
+:::note
+opensshd requires the Gitea program to be owned by root and not
+writable by group or others. The program must be specified by an absolute
+path.
+Gitea must be running for this command to succeed.
+:::
+
+### migrate
+
+Migrates the database. This command can be used to run other commands before starting the server for the first time.
+This command is idempotent.
+
+### doctor check
+
+Diagnose and potentially fix problems with the current Gitea instance.
+Several checks are run by default, but additional ones can be run:
+
+- `gitea doctor check --list` - will list all the available checks
+- `gitea doctor check --all` - will run all available checks
+- `gitea doctor check --default` - will run the default checks
+- `gitea doctor check --run [check(s),]...` - will run the named checks
+
+Some problems can be automatically fixed by passing the `--fix` option.
+Extra logging can be set with `--log-file=...`.
+
+#### doctor recreate-table
+
+Sometimes when there are migrations the old columns and default values may be left
+unchanged in the database schema. This may lead to warning such as:
+
+```log
+2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync() [W] Table user Column keep_activity_private db default is , struct default is 0
+```
+
+You can cause Gitea to recreate these tables and copy the old data into the new table
+with the defaults set appropriately by using:
+
+```bash
+gitea doctor recreate-table user
+```
+
+You can ask Gitea to recreate multiple tables using:
+
+```bash
+gitea doctor recreate-table table1 table2 ...
+```
+
+And if you would like Gitea to recreate all tables simply call:
+
+```bash
+gitea doctor recreate-table
+```
+
+It is highly recommended to back-up your database before running these commands.
+
+### doctor convert
+
+Converts a MySQL database from utf8 to utf8mb4 or a MSSQL database from varchar to nvarchar.
+
+### manager
+
+Manage running server operations:
+
+- Commands:
+  - `shutdown`: Gracefully shutdown the running process
+  - `restart`: Gracefully restart the running process - (not implemented for windows servers)
+  - `flush-queues`: Flush queues in the running process
+    - Options:
+      - `--timeout value`: Timeout for the flushing process (default: 1m0s)
+      - `--non-blocking`: Set to true to not wait for flush to complete before returning
+  - `logging`: Adjust logging commands
+    - Commands:
+      - `pause`: Pause logging
+        - Notes:
+          - The logging level will be raised to INFO temporarily if it is below this level.
+          - Gitea will buffer logs up to a certain point and will drop them after that point.
+      - `resume`: Resume logging
+      - `release-and-reopen`: Cause Gitea to release and re-open files and connections used for logging (Equivalent to sending SIGUSR1 to Gitea.)
+      - `remove name`: Remove the named logger
+        - Options:
+          - `--group group`, `-g group`: Set the group to remove the sublogger from. (defaults to `default`)
+      - `add`: Add a logger
+        - Commands:
+          - `console`: Add a console logger
+            - Options:
+              - `--group value`, `-g value`: Group to add logger to - will default to "default"
+              - `--name value`, `-n value`: Name of the new logger - will default to mode
+              - `--level value`, `-l value`: Logging level for the new logger
+              - `--stacktrace-level value`, `-L value`: Stacktrace logging level
+              - `--flags value`, `-F value`: Flags for the logger
+              - `--expression value`, `-e value`: Matching expression for the logger
+              - `--prefix value`, `-p value`: Prefix for the logger
+              - `--color`: Use color in the logs
+              - `--stderr`: Output console logs to stderr - only relevant for console
+          - `file`: Add a file logger
+            - Options:
+              - `--group value`, `-g value`: Group to add logger to - will default to "default"
+              - `--name value`, `-n value`: Name of the new logger - will default to mode
+              - `--level value`, `-l value`: Logging level for the new logger
+              - `--stacktrace-level value`, `-L value`: Stacktrace logging level
+              - `--flags value`, `-F value`: Flags for the logger
+              - `--expression value`, `-e value`: Matching expression for the logger
+              - `--prefix value`, `-p value`: Prefix for the logger
+              - `--color`: Use color in the logs
+              - `--filename value`, `-f value`: Filename for the logger -
+              - `--rotate`, `-r`: Rotate logs
+              - `--max-size value`, `-s value`: Maximum size in bytes before rotation
+              - `--daily`, `-d`: Rotate logs daily
+              - `--max-days value`, `-D value`: Maximum number of daily logs to keep
+              - `--compress`, `-z`: Compress rotated logs
+              - `--compression-level value`, `-Z value`: Compression level to use
+          - `conn`: Add a network connection logger
+            - Options:
+              - `--group value`, `-g value`: Group to add logger to - will default to "default"
+              - `--name value`, `-n value`: Name of the new logger - will default to mode
+              - `--level value`, `-l value`: Logging level for the new logger
+              - `--stacktrace-level value`, `-L value`: Stacktrace logging level
+              - `--flags value`, `-F value`: Flags for the logger
+              - `--expression value`, `-e value`: Matching expression for the logger
+              - `--prefix value`, `-p value`: Prefix for the logger
+              - `--color`: Use color in the logs
+              - `--reconnect-on-message`, `-R`: Reconnect to host for every message
+              - `--reconnect`, `-r`: Reconnect to host when connection is dropped
+              - `--protocol value`, `-P value`: Set protocol to use: tcp, unix, or udp (defaults to tcp)
+              - `--address value`, `-a value`: Host address and port to connect to (defaults to :7020)
+          - `smtp`: Add an SMTP logger
+            - Options:
+              - `--group value`, `-g value`: Group to add logger to - will default to "default"
+              - `--name value`, `-n value`: Name of the new logger - will default to mode
+              - `--level value`, `-l value`: Logging level for the new logger
+              - `--stacktrace-level value`, `-L value`: Stacktrace logging level
+              - `--flags value`, `-F value`: Flags for the logger
+              - `--expression value`, `-e value`: Matching expression for the logger
+              - `--prefix value`, `-p value`: Prefix for the logger
+              - `--color`: Use color in the logs
+              - `--username value`, `-u value`: Mail server username
+              - `--password value`, `-P value`: Mail server password
+              - `--host value`, `-H value`: Mail server host (defaults to: 127.0.0.1:25)
+              - `--send-to value`, `-s value`: Email address(es) to send to
+              - `--subject value`, `-S value`: Subject header of sent emails
+  - `processes`: Display Gitea processes and goroutine information
+    - Options:
+      - `--flat`: Show processes as flat table rather than as tree
+      - `--no-system`: Do not show system processes
+      - `--stacktraces`: Show stacktraces for goroutines associated with processes
+      - `--json`: Output as json
+      - `--cancel PID`: Send cancel to process with PID. (Only for non-system processes.)
+
+### dump-repo
+
+Dump-repo dumps repository data from Git/GitHub/Gitea/GitLab:
+
+- Options:
+  - `--git_service service` : Git service, it could be `git`, `github`, `gitea`, `gitlab`, If clone_addr could be recognized, this could be ignored.
+  - `--repo_dir dir`, `-r dir`: Repository dir path to store the data
+  - `--clone_addr addr`: The URL will be clone, currently could be a git/github/gitea/gitlab http/https URL. i.e. https://github.com/lunny/tango.git
+  - `--auth_username lunny`: The username to visit the clone_addr
+  - `--auth_password <password>`: The password to visit the clone_addr
+  - `--auth_token <token>`: The personal token to visit the clone_addr
+  - `--owner_name lunny`: The data will be stored on a directory with owner name if not empty
+  - `--repo_name tango`: The data will be stored on a directory with repository name if not empty
+  - `--units <units>`: Which items will be migrated, one or more units should be separated as comma. wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments are allowed. Empty means all units.
+
+### restore-repo
+
+Restore-repo restore repository data from disk dir:
+
+- Options:
+  - `--repo_dir dir`, `-r dir`: Repository dir path to restore from
+  - `--owner_name lunny`: Restore destination owner name
+  - `--repo_name tango`: Restore destination repository name
+  - `--units <units>`: Which items will be restored, one or more units should be separated as comma. wiki, issues, labels, releases, release_assets, milestones, pull_requests, comments are allowed. Empty means all units.
+
+### actions generate-runner-token
+
+Generate a new token for a runner to use to register with the server
+
+- Options:
+  - `--scope {owner}[/{repo}]`, `-s {owner}[/{repo}]`: To limit the scope of the runner, no scope means the runner can be used for all repos, but you can also limit it to a specific repo or owner
+
+To register a global runner:
+
+```bash
+gitea actions generate-runner-token
+```
+
+To register a runner for a specific organization, in this case `org`:
+
+```bash
+gitea actions generate-runner-token -s org
+```
+
+To register a runner for a specific repo, in this case `username/test-repo`:
+
+```bash
+gitea actions generate-runner-token -s username/test-repo
+```

docs/administration/customizing-gitea.md

@@ -0,0 +1,516 @@
+---
+date: "2017-04-15T14:56:00+02:00"
+slug: "customizing-gitea"
+sidebar_position: 100
+aliases:
+  - /en-us/customizing-gitea
+---
+
+# 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 [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
+the `CustomPath` by setting either the `GITEA_CUSTOM` environment variable or by
+using the `--custom-path` option on the `gitea` binary. (The option will override the
+environment variable.)
+
+If Gitea is deployed from binary, all default paths will be relative to the Gitea
+binary. If installed from a distribution, these paths will likely be modified to
+the Linux Filesystem Standard. Gitea will attempt to create required folders, including
+`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 [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.
+
+- [Quick Cheat Sheet](../administration/config-cheat-sheet.md)
+- [Complete List](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
+
+If the `CustomPath` folder can't be found despite checking `gitea help`, check the `GITEA_CUSTOM`
+environment variable; this can be used to override the default path to something else.
+`GITEA_CUSTOM` might, for example, be set by an init script. You can check whether the value
+is set under the "Configuration" tab on the site administration page.
+
+- [List of Environment Variables](../administration/environment-variables.md)
+
+:::note
+Gitea must perform a full restart to see configuration changes.
+:::
+
+## Serving custom public files
+
+To make Gitea serve custom public files (like pages and images), use the folder
+`$GITEA_CUSTOM/public/` as the webroot. Symbolic links will be followed.
+At the moment, only the following files are served:
+
+- `public/robots.txt`
+- files in the `public/.well-known/` folder
+- files in the `public/assets/` folder
+
+For example, a file `image.png` stored in `$GITEA_CUSTOM/public/assets/`, can be accessed with
+the url `http://gitea.domain.tld/assets/image.png`.
+
+## Changing the logo
+
+To build a custom logo and/or favicon clone the Gitea source repository, replace `assets/logo.svg` and/or `assets/favicon.svg` and run
+`make generate-images`. `assets/favicon.svg` is used for the favicon only. This will update below output files which you can then place in `$GITEA_CUSTOM/public/assets/img` on your server:
+
+- `public/assets/img/logo.svg` - Used for site icon, app icon
+- `public/assets/img/logo.png` - Used for Open Graph
+- `public/assets/img/avatar_default.png` - Used as the default avatar image
+- `public/assets/img/apple-touch-icon.png` - Used on iOS devices for bookmarks
+- `public/assets/img/favicon.svg` - Used for favicon
+- `public/assets/img/favicon.png` - Used as fallback for browsers that don't support SVG favicons
+
+In case the source image is not in vector format, you can attempt to convert a raster image using tools like [this](https://www.aconvert.com/image/png-to-svg/).
+
+## Customizing Gitea pages and resources
+
+Gitea's executable contains all the resources required to run: templates, images, style-sheets
+and translations. Any of them can be overridden by placing a replacement in a matching path
+inside the `custom` directory. For example, to replace the default `.gitignore` provided
+for C++ repositories, we want to replace `options/gitignore/C++`. To do this, a replacement
+must be placed in `$GITEA_CUSTOM/options/gitignore/C++` (see about the location of the `CustomPath`
+directory at the top of this document).
+
+Every single page of Gitea can be changed. Dynamic content is generated using [go templates](https://pkg.go.dev/html/template),
+which can be modified by placing replacements below the `$GITEA_CUSTOM/templates` directory.
+
+To obtain any embedded file (including templates), the [`gitea embedded` tool](../administration/cmd-embedded.md) can be used. Alternatively, they can be found in the [`templates`](https://github.com/go-gitea/gitea/tree/main/templates) directory of Gitea source (Note: the example link is from the `main` branch. Make sure to use templates compatible with the release you are using).
+
+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`.
+Edit as you wish.
+Dont forget to restart your Gitea to apply the changes.
+
+### Adding links and tabs
+
+If all you want is to add extra links to the top navigation bar or footer, or extra tabs to the repository view, you can put them in `extra_links.tmpl` (links added to the navbar), `extra_links_footer.tmpl` (links added to the left side of footer), and `extra_tabs.tmpl` inside your `$GITEA_CUSTOM/templates/custom/` directory.
+
+For instance, let's say you are in Germany and must add the famously legally-required "Impressum"/about page, listing who is responsible for the site's content:
+just place it under your "$GITEA_CUSTOM/public/assets/" directory (for instance `$GITEA_CUSTOM/public/assets/impressum.html`) and put a link to it in either `$GITEA_CUSTOM/templates/custom/extra_links.tmpl` or `$GITEA_CUSTOM/templates/custom/extra_links_footer.tmpl`.
+
+To match the current style, the link should have the class name "item", and you can use `{{AppSubUrl}}` to get the base URL:
+`<a class="item" href="{{AppSubUrl}}/assets/impressum.html">Impressum</a>`
+
+For more information, see [Adding Legal Pages](../administration/adding-legal-pages.md).
+
+You can add new tabs in the same way, putting them in `extra_tabs.tmpl`.
+The exact HTML needed to match the style of other tabs is in the file
+`templates/repo/header.tmpl`
+([source in GitHub](https://github.com/go-gitea/gitea/blob/main/templates/repo/header.tmpl))
+
+### Other additions to the page
+
+Apart from `extra_links.tmpl` and `extra_tabs.tmpl`, there are other useful templates you can put in your `$GITEA_CUSTOM/templates/custom/` directory:
+
+- `header.tmpl`, just before the end of the `<head>` tag where you can add custom CSS files for instance.
+- `body_outer_pre.tmpl`, right after the start of `<body>`.
+- `body_inner_pre.tmpl`, before the top navigation bar, but already inside the main container `<div class="full height">`.
+- `body_inner_post.tmpl`, before the end of the main container.
+- `body_outer_post.tmpl`, before the bottom `<footer>` element.
+- `footer.tmpl`, right before the end of the `<body>` tag, a good place for additional JavaScript.
+
+### Using Gitea variables
+
+It's possible to use various Gitea variables in your custom templates.
+
+First, _temporarily_ enable development mode: in your `app.ini` change from `RUN_MODE = prod` to `RUN_MODE = dev`. Then add `{{ $ | DumpVar }}` to any of your templates, restart Gitea and refresh that page; that will dump all available variables.
+
+Find the data that you need, and use the corresponding variable; for example, if you need the name of the repository then you'd use `{{.Repository.Name}}`.
+
+If you need to transform that data somehow, and aren't familiar with Go, an easy workaround is to add the data to the DOM and add a small JavaScript script block to manipulate the data.
+
+### Example: PlantUML
+
+You can add [PlantUML](https://plantuml.com/) support to Gitea's markdown by using a PlantUML server.
+The data is encoded and sent to the PlantUML server which generates the picture. There is an online
+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 `$GITEA_CUSTOM/templates/custom/footer.tmpl`:
+
+```html
+<script nonce="{{ctx.CspScriptNonce}}">
+  $(async () => {
+    if (!$('.language-plantuml').length) return;
+    await Promise.all([
+      $.getScript('https://your-gitea-server.com/assets/deflate.js'),
+      $.getScript('https://your-gitea-server.com/assets/encode.js'),
+      $.getScript('https://your-gitea-server.com/assets/plantuml_codeblock_parse.js'),
+    ]);
+    // Replace call with address to your plantuml server
+    parsePlantumlCodeBlocks("https://www.plantuml.com/plantuml");
+  });
+</script>
+```
+
+You can then add blocks like the following to your markdown:
+
+```plantuml
+Alice -> Bob: Authentication Request
+Bob --> Alice: Authentication Response
+
+Alice -> Bob: Another authentication Request
+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: CAD Files Preview using Online 3D Viewer
+
+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 nonce="{{ctx.CspScriptNonce}}">
+    function onPageChange() {
+      // Supported 3D file types
+      const fileTypes = ['3dm', '3ds', '3mf', 'amf', 'bim', 'brep', 'dae', 'fbx', 'fcstd', 'glb', 'gltf', 'ifc', 'igs', 'iges', 'stp', 'step', 'stl', 'obj', 'off', 'ply', 'wrl'];
+
+      // Select matching link
+      const links = Array.from(document.querySelectorAll('a.ui.mini.basic.button'));
+      const link3D = links.find(link => {
+        const href = link.href.toLowerCase();
+        return href.includes('/raw/') && fileTypes.some(ext => href.endsWith(`.${ext}`));
+      });
+
+	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>
+```
+
+#### Part 2: Add public files
+
+Now we need to download latest version of O3DV. Go to "$GITEA_CUSTOM/public/assets/".
+Create folder using (and cd into it):
+
+```
+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
+-- custom
+    `-- footer.tmpl
+
+$GITEA_CUSTOM/public/assets/
+-- o3dv
+   |-- o3dv.zip
+   |-- o3dv.license.md
+   |-- o3dv.min.js
+   |-- envmaps
+    \...
+```
+
+## Customizing Gitea mails
+
+The `$GITEA_CUSTOM/templates/mail` folder allows changing the body of every mail of Gitea.
+Templates to override can be found in the
+[`templates/mail`](https://github.com/go-gitea/gitea/tree/main/templates/mail)
+directory of Gitea source.
+Override by making a copy of the file under `$GITEA_CUSTOM/templates/mail` using a
+full path structure matching source.
+
+Any statement contained inside `{{` and `}}` are Gitea's template
+syntax and shouldn't be touched without fully understanding these components.
+
+## Adding Analytics to Gitea
+
+Google Analytics, Matomo (previously Piwik), and other analytics services can be added to Gitea. To add the tracking code, refer to the `Other additions to the page` section of this document, and add the JavaScript to the `$GITEA_CUSTOM/templates/custom/header.tmpl` file.
+
+## Customizing gitignores, labels, licenses, locales, and readmes
+
+Place custom files in corresponding sub-folder under `custom/options`.
+
+:::note
+The files should not have a file extension, e.g. `Labels` rather than `Labels.txt`
+:::
+
+### gitignores
+
+To add custom .gitignore, add a file with existing [.gitignore rules](https://git-scm.com/docs/gitignore) in it to `$GITEA_CUSTOM/options/gitignore`
+
+## Customizing the git configuration
+
+Starting with Gitea 1.20, you can customize the git configuration via the `git.config` section.
+
+### Enabling signed git pushes
+
+[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.certNonceSeed = <randomstring>
+```
+
+`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
+
+Starting with Gitea 1.19, you can add a file that follows the [YAML label format](https://github.com/go-gitea/gitea/blob/main/options/label/Advanced.yaml) to `$GITEA_CUSTOM/options/label`:
+
+```yaml
+labels:
+  - name: "foo/bar"  # name of the label that will appear in the dropdown
+    exclusive: true # whether to use the exclusive namespace for scoped labels. scoped delimiter is /
+    color: aabbcc # hex colour coding
+    description: Some label # long description of label intent
+ ```
+
+The [legacy file format](https://github.com/go-gitea/gitea/blob/main/options/label/Default) can still be used following the format below, however we strongly recommend using the newer YAML format instead.
+
+`#hex-color label name ; label description`
+
+For more information, see the [labels documentation](../usage/issues-prs/labels.md).
+
+### Licenses
+
+To add a custom license, add a file with the license text to `$GITEA_CUSTOM/options/license`
+
+### Locales
+
+Locales are managed via our [Crowdin](https://crowdin.com/project/gitea).
+You can override a locale by placing an altered locale file in `$GITEA_CUSTOM/options/locale`.
+Gitea's default locale files can be found in the [`options/locale`](https://github.com/go-gitea/gitea/tree/main/options/locale) source folder and these should be used as examples for your changes.
+
+To add a completely new locale, as well as placing the file in the above location, you will need to add the new lang and name to the `[i18n]` section in your `app.ini`. Keep in mind that Gitea will use those settings as **overrides**, so if you want to keep the other languages as well you will need to copy/paste the default values and add your own to them.
+
+```ini title="app.ini"
+[i18n]
+LANGS = en-US,foo-BAR
+NAMES = English,FooBar
+```
+
+The first locale will be used as the default if user browser's language doesn't match any locale in the list.
+
+Locales may change between versions, so keeping track of your customized locales is highly encouraged.
+
+### Readmes
+
+To add a custom Readme, add a markdown formatted file (without an `.md` extension) to `$GITEA_CUSTOM/options/readme`
+
+:::note
+Readme templates support **variable expansion**.
+currently there are `{Name}` (name of repository), `{Description}`, `{CloneURL.SSH}`, `{CloneURL.HTTPS}` and `{OwnerName}`
+:::
+
+### Reactions
+
+To change reaction emoji's you can set allowed reactions at app.ini
+
+```ini title="app.ini"
+[ui]
+REACTIONS = +1, -1, laugh, confused, heart, hooray, eyes
+```
+
+A full list of supported emoji's is at [emoji list](https://gitea.com/gitea/gitea.com/issues/8)
+
+## Customizing the look of Gitea
+
+The built-in themes are `gitea-light`, `gitea-dark`, and `gitea-auto` (which automatically adapts to OS settings).
+
+The default theme can be changed via `DEFAULT_THEME` in the [ui](../administration/config-cheat-sheet.md#ui-ui) section of `app.ini`.
+
+Gitea also has support for user themes, which means every user can select which theme should be used.
+The list of themes a user can choose from can be configured with the `THEMES` value in the [ui](../administration/config-cheat-sheet.md#ui-ui) section of `app.ini`.
+
+To make a custom theme available to all users:
+
+1. Add a CSS file to `$GITEA_CUSTOM/public/assets/css/theme-<theme-name>.css`.
+  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).
+
+## Customizing fonts
+
+Fonts can be customized using CSS variables:
+
+```css
+:root {
+  --fonts-proportional: /* custom proportional fonts */ !important;
+  --fonts-monospace: /* custom monospace fonts */ !important;
+  --fonts-emoji: /* custom emoji fonts */ !important;
+}
+```

docs/administration/email-setup.md

@@ -0,0 +1,135 @@
+---
+date: "2019-10-15T10:10:00+05:00"
+slug: "email-setup"
+sidebar_position: 12
+aliases:
+  - /en-us/email-setup
+---
+
+# Email setup
+
+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.
+
+:::note
+For use in the official Gitea Docker image, please configure with the SMTP version (see the following section).
+:::
+
+:::note
+For Internet-facing sites consult documentation of your MTA for instructions to send emails over TLS. Also set up SPF, DMARC, and DKIM DNS records to make emails sent be accepted as legitimate by various email providers.
+:::
+
+```ini title="app.ini"
+[mailer]
+ENABLED       = true
+FROM          = [email protected]
+PROTOCOL      = sendmail
+SENDMAIL_PATH = /usr/sbin/sendmail
+SENDMAIL_ARGS = "--" ; most "sendmail" programs take options, "--" will prevent an email address being interpreted as an option.
+```
+
+## Using SMTP
+
+Directly use SMTP server as relay. This option is useful if you don't want to set up MTA on your instance but you have an account at email provider.
+
+```ini title="app.ini"
+[mailer]
+ENABLED        = true
+FROM           = [email protected]
+PROTOCOL       = smtps
+SMTP_ADDR      = mail.mydomain.com
+SMTP_PORT      = 465
+USER           = [email protected]
+PASSWD         = `password`
+```
+
+Restart Gitea for the configuration changes to take effect.
+
+To send a test email to validate the settings, go to Gitea > Site Administration > Configuration > Summary -> Mailer Configuration.
+
+For the full list of options check the [Config Cheat Sheet](../administration/config-cheat-sheet.md)
+
+:::note
+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 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.
+
+Note that Implicit TLS is recommended by [RFC8314](https://tools.ietf.org/html/rfc8314#section-3) since 2018.
+
+### Gmail
+
+The following configuration should work with GMail's SMTP server:
+
+```ini title="app.ini"
+[mailer]
+ENABLED        = true
+HOST           = smtp.gmail.com:465 ; Remove this line for Gitea >= 1.18.0
+SMTP_ADDR      = smtp.gmail.com
+SMTP_PORT      = 465
+FROM           = [email protected]
+USER           = example.user
+PASSWD         = `***`
+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.
+
+Note that emails sent using SMTP are not [end-to-end encrypted](https://proton.me/support/proton-mail-encryption-explained). However, they’re still stored with zero-access encryption like any other emails in your Proton Mail inbox.
+
+The following configuration should work with ProtonMail's SMTP server:
+
+1. In your browser (or desktop application), sign in to your Proton Mail account and select **Settings → All settings → Proton Mail → IMAP/SMTP → SMTP tokens**.
+2. Click **Generate token**.
+3. Enter the following details to create a new SMTP token:
+    - **Token name**: Select a name for your token. This is for your reference only and does not affect the token's functionality.
+    - **Email address**: Select one of your active custom domain addresses to pair with your token. Copy this email address and use it for the `FROM` and `USER` configuration in `app.ini`.
+4. Click **Generate**.
+5. Enter your Proton Mail Account password.
+
+Your SMTP username and SMTP token (password) will be generated. You can now enter them as the `USER` and `PASSWD` in your `app.ini` configuration.
+
+```ini title="app.ini"
+[mailer]
+ENABLED        = true
+FROM           = [email protected]
+PROTOCOL       = smtp+starttls
+SMTP_ADDR      = smtp.protonmail.ch
+SMTP_PORT      = 587
+USER           = [email protected]
+PASSWD         = `TOKEN`
+```
+
+After closing the popup, you will not be able to see this SMTP token (password) again for security reasons. You can always generate more tokens if you need to rotate passwords.
+
+Note: Your Proton Mail login or mailbox passwords will not work with SMTP

docs/administration/environment-variables.md

@@ -1,18 +1,9 @@
 ---
 date: "2017-04-08T11:34:00+02:00"
-title: "Environment variables"
 slug: "environment-variables"
 sidebar_position: 10
-toc: false
-draft: false
 aliases:
   - /en-us/environment-variables
-menu:
-  sidebar:
-    parent: "administration"
-    name: "Environment variables"
-    sidebar_position: 10
-    identifier: "environment-variables"
 ---
 
 # Environment variables

docs/administration/external-renderers.md

@@ -1,21 +1,12 @@
 ---
 date: "2018-11-23:00:00+02:00"
-title: "External renderers"
 slug: "external-renderers"
 sidebar_position: 60
-toc: false
-draft: false
 aliases:
   - /en-us/external-renderers
-menu:
-  sidebar:
-    parent: "administration"
-    name: "External renderers"
-    sidebar_position: 60
-    identifier: "external-renderers"
 ---
 
-# Custom files rendering configuration
+# External renderers
 
 Gitea supports custom file renderings (i.e., Jupyter notebooks, asciidoc, etc.) through external binaries,
 it is just a matter of:
@@ -24,7 +15,7 @@ it is just a matter of:
 - add some configuration to your `app.ini` file
 - restart your Gitea instance
 
-This supports rendering of whole files. If you want to render code blocks in markdown you would need to do something with javascript. See some examples on the [Customizing Gitea](administration/customizing-gitea.md) page.
+This supports rendering of whole files. If you want to render code blocks in markdown you would need to do something with javascript. See some examples on the [Customizing Gitea](../administration/customizing-gitea.md) page.
 
 ## Installing external binaries
 
@@ -32,18 +23,16 @@ 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 gitea/gitea:@version@
+FROM docker.gitea.com/gitea:@dockerVersion@
 [...]
 
 COPY custom/app.ini /data/gitea/conf/app.ini
 [...]
 
-RUN apk --no-cache add asciidoctor freetype freetype-dev gcc g++ libpng libffi-dev py-pip python3-dev py3-pip py3-pyzmq
+RUN apk --no-cache add asciidoctor freetype freetype-dev gcc g++ libpng libffi-dev pandoc python3-dev py3-pyzmq pipx
 # install any other package you need for your external renderers
 
-RUN pip3 install --upgrade pip
-RUN pip3 install -U setuptools
-RUN pip3 install jupyter docutils
+RUN pipx install jupyter docutils --include-deps --global
 # add above any other python package you may need to install
 ```
 

docs/administration/fail2ban-setup.md

@@ -0,0 +1,118 @@
+---
+date: "2018-05-11T11:00:00+02:00"
+slug: "fail2ban-setup"
+sidebar_position: 16
+aliases:
+  - /en-us/fail2ban-setup
+---
+
+# Fail2ban Setup
+
+**Remember that fail2ban is powerful and can cause lots of issues if you do it incorrectly, so make
+sure to test this before relying on it so you don't lock yourself out.**
+
+Gitea returns an HTTP 200 for bad logins in the web logs, but if you have logging options on in
+`app.ini`, then you should be able to go off of `log/gitea.log`, which gives you something like this
+on a bad authentication from the web or CLI using SSH or HTTP respectively:
+
+```log
+2018/04/26 18:15:54 [I] Failed authentication attempt for user from xxx.xxx.xxx.xxx
+```
+
+```log
+2020/10/15 16:05:09 modules/ssh/ssh.go:143:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
+```
+
+(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
+
+```log
+2020/10/15 16:05:09 modules/ssh/ssh.go:155:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
+```
+
+(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
+
+```log
+2020/10/15 16:05:09 modules/ssh/ssh.go:198:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
+```
+
+(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
+
+```log
+2020/10/15 16:05:09 modules/ssh/ssh.go:213:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
+```
+
+(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
+
+```log
+2020/10/15 16:05:09 modules/ssh/ssh.go:227:publicKeyHandler() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
+```
+
+(DEPRECATED: This may be a false positive as the user may still go on to correctly authenticate.)
+
+```log
+2020/10/15 16:05:09 modules/ssh/ssh.go:249:sshConnectionFailed() [W] Failed authentication attempt from xxx.xxx.xxx.xxx
+```
+
+(From 1.15 this new message will available and doesn't have any of the false positive results that above messages from publicKeyHandler do. This will only be logged if the user has completely failed authentication.)
+
+```log
+2020/10/15 16:08:44 ...s/context/context.go:204:HandleText() [E] invalid credentials from xxx.xxx.xxx.xxx
+```
+
+Add our filter in `/etc/fail2ban/filter.d/gitea.local`:
+
+```ini
+# gitea.local
+[Definition]
+failregex =  .*(Failed authentication attempt|invalid credentials|Attempted access of unknown user).* from <HOST>
+ignoreregex =
+```
+
+Add our jail in `/etc/fail2ban/jail.d/gitea.local`:
+
+```ini
+[gitea]
+enabled = true
+filter = gitea
+logpath = /var/lib/gitea/log/gitea.log
+maxretry = 10
+findtime = 3600
+bantime = 900
+action = iptables-allports
+```
+
+If you're using Docker, you'll also need to add an additional jail to handle the **FORWARD**
+chain in **iptables**. Configure it in `/etc/fail2ban/jail.d/gitea-docker.local`:
+
+```ini
+[gitea-docker]
+enabled = true
+filter = gitea
+logpath = /var/lib/gitea/log/gitea.log
+maxretry = 10
+findtime = 3600
+bantime = 900
+action = iptables-allports[chain="FORWARD"]
+```
+
+Then simply run `service fail2ban restart` to apply your changes. You can check to see if
+fail2ban has accepted your configuration using `service fail2ban status`.
+
+Make sure and read up on fail2ban and configure it to your needs, this bans someone
+for **15 minutes** (from all ports) when they fail authentication 10 times in an hour.
+
+If you run Gitea behind a reverse proxy with Nginx (for example with Docker), you need to add
+this to your Nginx configuration so that IPs don't show up as 127.0.0.1:
+
+```
+proxy_set_header X-Real-IP $remote_addr;
+```
+
+The security options in `app.ini` need to be adjusted to allow the interpretation of the headers
+as well as the list of IP addresses and networks that describe trusted proxy servers
+(See the [configuration cheat sheet](../administration/config-cheat-sheet.md#security-security) for more information).
+
+```
+REVERSE_PROXY_LIMIT = 1
+REVERSE_PROXY_TRUSTED_PROXIES = 127.0.0.1/8 ; 172.17.0.0/16 for the docker default network
+```

docs/administration/git-lfs-support.md

@@ -0,0 +1,64 @@
+---
+date: "2019-10-06T08:00:00+05:00"
+slug: "git-lfs-setup"
+sidebar_position: 12
+aliases:
+  - /en-us/git-lfs-setup
+---
+
+# Git LFS setup
+
+To use Gitea's built-in LFS support, you must update the `app.ini` file:
+
+```ini
+[server]
+; Enables git-lfs support. true or false, default is false.
+LFS_START_SERVER = true
+
+[lfs]
+; Where your lfs files reside, default is data/lfs.
+PATH = /home/gitea/data/lfs
+```
+
+:::note
+LFS server support needs at least Git v2.1.2 installed on the server
+:::
+
+# Git LFS Pure SSH protocol
+
+The LFS Pure SSH protocol supports making LFS connections purely over SSH
+(without having to expose an HTTP endpoint for the Gitea server).
+Support for it can be enabled with the config option `server.LFS_ALLOW_PURE_SSH`:
+
+```ini
+[server]
+LFS_ALLOW_PURE_SSH = true
+```
+
+:::note
+The option is currently set to default false due to an open bug in the `git-lfs`
+client that causes SSH transfers to hang: https://github.com/git-lfs/git-lfs/pull/5816
+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

@@ -0,0 +1,115 @@
+---
+date: "2018-06-02T11:00:00+02:00"
+slug: "https-setup"
+sidebar_position: 12
+aliases:
+  - /en-us/https-setup
+---
+
+# HTTPS Setup
+
+## Using the built-in server
+
+Before you enable HTTPS, make sure that you have valid SSL/TLS certificates.
+You could use self-generated certificates for evaluation and testing. Please run `gitea cert --host [HOST]` to generate a self signed certificate.
+
+If you are using Apache or nginx on the server, it's recommended to check the [reverse proxy guide](./reverse-proxies.md).
+
+To use Gitea's built-in HTTPS support, you must change your `app.ini` file:
+
+```ini
+[server]
+PROTOCOL  = https
+ROOT_URL  = https://git.example.com:3000/
+HTTP_PORT = 3000
+CERT_FILE = cert.pem
+KEY_FILE  = key.pem
+```
+
+Note that if your certificate is signed by a third party certificate authority (i.e. not self-signed), then cert.pem should contain the certificate chain. The server certificate must be the first entry in cert.pem, followed by the intermediaries in order (if any). The root certificate does not have to be included because the connecting client must already have it in order to establish the trust relationship.
+To learn more about the config values, please checkout the [Config Cheat Sheet](./config-cheat-sheet.md#server-server).
+
+For the `CERT_FILE` or `KEY_FILE` field, the file path is relative to the `GITEA_CUSTOM` environment variable when it is a relative path. It can be an absolute path as well.
+
+### Setting up HTTP redirection
+
+The Gitea server is only able to listen to one port; to redirect HTTP requests to the HTTPS port, you will need to enable the HTTP redirection service:
+
+```ini
+[server]
+REDIRECT_OTHER_PORT = true
+; Port the redirection service should listen on
+PORT_TO_REDIRECT = 3080
+```
+
+If you are using Docker, make sure that this port is configured in your `docker-compose.yml` file.
+
+## Using ACME (Default: Let's Encrypt)
+
+[ACME](https://tools.ietf.org/html/rfc8555) is a Certificate Authority standard protocol that allows you to automatically request and renew SSL/TLS certificates. [Let's Encrypt](https://letsencrypt.org/) is a free publicly trusted Certificate Authority server using this standard. Only `HTTP-01` and `TLS-ALPN-01` challenges are implemented. In order for ACME challenges to pass and verify your domain ownership, external traffic to the gitea domain on port `80` (`HTTP-01`) or port `443` (`TLS-ALPN-01`) has to be served by the gitea instance. Setting up [HTTP redirection](#setting-up-http-redirection) and port-forwards might be needed for external traffic to route correctly. Normal traffic to port `80` will otherwise be automatically redirected to HTTPS. **You must consent** to the ACME provider's terms of service (default Let's Encrypt's [terms of service](https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf)).
+
+Minimum setup using the default Let's Encrypt:
+
+```ini
+[server]
+PROTOCOL=https
+DOMAIN=git.example.com
+ENABLE_ACME=true
+ACME_ACCEPTTOS=true
+ACME_DIRECTORY=https
+;; Email can be omitted here and provided manually at first run, after which it is cached
+ACME_EMAIL=[email protected]
+```
+
+Minimum setup using a [smallstep CA](https://github.com/smallstep/certificates), refer to [their tutorial](https://smallstep.com/docs/tutorials/acme-challenge) for more information.
+
+```ini
+[server]
+PROTOCOL=https
+DOMAIN=git.example.com
+ENABLE_ACME=true
+ACME_ACCEPTTOS=true
+ACME_URL=https://ca.example.com/acme/acme/directory
+;; Can be omitted if using the system's trust is preferred
+;ACME_CA_ROOT=/path/to/root_ca.crt
+ACME_DIRECTORY=https
+ACME_EMAIL=[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).
+
+After that, enable HTTPS by following one of these guides:
+
+- [nginx](https://nginx.org/en/docs/http/configuring_https_servers.html)
+- [apache2/httpd](https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html)
+- [caddy](https://caddyserver.com/docs/tls)
+
+:::note
+Enabling HTTPS only at the proxy level is referred as [TLS Termination Proxy](https://en.wikipedia.org/wiki/TLS_termination_proxy). The proxy server accepts incoming TLS connections, decrypts the contents, and passes the now unencrypted contents to Gitea. This is normally fine as long as both the proxy and Gitea instances are either on the same machine, or on different machines within private network (with the proxy is exposed to outside network). If your Gitea instance is separated from your proxy over a public network, or if you want full end-to-end encryption, you can also [enable HTTPS support directly in Gitea using built-in server](#using-the-built-in-server) and forward the connections over HTTPS instead.
+:::

docs/administration/logging-config.md

@@ -0,0 +1,286 @@
+---
+date: "2019-04-02T17:06:00+01:00"
+slug: "logging-config"
+sidebar_position: 40
+aliases:
+  - /en-us/logging-configuration
+---
+
+# Logging Configuration
+
+The logging configuration of Gitea mainly consists of 3 types of components:
+
+- The `[log]` section for general configuration
+- `[log.<mode-name>]` sections for the configuration of different log writers to output logs, aka: "writer mode", the mode name is also used as "writer name".
+- The `[log]` section can also contain sub-logger configurations following the key schema `logger.<logger-name>.<CONFIG-KEY>`
+
+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).
+
+## The `[log]` section
+
+Configuration of logging facilities in Gitea happen in the `[log]` section and its subsections.
+
+In the top level `[log]` section the following configurations can be placed:
+
+- `ROOT_PATH`: (Default: **%(GITEA_WORK_DIR)/log**): Base path for log files
+- `MODE`: (Default: **console**) List of log outputs to use for the Default logger.
+- `LEVEL`: (Default: **Info**) Least severe log events to persist, case-insensitive. Possible values are: `Trace`, `Debug`, `Info`, `Warn`, `Error`, `Fatal`.
+- `STACKTRACE_LEVEL`: (Default: **None**) For this and more severe events the stacktrace will be printed upon getting logged.
+
+And it can contain the following sub-loggers:
+
+- `logger.router.MODE`: (Default: **,**): List of log outputs to use for the Router logger.
+- `logger.access.MODE`: (Default: **_empty_**)  List of log outputs to use for the Access logger. By default, the access logger is disabled.
+- `logger.xorm.MODE`: (Default: **,**) List of log outputs to use for the XORM logger.
+
+Setting a comma (`,`) to sub-logger's mode means making it use the default global `MODE`.
+
+## Quick samples
+
+### Default (empty) Configuration
+
+The empty configuration is equivalent to default:
+
+```ini
+[log]
+ROOT_PATH = %(GITEA_WORK_DIR)/log
+MODE = console
+LEVEL = Info
+STACKTRACE_LEVEL = None
+logger.router.MODE = ,
+logger.xorm.MODE = ,
+logger.access.MODE =
+
+; this is the config options of "console" mode (used by MODE=console above)
+[log.console]
+MODE = console
+FLAGS = stdflags
+PREFIX =
+COLORIZE = true
+```
+
+This is equivalent to sending all logs to the console, with default Golang log being sent to the console log too.
+
+This is only a sample, and it is the default, do not need to write it into your configuration file.
+
+### Disable Router logs and record some access logs to file
+
+The Router logger is disabled, the access logs (>=Warn) goes into `access.log`:
+
+```ini
+[log]
+logger.router.MODE =
+logger.access.MODE = access-file
+
+[log.access-file]
+MODE = file
+LEVEL = Warn
+FILE_NAME = access.log
+```
+
+### Set different log levels for different modes
+
+Default logs (>=Warn) goes into `gitea.log`, while Error logs goes into `file-error.log`:
+
+```ini
+[log]
+LEVEL = Warn
+MODE = file, file-error
+
+; by default, the "file" mode will record logs to %(log.ROOT_PATH)/gitea.log, so we don't need to set it
+; [log.file]
+; by default, the MODE (actually it's the output writer of this logger) is taken from the section name, so we don't need to set it either
+; MODE = file
+
+[log.file-error]
+MODE = file
+LEVEL = Error
+FILE_NAME = file-error.log
+```
+
+## Log outputs (mode and writer)
+
+Gitea provides the following log output writers:
+
+- `console` - Log to `stdout` (or `stderr` if it is set in the config)
+- `file` - Log to a file
+- `conn` - Log to a socket (network or unix)
+
+### Common configuration
+
+Certain configuration is common to all modes of log output:
+
+- `MODE` is the mode of the log output writer. It will default to the mode name in the ini section. Thus `[log.console]` will default to `MODE = console`.
+- `LEVEL` is the lowest level that this output will log.
+- `STACKTRACE_LEVEL` is the lowest level that this output will print a stacktrace.
+- `COLORIZE` will default to `true` for `console` as described, otherwise it will default to `false`.
+
+#### `EXPRESSION`
+
+`EXPRESSION` represents a regular expression that log events must match to be logged by the output writer.
+Either the log message, (with colors removed), must match or the `longfilename:linenumber:functionname` must match.
+NB: the whole message or string doesn't need to completely match.
+
+Please note this expression will be run in the writer's goroutine but not the logging event goroutine.
+
+#### `FLAGS`
+
+`FLAGS` represents the preceding logging context information that is
+printed before each message. It is a comma-separated string set. The order of values does not matter.
+
+It defaults to `stdflags` (= `date,time,medfile,shortfuncname,levelinitial`)
+
+Possible values are:
+
+- `none` or `,` - No flags.
+- `date` - the date in the local time zone: `2009/01/23`.
+- `time` - the time in the local time zone: `01:23:23`.
+- `microseconds` - microsecond resolution: `01:23:23.123123`. Assumes  time.
+- `longfile` - full file name and line number: `/a/b/c/d.go:23`.
+- `shortfile` - final file name element and line number: `d.go:23`.
+- `funcname` - function name of the caller: `runtime.Caller()`.
+- `shortfuncname` - last part of the function name. Overrides `funcname`.
+- `utc` - if date or time is set, use UTC rather than the local time zone.
+- `levelinitial` - initial character of the provided level in brackets eg. `[I]` for info.
+- `level` - level in brackets `[INFO]`.
+- `gopid` - the Goroutine-PID of the context.
+- `medfile` - last 20 characters of the filename - equivalent to `shortfile,longfile`.
+- `stdflags` - equivalent to `date,time,medfile,shortfuncname,levelinitial`.
+
+### Console mode
+
+In this mode the logger will forward log messages to the stdout and
+stderr streams attached to the Gitea process.
+
+For loggers in console mode, `COLORIZE` will default to `true` if not
+on windows, or the Windows terminal can be set into ANSI mode or is a
+cygwin or Msys pipe.
+
+Settings:
+
+- `STDERR`: **false**: Whether the logger should print to `stderr` instead of `stdout`.
+
+### File mode
+
+In this mode the logger will save log messages to a file.
+
+Settings:
+
+- `FILE_NAME`: The file to write the log events to, relative to `ROOT_PATH`, Default to `%(ROOT_PATH)/gitea.log`. Exception: access log will default to `%(ROOT_PATH)/access.log`.
+- `MAX_SIZE_SHIFT`: **28**: Maximum size shift of a single file. 28 represents 256Mb. For details see below.
+- `LOG_ROTATE` **true**: Whether to rotate the log files. TODO: if false, will it delete instead on daily rotate, or do nothing?.
+- `DAILY_ROTATE`: **true**: Whether to rotate logs daily.
+- `MAX_DAYS`: **7**: Delete rotated log files after this number of days.
+- `COMPRESS`: **true**: Whether to compress old log files by default with gzip.
+- `COMPRESSION_LEVEL`: **-1**: Compression level. For details see below.
+
+`MAX_SIZE_SHIFT` defines the maximum size of a file by left shifting 1 the given number of times (`1 << x`).
+The exact behavior at the time of v1.17.3 can be seen [here](https://github.com/go-gitea/gitea/blob/v1.17.3/modules/setting/log.go#L185).
+
+The useful values of `COMPRESSION_LEVEL` are from 1 (best speed) to 9 (best compression). [DefaultCompression](https://pkg.go.dev/compress/gzip#pkg-constants) (-1) and [HuffmanOnly](https://pkg.go.dev/compress/flate#HuffmanOnly) (-2) can also be chosen.
+Beware that better compression might come with higher resource usage.
+
+### Conn mode
+
+In this mode the logger will send log messages over a network socket.
+
+Settings:
+
+- `ADDR`: **:7020**: Sets the address to connect to.
+- `PROTOCOL`: **tcp**: Set the protocol, either "tcp", "unix" or "udp".
+- `RECONNECT`: **false**: Try to reconnect when connection is lost.
+- `RECONNECT_ON_MSG`: **false**: Reconnect host for every single message.
+
+### The "Router" logger
+
+The Router logger logs the following message types when Gitea's route handlers work:
+
+- `started` messages will be logged at TRACE level
+- `polling`/`completed` routers will be logged at INFO. Exception: "/assets" static resource requests are also logged at TRACE.
+- `slow` routers will be logged at WARN
+- `failed` routers will be logged at WARN
+
+### The "XORM" logger
+
+To make XORM outputs SQL logs, the `LOG_SQL` in `[database]` section should also be set to `true`.
+
+### The "Access" logger
+
+The Access logger is a new logger since Gitea 1.9. It provides a NCSA
+Common Log compliant log format. It's highly configurable but caution
+should be taken when changing its template. The main benefit of this
+logger is that Gitea can now log accesses in a standard log format so
+standard tools may be used.
+
+You can enable this logger using `logger.access.MODE = ...`.
+
+If desired the format of the Access logger can be changed by changing
+the value of the `ACCESS_LOG_TEMPLATE`.
+
+Please note, the access logger will log at `INFO` level, setting the
+`LEVEL` of this logger to `WARN` or above will result in no access logs.
+
+#### The ACCESS_LOG_TEMPLATE
+
+This value represents a go template. Its default value is
+
+```tmpl
+{{.Ctx.RemoteHost}} - {{.Identity}} {{.Start.Format "[02/Jan/2006:15:04:05 -0700]" }} "{{.Ctx.Req.Method}} {{.Ctx.Req.URL.RequestURI}} {{.Ctx.Req.Proto}}" {{.ResponseWriter.Status}} {{.ResponseWriter.Size}} "{{.Ctx.Req.Referer}}" "{{.Ctx.Req.UserAgent}}"`
+```
+
+The template is passed following options:
+
+- `Ctx` is the `context.Context`
+- `Identity` is the `SignedUserName` or `"-"` if the user is not logged in
+- `Start` is the start time of the request
+- `ResponseWriter` is the `http.ResponseWriter`
+
+Caution must be taken when changing this template as it runs outside of
+the standard panic recovery trap. The template should also be as simple
+as it runs for every request.
+
+## Releasing-and-Reopening, Pausing and Resuming logging
+
+If you are running on Unix you may wish to release-and-reopen logs in order to use `logrotate` or other tools.
+It is possible force Gitea to release and reopen it's logging files and connections by sending `SIGUSR1` to the
+running process, or running `gitea manager logging release-and-reopen`.
+
+Alternatively, you may wish to pause and resume logging - this can be accomplished through the use of the
+`gitea manager logging pause` and `gitea manager logging resume` commands. Please note that whilst logging
+is paused log events below INFO level will not be stored and only a limited number of events will be stored.
+Logging may block, albeit temporarily, slowing Gitea considerably whilst paused - therefore it is
+recommended that pausing only done for a very short period of time.
+
+## Adding and removing logging whilst Gitea is running
+
+It is possible to add and remove logging whilst Gitea is running using the `gitea manager logging add` and `remove` subcommands.
+This functionality can only adjust running log systems and cannot be used to start the access or router loggers if they
+were not already initialized. If you wish to start these systems you are advised to adjust the app.ini and (gracefully) restart
+the Gitea service.
+
+The main intention of these commands is to easily add a temporary logger to investigate problems on running systems where a restart
+may cause the issue to disappear.
+
+## Using `logrotate` instead of built-in log rotation
+
+Gitea includes built-in log rotation, which should be enough for most deployments. However, if you instead want to use the `logrotate` utility:
+
+- Disable built-in log rotation by setting `LOG_ROTATE` to `false` in your `app.ini`.
+- Install `logrotate`.
+- Configure `logrotate` to match your deployment requirements, see `man 8 logrotate` for configuration syntax details.
+  In the `postrotate/endscript` block send Gitea a `USR1` signal via `kill -USR1` or `kill -10` to the `gitea` process itself,
+  or run `gitea manager logging release-and-reopen` (with the appropriate environment).
+  Ensure that your configurations apply to all files emitted by Gitea loggers as described in the above sections.
+- Always do `logrotate /etc/logrotate.conf --debug` to test your configurations.
+- If you are using docker and are running from outside the container you can use
+  `docker exec -u $OS_USER $CONTAINER_NAME sh -c 'gitea manager logging release-and-reopen'`
+  or `docker exec $CONTAINER_NAME sh -c '/bin/s6-svc -1 /etc/s6/gitea/'` or send `USR1` directly to the Gitea process itself.
+
+The next `logrotate` jobs will include your configurations, so no restart is needed.
+You can also immediately reload `logrotate` with `logrotate /etc/logrotate.conf --force`.

docs/administration/mail-templates.md

@@ -0,0 +1,268 @@
+---
+date: "2019-10-23T17:00:00-03:00"
+slug: "mail-templates"
+sidebar_position: 45
+aliases:
+  - /en-us/mail-templates
+---
+
+# Mail templates
+
+To craft the e-mail subject and contents for certain operations, Gitea can be customized by using templates. The templates
+for these functions are located under the [`custom` directory](../administration/customizing-gitea.md).
+Gitea has an internal template that serves as default in case there's no custom alternative.
+
+Custom templates are loaded when Gitea starts. Changes made to them are not recognized until Gitea is restarted again.
+
+## Mail notifications supporting templates
+
+Currently, the following notification events make use of templates:
+
+| Action name | Usage                                                                                                        |
+| ----------- | ------------------------------------------------------------------------------------------------------------ |
+| `new`       | A new issue or pull request was created.                                                                     |
+| `comment`   | A new comment was created in an existing issue or pull request.                                              |
+| `close`     | An issue or pull request was closed.                                                                         |
+| `reopen`    | An issue or pull request was reopened.                                                                       |
+| `review`    | The head comment of a review in a pull request.                                                              |
+| `approve`   | The head comment of a approving review for a pull request.                                                   |
+| `reject`    | The head comment of a review requesting changes for a pull request.                                          |
+| `code`      | A single comment on the code of a pull request.                                                              |
+| `assigned`  | User was assigned to an issue or pull request.                                                               |
+| `default`   | Any action not included in the above categories, or when the corresponding category template is not present. |
+
+The path for the template of a particular message type is:
+
+```sh
+custom/templates/mail/{action type}/{action name}.tmpl
+```
+
+Where `{action type}` is one of `issue` or `pull` (for pull requests), and `{action name}` is one of the names listed above.
+
+For example, the specific template for a mail regarding a comment in a pull request is:
+
+```sh
+custom/templates/mail/pull/comment.tmpl
+```
+
+However, creating templates for each and every action type/name combination is not required.
+A fallback system is used to choose the appropriate template for an event. The _first existing_
+template on this list is used:
+
+- The specific template for the desired **action type** and **action name**.
+- The template for action type `issue` and the desired **action name**.
+- The template for the desired **action type**, action name `default`.
+- The template for action type `issue`, action name `default`.
+
+The only mandatory template is action type `issue`, action name `default`, which is already embedded in Gitea
+unless it's overridden by the user in the `custom` directory.
+
+## Template syntax
+
+Mail templates are UTF-8 encoded text files that need to follow one of the following formats:
+
+```
+Text and macros for the subject line
+------------
+Text and macros for the mail body
+```
+
+or
+
+```
+Text and macros for the mail body
+```
+
+Specifying a _subject_ section is optional (and therefore also the dash line separator). When used, the separator between
+_subject_ and _mail body_ templates requires at least three dashes; no other characters are allowed in the separator line.
+
+_Subject_ and _mail body_ are parsed by [Golang's template engine](https://go.dev/pkg/text/template/) and
+are provided with a _metadata context_ assembled for each notification. The context contains the following elements:
+
+| Name               | Type             | Available     | Usage                                                                                                                                                                                                                                             |
+| ------------------ | ---------------- | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `.FallbackSubject` | string           | Always        | A default subject line. See Below.                                                                                                                                                                                                                |
+| `.Subject`         | string           | Only in body  | The _subject_, once resolved.                                                                                                                                                                                                                     |
+| `.Body`            | string           | Always        | The message of the issue, pull request or comment, parsed from Markdown into HTML and sanitized. Do not confuse with the _mail body_.                                                                                                             |
+| `.Link`            | string           | Always        | The address of the originating issue, pull request or comment.                                                                                                                                                                                    |
+| `.Issue`           | models.Issue     | Always        | The issue (or pull request) originating the notification. To get data specific to a pull request (e.g. `HasMerged`), `.Issue.PullRequest` can be used, but care should be taken as this field will be `nil` if the issue is _not_ a pull request. |
+| `.Comment`         | models.Comment   | If applicable | If the notification is from a comment added to an issue or pull request, this will contain the information about the comment.                                                                                                                     |
+| `.IsPull`          | bool             | Always        | `true` if the mail notification is associated with a pull request (i.e. `.Issue.PullRequest` is not `nil`).                                                                                                                                       |
+| `.Repo`            | string           | Always        | Name of the repository, including owner name (e.g. `mike/stuff`)                                                                                                                                                                                  |
+| `.User`            | models.User      | Always        | Owner of the repository from which the event originated. To get the user name (e.g. `mike`),`.User.Name` can be used.                                                                                                                             |
+| `.Doer`            | models.User      | Always        | User that executed the action triggering the notification event. To get the user name (e.g. `rhonda`), `.Doer.Name` can be used.                                                                                                                  |
+| `.IsMention`       | bool             | Always        | `true` if this notification was only generated because the user was mentioned in the comment, while not being subscribed to the source. It will be `false` if the recipient was subscribed to the issue or repository.                            |
+| `.SubjectPrefix`   | string           | Always        | `Re: ` if the notification is about other than issue or pull request creation; otherwise an empty string.                                                                                                                                         |
+| `.ActionType`      | string           | Always        | `"issue"` or `"pull"`. Will correspond to the actual _action type_ independently of which template was selected.                                                                                                                                  |
+| `.ActionName`      | string           | Always        | It will be one of the action types described above (`new`, `comment`, etc.), and will correspond to the actual _action name_ independently of which template was selected.                                                                        |
+| `.ReviewComments`  | []models.Comment | Always        | List of code comments in a review. The comment text will be in `.RenderedContent` and the referenced code will be in `.Patch`.                                                                                                                    |
+
+All names are case sensitive.
+
+### The _subject_ part of the template
+
+The template engine used for the mail _subject_ is golang's [`text/template`](https://go.dev/pkg/text/template/).
+Please refer to the linked documentation for details about its syntax.
+
+The _subject_ is built using the following steps:
+
+- A template is selected according to the type of notification and to what templates are present.
+- The template is parsed and resolved (e.g. `{{.Issue.Index}}` is converted to the number of the issue
+  or pull request).
+- All space-like characters (e.g. `TAB`, `LF`, etc.) are converted to normal spaces.
+- All leading, trailing and redundant spaces are removed.
+- The string is truncated to its first 256 runes (characters).
+
+If the end result is an empty string, **or** no subject template was available (i.e. the selected template
+did not include a subject part), Gitea's **internal default** will be used.
+
+The internal default (fallback) subject is the equivalent of:
+
+```sh
+{{.SubjectPrefix}}[{{.Repo}}] {{.Issue.Title}} (#{{.Issue.Index}})
+```
+
+For example: `Re: [mike/stuff] New color palette (#38)`
+
+Gitea's default subject can also be found in the template _metadata_ as `.FallbackSubject` from any of
+the two templates, even if a valid subject template is present.
+
+### The _mail body_ part of the template
+
+The template engine used for the _mail body_ is golang's [`html/template`](https://go.dev/pkg/html/template/).
+Please refer to the linked documentation for details about its syntax.
+
+The _mail body_ is parsed after the mail subject, so there is an additional _metadata_ field which is
+the actual rendered subject, after all considerations.
+
+The expected result is HTML (including structural elements like`<html>`, `<body>`, etc.). Styling
+through `<style>` blocks, `class` and `style` attributes is possible. However, `html/template`
+does some [automatic escaping](https://go.dev/pkg/html/template/#hdr-Contexts) that should be considered.
+
+Attachments (such as images or external style sheets) are not supported. However, other templates can
+be referenced too, for example to provide the contents of a `<style>` element in a centralized fashion.
+The external template must be placed under `custom/mail` and referenced relative to that directory.
+For example, `custom/mail/styles/base.tmpl` can be included using `{{template styles/base}}`.
+
+The mail is sent with `Content-Type: multipart/alternative`, so the body is sent in both HTML
+and text formats. The latter is obtained by stripping the HTML markup.
+
+## Troubleshooting
+
+How a mail is rendered is directly dependent on the capabilities of the mail application. Many mail
+clients don't even support HTML, so they show the text version included in the generated mail.
+
+If the template fails to render, it will be noticed only at the moment the mail is sent.
+A default subject is used if the subject template fails, and whatever was rendered successfully
+from the _mail body_ is used, disregarding the rest.
+
+Please check [Gitea's logs](../administration/logging-config.md) for error messages in case of trouble.
+
+## Example
+
+`custom/templates/mail/issue/default.tmpl`:
+
+```html
+[{{.Repo}}] @{{.Doer.Name}}
+{{if eq .ActionName "new"}}
+    created
+{{else if eq .ActionName "comment"}}
+    commented on
+{{else if eq .ActionName "close"}}
+    closed
+{{else if eq .ActionName "reopen"}}
+    reopened
+{{else}}
+    updated
+{{end}}
+{{if eq .ActionType "issue"}}
+    issue
+{{else}}
+    pull request
+{{end}}
+#{{.Issue.Index}}: {{.Issue.Title}}
+------------
+<!DOCTYPE html>
+<html>
+<head>
+    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+    <title>{{.Subject}}</title>
+</head>
+
+<body>
+    {{if .IsMention}}
+    <p>
+        You are receiving this because @{{.Doer.Name}} mentioned you.
+    </p>
+    {{end}}
+    <p>
+        <p>
+        <a href="{{AppUrl}}/{{.Doer.LowerName}}">@{{.Doer.Name}}</a>
+        {{if not (eq .Doer.FullName "")}}
+            ({{.Doer.FullName}})
+        {{end}}
+        {{if eq .ActionName "new"}}
+            created
+        {{else if eq .ActionName "close"}}
+            closed
+        {{else if eq .ActionName "reopen"}}
+            reopened
+        {{else}}
+            updated
+        {{end}}
+        <a href="{{.Link}}">{{.Repo}}#{{.Issue.Index}}</a>.
+        </p>
+        {{if not (eq .Body "")}}
+            <h3>Message content</h3>
+            <hr>
+            {{.Body}}
+        {{end}}
+    </p>
+    <hr>
+    <p>
+        <a href="{{.Link}}">View it on Gitea</a>.
+    </p>
+</body>
+</html>
+```
+
+This template produces something along these lines:
+
+### Subject
+
+> [mike/stuff] @rhonda commented on pull request #38: New color palette
+
+### Mail body
+
+> [@rhonda](#) (Rhonda Myers) updated [mike/stuff#38](#).
+>
+> #### Message content
+>
+> \_********************************\_********************************
+>
+> Mike, I think we should tone down the blues a little.
+> \_********************************\_********************************
+>
+> [View it on Gitea](#).
+
+## Advanced
+
+The template system contains several functions that can be used to further process and format
+the messages. Here's a list of some of them:
+
+| Name             | Parameters  | Available | Usage                                                               |
+| ---------------- | ----------- | --------- | ------------------------------------------------------------------- |
+| `AppUrl`         | -           | Any       | Gitea's URL                                                         |
+| `AppName`        | -           | Any       | Set from `app.ini`, usually "Gitea"                                 |
+| `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          |
+
+These are _functions_, not metadata, so they have to be used:
+
+```html
+Like this:         {{SanitizeHTML "Escape<my>text"}}
+Or this:           {{"Escape<my>text" | SanitizeHTML}}
+Or this:           {{AppUrl}}
+But not like this: {{.AppUrl}}
+```

docs/administration/repo-indexer.md

@@ -1,18 +1,9 @@
 ---
 date: "2019-09-06T01:35:00-03:00"
-title: "Repository indexer"
 slug: "repo-indexer"
 sidebar_position: 45
-toc: false
-draft: false
 aliases:
   - /en-us/repo-indexer
-menu:
-  sidebar:
-    parent: "administration"
-    name: "Repository indexer"
-    sidebar_position: 45
-    identifier: "repo-indexer"
 ---
 
 # Repository indexer
@@ -25,7 +16,7 @@ Better code search support could be achieved by setting up the repository indexe
 
 ## Setting up the repository indexer
 
-Gitea can search through the files of the repositories by enabling this function in your [`app.ini`](administration/config-cheat-sheet.md):
+Gitea can search through the files of the repositories by enabling this function in your [`app.ini`](../administration/config-cheat-sheet.md):
 
 ```ini
 [indexer]
@@ -41,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

@@ -0,0 +1,461 @@
+---
+date: "2018-05-22T11:00:00+00:00"
+slug: "reverse-proxies"
+sidebar_position: 16
+aliases:
+  - /en-us/reverse-proxies
+---
+
+# Reverse Proxies
+
+## General configuration
+
+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-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
+
+Usually it's **not recommended** to put Gitea in a sub-path, it's not widely used and may have some issues in rare cases.
+
+To make Gitea work with a sub-path (eg: `https://common.example.com/gitea/`),
+there are some extra requirements besides the general configuration above:
+
+1. Use `[server] ROOT_URL = https://common.example.com/gitea/` in your `app.ini` file.
+2. Make the reverse-proxy pass `https://common.example.com/gitea/foo` to `http://gitea:3000/foo`.
+3. The container registry requires a fixed sub-path `/v2` at the root level which must be configured:
+   - Make the reverse-proxy pass `https://common.example.com/v2` to `http://gitea:3000/v2`.
+   - Make sure the URI and headers are also correctly passed (see the general configuration above).
+
+## Nginx
+
+If you want Nginx to serve your Gitea instance, add the following `server` section to the `http` section of `nginx.conf`.
+
+Make sure `client_max_body_size` is large enough, otherwise there would be "413 Request Entity Too Large" error when uploading large files.
+
+```nginx
+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;
+        proxy_set_header X-Real-IP $remote_addr;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header X-Forwarded-Proto $scheme;
+    }
+}
+```
+
+## Nginx with a sub-path
+
+In case you already have a site, and you want Gitea to share the domain name,
+you can setup Nginx to serve Gitea under a sub-path by adding the following `server` section
+into the `http` section of `nginx.conf`:
+
+```nginx
+server {
+    ...
+    location ~ ^/(gitea|v2)($|/) {
+        client_max_body_size 512M;
+
+        # make nginx use unescaped URI, keep "%2F" as-is, remove the "/gitea" sub-path prefix, pass "/v2" as-is.
+        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;
+        proxy_set_header Upgrade $http_upgrade;
+        proxy_set_header Host $host;
+        proxy_set_header X-Real-IP $remote_addr;
+        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+        proxy_set_header X-Forwarded-Proto $scheme;
+    }
+}
+```
+
+Then you **MUST** set something like `[server] ROOT_URL = http://git.example.com/gitea/` correctly in your configuration.
+
+## Nginx 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.
+
+Nginx can serve static resources directly and proxy only the dynamic requests to Gitea.
+Nginx is optimized for serving static content, while the proxying of large responses might be the opposite of that
+(see [https://serverfault.com/q/587386](https://serverfault.com/q/587386)).
+
+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.
+
+```nginx
+server {
+    listen 80;
+    server_name git.example.com;
+
+    location /_/static/assets/ {
+        alias /path/to/gitea/public/;
+    }
+
+    location / {
+        # other directives, see the "Nginx" config section above
+        proxy_pass http://localhost:3000;
+    }
+}
+```
+
+### Two nodes and two domains
+
+Set `[server] STATIC_URL_PREFIX = http://cdn.example.com/gitea` in your configuration.
+
+```nginx
+# application server running Gitea
+server {
+    listen 80;
+    server_name git.example.com;
+
+    location / {
+        # other directives, see the "Nginx" config section above
+        proxy_pass http://localhost:3000;
+    }
+}
+```
+
+```nginx
+# static content delivery server
+server {
+    listen 80;
+    server_name cdn.example.com;
+
+    location /gitea/ {
+        alias /path/to/gitea/public/;
+    }
+
+    location / {
+        return 404;
+    }
+}
+```
+
+## 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):
+
+```apacheconf
+<VirtualHost *:80>
+    ...
+    ProxyPreserveHost On
+    ProxyRequests off
+    AllowEncodedSlashes NoDecode
+    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.
+
+## Apache HTTPD with a sub-path
+
+In case you already have a site, and you want Gitea to share the domain name, you can setup Apache HTTPD to serve Gitea under a sub-path by adding the following to you Apache HTTPD configuration (usually located at `/etc/apache2/httpd.conf` in Ubuntu):
+
+```apacheconf
+<VirtualHost *:80>
+    ...
+    <Proxy *>
+         Order allow,deny
+         Allow from all
+    </Proxy>
+    AllowEncodedSlashes NoDecode
+    # Note: no trailing slash after either /git or port
+    ProxyPass /git http://localhost:3000 nocanon upgrade=websocket
+    ProxyPreserveHost On
+    RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
+</VirtualHost>
+```
+
+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`. `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
+
+If you want Caddy to serve your Gitea instance, you can add the following server block to your Caddyfile:
+
+```
+git.example.com {
+    reverse_proxy localhost:3000
+}
+```
+
+## Caddy with a sub-path
+
+In case you already have a site, and you want Gitea to share the domain name, you can setup Caddy to serve Gitea under a sub-path by adding the following to your server block in your Caddyfile:
+
+```
+git.example.com {
+    route /git/* {
+        uri strip_prefix /git
+        reverse_proxy localhost:3000
+    }
+}
+```
+
+Then set `[server] ROOT_URL = http://git.example.com/git/` in your configuration.
+
+## IIS
+
+If you wish to run Gitea with IIS. You will need to setup IIS with URL Rewrite as reverse proxy.
+
+1. Setup an empty website in IIS, named let's say, `Gitea Proxy`.
+2. Follow the first two steps in [Microsoft's Technical Community Guide to Setup IIS with URL Rewrite](https://techcommunity.microsoft.com/t5/iis-support-blog/setup-iis-with-url-rewrite-as-a-reverse-proxy-for-real-world/ba-p/846222#M343). That is:
+
+- 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
+<?xml version="1.0" encoding="UTF-8"?>
+<configuration>
+    <system.web>
+        <httpRuntime requestPathInvalidCharacters="" />
+    </system.web>
+    <system.webServer>
+        <security>
+          <requestFiltering>
+            <hiddenSegments>
+              <clear />
+            </hiddenSegments>
+            <denyUrlSequences>
+              <clear />
+            </denyUrlSequences>
+            <fileExtensions allowUnlisted="true">
+              <clear />
+            </fileExtensions>
+          </requestFiltering>
+        </security>
+        <rewrite>
+            <rules useOriginalURLEncoding="false">
+                <rule name="ReverseProxyInboundRule1" stopProcessing="true">
+                    <match url="(.*)" />
+                    <action type="Rewrite" url="http://127.0.0.1:3000{UNENCODED_URL}" />
+                    <serverVariables>
+                        <set name="HTTP_X_ORIGINAL_ACCEPT_ENCODING" value="HTTP_ACCEPT_ENCODING" />
+                        <set name="HTTP_ACCEPT_ENCODING" value="" />
+                    </serverVariables>
+                </rule>
+            </rules>
+            <outboundRules>
+                <rule name="ReverseProxyOutboundRule1" preCondition="ResponseIsHtml1">
+                    <!-- set the pattern correctly here - if you only want to accept http or https -->
+                    <!-- change the pattern and the action value as appropriate -->
+                    <match filterByTags="A, Form, Img" pattern="^http(s)?://127.0.0.1:3000/(.*)" />
+                    <action type="Rewrite" value="http{R:1}://git.example.com/{R:2}" />
+                </rule>
+                <rule name="RestoreAcceptEncoding" preCondition="NeedsRestoringAcceptEncoding">
+                    <match serverVariable="HTTP_ACCEPT_ENCODING" pattern="^(.*)" />
+                    <action type="Rewrite" value="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" />
+                </rule>
+                <preConditions>
+                    <preCondition name="ResponseIsHtml1">
+                        <add input="{RESPONSE_CONTENT_TYPE}" pattern="^text/html" />
+                    </preCondition>
+                    <preCondition name="NeedsRestoringAcceptEncoding">
+                        <add input="{HTTP_X_ORIGINAL_ACCEPT_ENCODING}" pattern=".+" />
+                    </preCondition>
+                </preConditions>
+            </outboundRules>
+        </rewrite>
+        <urlCompression doDynamicCompression="true" />
+        <handlers>
+          <clear />
+          <add name="StaticFile" path="*" verb="*" modules="StaticFileModule,DefaultDocumentModule,DirectoryListingModule" resourceType="Either" requireAccess="Read" />
+        </handlers>
+        <!-- Map all extensions to the same MIME type, so all files can be
+               downloaded. -->
+        <staticContent>
+          <clear />
+          <mimeMap fileExtension="*" mimeType="application/octet-stream" />
+        </staticContent>
+    </system.webServer>
+</configuration>
+```
+
+## HAProxy
+
+If you want HAProxy to serve your Gitea instance, you can add the following to your HAProxy configuration
+
+add an acl in the frontend section to redirect calls to gitea.example.com to the correct backend
+
+```
+frontend http-in
+    ...
+    acl acl_gitea hdr(host) -i gitea.example.com
+    use_backend gitea if acl_gitea
+    ...
+```
+
+add the previously defined backend section
+
+```
+backend gitea
+    server localhost:3000 check
+```
+
+If you redirect the http content to https, the configuration work the same way, just remember that the connection between HAProxy and Gitea will be done via http so you do not have to enable https in Gitea's configuration.
+
+## HAProxy with a sub-path
+
+In case you already have a site, and you want Gitea to share the domain name, you can setup HAProxy to serve Gitea under a sub-path by adding the following to you HAProxy configuration:
+
+```
+frontend http-in
+    ...
+    acl acl_gitea path_beg /gitea
+    use_backend gitea if acl_gitea
+    ...
+```
+
+With that configuration http://example.com/gitea/ will redirect to your Gitea instance.
+
+then for the backend section
+
+```
+backend gitea
+    http-request replace-path /gitea\/?(.*) \/\1
+    server localhost:3000 check
+```
+
+The added http-request will automatically add a trailing slash if needed and internally remove /gitea from the path to allow it to work correctly with Gitea by setting properly http://example.com/gitea as the root.
+
+Then you **MUST** set something like `[server] ROOT_URL = http://example.com/gitea/` correctly in your configuration.
+
+## Traefik
+
+If you want traefik to serve your Gitea instance, you can add the following label section to your `docker-compose.yaml` (Assuming the provider is docker).
+
+```yaml
+gitea:
+  image: docker.io/gitea/gitea
+  ...
+  labels:
+    - "traefik.enable=true"
+    - "traefik.http.routers.gitea.rule=Host(`example.com`)"
+    - "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000"
+```
+
+This config assumes that you are handling HTTPS on the traefik side and using HTTP between Gitea and traefik.
+
+## Traefik with a sub-path
+
+In case you already have a site, and you want Gitea to share the domain name, you can setup Traefik to serve Gitea under a sub-path by adding the following to your `docker-compose.yaml` (Assuming the provider is docker) :
+
+```yaml
+gitea:
+  image: docker.io/gitea/gitea
+  ...
+  labels:
+    - "traefik.enable=true"
+    - "traefik.http.routers.gitea.rule=Host(`example.com`) && PathPrefix(`/gitea`)"
+    - "traefik.http.services.gitea-websecure.loadbalancer.server.port=3000"
+    - "traefik.http.middlewares.gitea-stripprefix.stripprefix.prefixes=/gitea"
+    - "traefik.http.routers.gitea.middlewares=gitea-stripprefix"
+```
+
+This config assumes that you are handling HTTPS on the traefik side and using HTTP between Gitea and traefik.
+
+Then you **MUST** set something like `[server] ROOT_URL = http://example.com/gitea/` correctly in your configuration.

docs/administration/search-engines-indexation.md

@@ -1,21 +1,12 @@
 ---
 date: "2019-12-31T13:55:00+05:00"
-title: "Search Engines Indexation"
 slug: "search-engines-indexation"
 sidebar_position: 60
-toc: false
-draft: false
 aliases:
   - /en-us/search-engines-indexation
-menu:
-  sidebar:
-    parent: "administration"
-    name: "Search Engines Indexation"
-    sidebar_position: 60
-    identifier: "search-engines-indexation"
 ---
 
-# Search engines indexation of your Gitea installation
+# Search Engines Indexation
 
 By default your Gitea installation will be indexed by search engines.
 If you don't want your repository to be visible for search engines read further.
@@ -23,7 +14,7 @@ If you don't want your repository to be visible for search engines read further.
 ## Block search engines indexation using robots.txt
 
 To make Gitea serve a custom `robots.txt` (default: empty 404) for top level installations,
-create a file with path `public/robots.txt` in the [`custom` folder or `CustomPath`](administration/customizing-gitea.md)
+create a file with path `public/robots.txt` in the [`custom` folder or `CustomPath`](../administration/customizing-gitea.md)
 
 Examples on how to configure the `robots.txt` can be found at [https://moz.com/learn/seo/robotstxt](https://moz.com/learn/seo/robotstxt).
 

docs/administration/signing.md

@@ -0,0 +1,212 @@
+---
+date: "2019-08-17T10:20:00+01:00"
+slug: "signing"
+sidebar_position: 50
+aliases:
+  - /en-us/signing
+---
+
+# GPG/SSH Commit Signatures
+
+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.
+
+A commit will be marked with a grey unlocked icon if no key can be
+found to verify it. If a commit is marked with a red unlocked icon,
+it is reported to be signed with a key with an id.
+
+:::note
+The signer of a commit does not have to be an author or
+committer of a commit.
+:::
+
+## Automatic Signing
+
+There are a number of places where Gitea will generate commits itself:
+
+- Repository Initialisation
+- Wiki Changes
+- CRUD actions using the editor or the API
+- Merges from Pull Requests
+
+Depending on configuration and server trust you may want Gitea to
+sign these commits.
+
+## Installing and generating a GPG key for Gitea
+
+It is up to a server administrator to determine how best to install
+a signing key. Gitea generates all its commits using the server `git`
+command at present - and therefore the server `gpg` will be used for
+signing (if configured.) Administrators should review best-practices
+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
+`[repository.signing]` section of `app.ini`:
+
+```ini
+...
+[repository.signing]
+SIGNING_KEY = default
+SIGNING_NAME =
+SIGNING_EMAIL =
+INITIAL_COMMIT = always
+CRUD_ACTIONS = pubkey, twofa, parentsigned
+WIKI = never
+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 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
+of the `user.signingkey`, `user.name` and `user.email` as appropriate.
+
+By adjusting Git's `config` file within Gitea's
+repositories, `SIGNING_KEY=default` could be used to provide different
+signing keys on a per-repository basis. However, this is clearly not an
+ideal UI and therefore subject to change.
+
+:::warning
+**Since 1.17**, Gitea runs git in its own home directory `[git].HOME_PATH` (default to `%(APP_DATA_PATH)/home`)
+and uses its own config `{[git].HOME_PATH}/.gitconfig`.
+
+If you have your own customized git config for Gitea, you should set these configs in system git config (aka `/etc/gitconfig`)
+or the Gitea internal git config `{[git].HOME_PATH}/.gitconfig`.
+
+Related home files for git command (like `.gnupg`) should also be put in Gitea's git home directory `[git].HOME_PATH`.
+
+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
+when creating a repository. The possible values are:
+
+- `never`: Never sign
+- `pubkey`: Only sign if the user has a public key
+- `twofa`: Only sign if the user logs in with two factor authentication
+- `always`: Always sign
+
+Options other than `never` and `always` can be combined as a comma
+separated list. The commit will be signed if all selected options are true.
+
+### `WIKI`
+
+This options determines if Gitea should sign commits to the Wiki.
+The possible values are:
+
+- `never`: Never sign
+- `pubkey`: Only sign if the user has a public key
+- `twofa`: Only sign if the user logs in with two-factor authentication
+- `parentsigned`: Only sign if the parent commit is signed.
+- `always`: Always sign
+
+Options other than `never` and `always` can be combined as a comma
+separated list. The commit will be signed if all selected options are true.
+
+### `CRUD_ACTIONS`
+
+This option determines if Gitea should sign commits from the web
+editor or API CRUD actions. The possible values are:
+
+- `never`: Never sign
+- `pubkey`: Only sign if the user has a public key
+- `twofa`: Only sign if the user logs in with two-factor authentication
+- `parentsigned`: Only sign if the parent commit is signed.
+- `always`: Always sign
+
+Options other than `never` and `always` can be combined as a comma
+separated list. The change will be signed if all selected options are true.
+
+### `MERGES`
+
+This option determines if Gitea should sign merge commits from PRs.
+The possible options are:
+
+- `never`: Never sign
+- `pubkey`: Only sign if the user has a public key
+- `twofa`: Only sign if the user logs in with two-factor authentication
+- `basesigned`: Only sign if the parent commit in the base repo is signed.
+- `headsigned`: Only sign if the head commit in the head branch is signed.
+- `commitssigned`: Only sign if all the commits in the head branch to the merge point are signed.
+- `approved`: Only sign approved merges to a protected branch.
+- `always`: Always sign
+
+Options other than `never` and `always` can be combined as a comma
+separated list. The merge will be signed if all selected options are true.
+
+## Obtaining the Public Key of the Signing Key
+
+The public key used to sign Gitea's commits can be obtained from the API at:
+
+```sh
+/api/v1/signing-key.gpg
+```
+
+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

@@ -0,0 +1,163 @@
+---
+date: "2018-06-24:00:00+02:00"
+slug: "api-usage"
+sidebar_position: 40
+aliases:
+  - /en-us/api-usage
+---
+
+# API Usage
+
+## Enabling/configuring API access
+
+By default, `ENABLE_SWAGGER` is true, and `MAX_RESPONSE_ITEMS` is set to 50. See [Config Cheat Sheet](../administration/config-cheat-sheet.md) for more information.
+
+## Authentication
+
+Gitea supports these methods of API authentication:
+
+- HTTP basic 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`.
+
+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_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
+plain-text.  It will not be displayed when listing tokens with a `GET`
+request; e.g.
+
+```sh
+$ curl --url https://yourusername:password@gitea.your.host/api/v1/users/<username>/tokens
+[{"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).
+An example of the header is `X-Gitea-OTP: 123456` where `123456`
+is where you'd place the code from your authenticator.
+Here is how the request would look like in curl:
+
+```sh
+$ curl -H "X-Gitea-OTP: 123456" --url https://yourusername:yourpassword@gitea.your.host/api/v1/users/yourusername/tokens
+```
+
+You can also create an API key token via your Gitea installation's web
+interface: `Settings | Applications | Generate New Token`.
+
+## OAuth2 Provider
+
+Access tokens obtained from Gitea's [OAuth2 provider](development/oauth2-provider.md) are accepted by these methods:
+
+- `Authorization bearer ...` header in HTTP headers
+- `token=...` parameter in URL query string
+- `access_token=...` parameter in URL query string
+
+### More on the `Authorization:` header
+
+For historical reasons, Gitea needs the word `token` included before
+the API key token in an authorization header, like this:
+
+```sh
+Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675
+```
+
+In a `curl` command, for instance, this would look like:
+
+```sh
+curl "http://localhost:4000/api/v1/repos/test1/test1/issues" \
+    -H "accept: application/json" \
+    -H "Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675" \
+    -H "Content-Type: application/json" -d "{ \"body\": \"testing\", \"title\": \"test 20\"}" -i
+```
+
+As mentioned above, the token used is the same one you would use in
+the `token=` string in a GET request.
+
+## Pagination
+
+The API supports pagination. The `page` and `limit` parameters are used to specify the page number and the number of items per page. As well, the `Link` header is returned with the next, previous, and last page links if there are more than one pages. The `x-total-count` is also returned to indicate the total number of items.
+
+```sh
+curl -v "http://localhost/api/v1/repos/search?limit=1"
+...
+< link: <http://localhost/api/v1/repos/search?limit=1&page=2>; rel="next",<http://localhost/api/v1/repos/search?limit=1&page=5252>; rel="last"
+...
+< x-total-count: 5252
+```
+
+## API Guide
+
+API Reference guide is auto-generated by swagger and available on:
+`https://gitea.your.host/api/swagger`
+or on the
+[Gitea instance](https://gitea.com/api/swagger)
+
+The OpenAPI document is at:
+`https://gitea.your.host/swagger.v1.json`
+
+## Sudo
+
+The API allows admin users to sudo API requests as another user. Simply add either a `sudo=` parameter or `Sudo:` request header with the username of the user to sudo.
+
+## SDKs
+
+- [Official go-sdk](https://gitea.com/gitea/go-sdk)
+- [more](https://gitea.com/gitea/awesome-gitea#user-content-sdk)

docs/development/integrations.md

@@ -1,18 +1,9 @@
 ---
 date: "2019-04-15T17:29:00+08:00"
-title: "Integrations"
 slug: "integrations"
 sidebar_position: 65
-toc: false
-draft: false
 aliases:
   - /en-us/integrations
-menu:
-  sidebar:
-    parent: "development"
-    name: "Integrations"
-    sidebar_position: 65
-    identifier: "integrations"
 ---
 
 # Integrations

docs/development/migrations.md

@@ -1,21 +1,12 @@
 ---
 date: "2019-04-15T17:29:00+08:00"
-title: "Migrations Interfaces"
 slug: "migrations-interfaces"
 sidebar_position: 55
-toc: false
-draft: false
 aliases:
   - /en-us/migrations-interfaces
-menu:
-  sidebar:
-    parent: "development"
-    name: "Migrations Interfaces"
-    sidebar_position: 55
-    identifier: "migrations-interfaces"
 ---
 
-# Migration Features
+# Migration Interfaces
 
 Complete migrations were introduced in Gitea 1.9.0. It defines two interfaces to support migrating
 repository data from other Git host platforms to Gitea or, in the future, migrating Gitea data to other Git host platforms.

docs/development/oauth2-provider.md

@@ -0,0 +1,271 @@
+---
+date: "2023-06-01T08:40:00+08:00"
+slug: "oauth2-provider"
+sidebar_position: 41
+aliases:
+  - /en-us/oauth2-provider
+---
+
+# OAuth2 Provider
+
+Gitea supports acting as an OAuth2 Provider, allowing third-party applications to access its resources with user consent.
+
+When acting as the OAuth2 Provider, Gitea verifies every authorization request against the related OAuth2 Application. This application can be set up by an individual user, an organization admin, or a Gitea instance admin.
+
+Regardless of who configured the application, the first authorization attempt opens a new page in the user's web browser, prompting them to authorize the application.
+
+## Configuration
+
+An OAuth2 Application in Gitea requires the following configuration made in two steps:
+
+### Gitea Step 1
+- Name (`/admin/applications/`)
+- Redirect URL (`/admin/applications/`)
+
+![](/development/gitea_oauth2_step1.png)
+
+### Gitea Step 2
+- Client ID (`/admin/applications/oauth2/_id_`)
+- Client Secret (`/admin/applications/oauth2/_id_`)
+- Confidential client status (`/admin/applications/oauth2/_id_`)
+
+![](/development/gitea_oauth2_step2.png)
+
+### Third Party Step 3
+
+The third-party (Relaying Parties) application's request must include:
+
+- Credentials (Client ID and Client Secret)
+- Desired scope and claims (expected to be provided by Gitea)
+
+An example of MinIO:
+
+![](/development/minio_oauth2.png)
+
+
+### Gitea's User Approval Step 3
+
+For example, logging in with a Gitea account on MinIO...
+![](/development/minio_login.png)
+
+...will display the approval popup after a successful login:
+![](/development/gitea_approval.png)
+
+By default, if the third party sets the scopes to `openid`, `email`, `profile`, and `groups`, and the user approves, the application gains full access to all of the user's public and private resources (repositories, issues, user information, etc.).
+
+> **NOTE:** At present, an admin who sets up the OAuth2 Application in Gitea must rely on the scopes sent by the third party and an approval decision by the informed user if restrictive access is expected. There is no way for the admin to set restrictive access via scopes during the application setup process.
+
+
+## Granular Scopes
+
+As of version v1.23, Gitea supports granular scopes, allowing third parties to request more limited access. These scopes, previously available only for [Personal Access Tokens](#scopes), enable users to restrict access to specific URL routes.
+
+Scopes are grouped by high-level API routes and further refined as follows:
+
+- `read`: `GET` routes
+- `write`: `POST`, `PUT`, `PATCH`, and `DELETE` routes (in addition to `GET`)
+
+For example, a third party can request minimal access, allowing Gitea to act as a simple OpenID Connect (OIDC) Provider. If the third party adds only `public-only` to 'openid', no other or any combination of the scopes `email`, `userinfo`, or `groups`, Gitea will act as a basic Single Sign-On provider. This configuration provides only verification that the user can log in with the correct credentials, supplying only basic information such as username, email, and a list of public memberships in organizations and teams.
+
+When any of the granular scopes known from Personal Access Tokens is introduced, Gitea will not allow full access (as it does by default). Instead, it will build granular access following read or write permissions to resources such as Repositories, Issues, ActivityPub, Admin functions, Organizations, Users, Packages, or miscellaneous features.
+
+> **NOTE:** If third party adds any scope other than the OIDC ones: `openid`, `email`, `profile`, and `groups` or the ones found already in Personal Access Token the scope will fallback to full access as it was the case before v1.23
+
+The approval page displayed to the user shows the list of scopes requested by the third party. Once approved, this decision is remembered. If the third party changes its requested scopes in future requests, the entire flow will fail, requiring re-authorization.
+
+## Endpoints
+
+| Endpoint                 | URL                                 |
+| ------------------------ | ----------------------------------- |
+| 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`                 |
+
+## Supported OAuth2 Grants
+
+At the moment Gitea only supports the [**Authorization Code Grant**](https://tools.ietf.org/html/rfc6749#section-1.3.1) standard with additional support of the following extensions:
+
+- [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636)
+- [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth)
+
+To use the Authorization Code Grant as a third party application it is required to register a new application via the "Settings" (`/user/settings/applications`) section of the settings. To test or debug you can use the web-tool https://oauthdebugger.com/.
+
+## Scopes
+
+Gitea supports scoped access tokens, which allow users the ability to restrict tokens to operate only on selected url routes. Scopes are grouped by high-level API routes, and further refined to the following:
+
+- `read`: `GET` routes
+- `write`: `POST`, `PUT`, `PATCH`, and `DELETE` routes (in addition to `GET`)
+
+Gitea token scopes are as follows:
+
+| Name | Description                                                                                                                                          |
+| ---- |------------------------------------------------------------------------------------------------------------------------------------------------------|
+| **(no scope)** | Not supported. A scope is required even for public repositories.                                                                                     |
+| **activitypub** | `activitypub` API routes: ActivityPub related operations.                                                                                            |
+|     **read:activitypub** | Grants read access for ActivityPub operations.                                                                                                       |
+|     **write:activitypub** | Grants read/write/delete access for ActivityPub operations.                                                                                          |
+| **admin** | `/admin/*` API routes: Site-wide administrative operations (hidden for non-admin accounts).                                                          |
+|     **read:admin** | Grants read access for admin operations, such as getting cron jobs or registered user emails.                                                        |
+|     **write:admin** | Grants read/write/delete access for admin operations, such as running cron jobs or updating user accounts.                                           |
+| **issue** | `issues/*`, `labels/*`, `milestones/*` API routes: Issue-related operations.                                                                         |
+|     **read:issue** | Grants read access for issues operations, such as getting issue comments, issue attachments, and milestones.                                         |
+|     **write:issue** | Grants read/write/delete access for issues operations, such as posting or editing an issue comment or attachment, and updating milestones.           |
+| **misc** | Reserved for future usage.                                                                                                                           |
+|     **read:misc** | Reserved for future usage.                                                                                                                           |
+|     **write:misc** | Reserved for future usage.                                                                                                                           |
+| **notification** | `notification/*` API routes: user notification operations.                                                                                           |
+|     **read:notification** | Grants read access to user notifications, such as which notifications users are subscribed to and read new notifications.                            |
+|     **write:notification** | Grants read/write/delete access to user notifications, such as marking notifications as read.                                                        |
+| **organization** | `orgs/*` and `teams/*` API routes: Organization and team management operations.                                                                      |
+|     **read:organization** | Grants read access to org and team status, such as listing all orgs a user has visibility to, teams, and team members.                               |
+|     **write:organization** | Grants read/write/delete access to org and team status, such as creating and updating teams and updating org settings.                               |
+| **package** | `/packages/*` API routes: Packages operations                                                                                                        |
+|     **read:package** | Grants read access to package operations, such as reading and downloading available packages.                                                        |
+|     **write:package** | Grants read/write/delete access to package operations. Currently the same as `read:package`.                                                         |
+| **repository** | `/repos/*` API routes except `/repos/issues/*`: Repository file, pull-request, and release operations.                                               |
+|     **read:repository** | Grants read access to repository operations, such as getting repository files, releases, collaborators.                                              |
+|     **write:repository** | Grants read/write/delete access to repository operations, such as getting updating repository files, creating pull requests, updating collaborators. |
+| **user** | `/user/*` and `/users/*` API routes: User-related operations.                                                                                        |
+|     **read:user** | Grants read access to user operations, such as getting user repo subscriptions and user settings.                                                    |
+|     **write:user** | Grants read/write/delete access to user operations, such as updating user repo subscriptions, followed users, and user settings.                     |
+
+## Pre-configured Applications
+
+Gitea creates OAuth applications for the following services by default on startup, as we assume that these are universally useful.
+
+|Application|Description|Client ID|
+|-----------|-----------|---------|
+|[git-credential-oauth](https://github.com/hickford/git-credential-oauth)|Git credential helper|`a4792ccc-144e-407e-86c9-5e7d8d9c3269`|
+|[Git Credential Manager](https://github.com/git-ecosystem/git-credential-manager)|Git credential helper|`e90ee53c-94e2-48ac-9358-a874fb9e0662`|
+|[tea](https://gitea.com/gitea/tea)|tea|`d57cb8c4-630c-4168-8324-ec79935e18d4`|
+
+To prevent unexpected behavior, they are being displayed as locked in the UI and their creation can instead be controlled by the `DEFAULT_APPLICATIONS` parameter in `app.ini`.
+
+## Client types
+
+Gitea supports both confidential and public client types, [as defined by RFC 6749](https://datatracker.ietf.org/doc/html/rfc6749#section-2.1).
+
+For public clients, a redirect URI of a loopback IP address such as `http://127.0.0.1/` allows any port. Avoid using `localhost`, [as recommended by RFC 8252](https://datatracker.ietf.org/doc/html/rfc8252#section-8.3).
+
+## Examples
+
+### Confidential client
+
+:::note
+This example does not use PKCE.
+:::
+
+1. Redirect the user to the authorization endpoint in order to get their consent for accessing the resources:
+
+   ```curl
+   https://[YOUR-GITEA-URL]/login/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=code&state=STATE
+   ```
+
+   The `CLIENT_ID` can be obtained by registering an application in the settings. The `STATE` is a random string that will be sent back to your application after the user authorizes. The `state` parameter is optional, but should be used to prevent CSRF attacks.
+
+   ![Authorization Page](/authorize.png)
+
+   The user will now be asked to authorize your application. If they authorize it, the user will be redirected to the `REDIRECT_URL`, for example:
+
+   ```curl
+   https://[REDIRECT_URI]?code=RETURNED_CODE&state=STATE
+   ```
+
+2. Using the provided `code` from the redirect, you can request a new application and refresh token. The access token endpoint accepts POST requests with `application/json` and `application/x-www-form-urlencoded` body, for example:
+
+   ```curl
+   POST https://[YOUR-GITEA-URL]/login/oauth/access_token
+   ```
+
+   ```json
+   {
+     "client_id": "YOUR_CLIENT_ID",
+     "client_secret": "YOUR_CLIENT_SECRET",
+     "code": "RETURNED_CODE",
+     "grant_type": "authorization_code",
+     "redirect_uri": "REDIRECT_URI"
+   }
+   ```
+
+   Response:
+
+   ```json
+   {
+     "access_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjowLCJleHAiOjE1NTUxNzk5MTIsImlhdCI6MTU1NTE3NjMxMn0.0-iFsAwBtxuckA0sNZ6QpBQmywVPz129u75vOM7wPJecw5wqGyBkmstfJHAjEOqrAf_V5Z-1QYeCh_Cz4RiKug",
+     "token_type": "bearer",
+     "expires_in": 3600,
+     "refresh_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjoxLCJjbnQiOjEsImV4cCI6MTU1NzgwNDMxMiwiaWF0IjoxNTU1MTc2MzEyfQ.S_HZQBy4q9r5SEzNGNIoFClT43HPNDbUdHH-GYNYYdkRfft6XptJBkUQscZsGxOW975Yk6RbgtGvq1nkEcklOw"
+   }
+   ```
+
+   The `CLIENT_SECRET` is the unique secret code generated for this application. Please note that the secret will only be visible after you created/registered the application with Gitea and cannot be recovered. If you lose the secret, you must regenerate the secret via the application's settings.
+
+   The `REDIRECT_URI` in the `access_token` request must match the `REDIRECT_URI` in the `authorize` request.
+
+3. Use the `access_token` to make [API requests](development/api-usage.md#oauth2-provider) to access the user's resources.
+
+### Public client (PKCE)
+
+PKCE (Proof Key for Code Exchange) is an extension to the OAuth flow which allows for a secure credential exchange without the requirement to provide a client secret.
+
+**Note**: Please ensure you have registered your OAuth application as a public client.
+
+To achieve this, you have to provide a `code_verifier` for every authorization request. A `code_verifier` has to be a random string with a minimum length of 43 characters and a maximum length of 128 characters. It can contain alphanumeric characters as well as the characters `-`, `.`, `_`  and `~`.
+
+Using this `code_verifier` string, a new one called `code_challenge` is created by using one of two methods:
+
+- If you have the required functionality on your client, set `code_challenge` to be a URL-safe base64-encoded string of the SHA256 hash of `code_verifier`. In that case, your `code_challenge_method` becomes `S256`.
+- If you are unable to do so, you can provide your `code_verifier` as a plain string to `code_challenge`. Then you have to set your `code_challenge_method` as `plain`.
+
+After you have generated this values, you can continue with your request.
+
+1. Redirect the user to the authorization endpoint in order to get their consent for accessing the resources:
+
+   ```curl
+   https://[YOUR-GITEA-URL]/login/oauth/authorize?client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&response_type=code&code_challenge_method=CODE_CHALLENGE_METHOD&code_challenge=CODE_CHALLENGE&state=STATE
+   ```
+
+   The `CLIENT_ID` can be obtained by registering an application in the settings. The `STATE` is a random string that will be sent back to your application after the user authorizes. The `state` parameter is optional, but should be used to prevent CSRF attacks.
+
+   ![Authorization Page](/authorize.png)
+
+   The user will now be asked to authorize your application. If they authorize it, the user will be redirected to the `REDIRECT_URL`, for example:
+
+   ```curl
+   https://[REDIRECT_URI]?code=RETURNED_CODE&state=STATE
+   ```
+
+2. Using the provided `code` from the redirect, you can request a new application and refresh token. The access token endpoint accepts POST requests with `application/json` and `application/x-www-form-urlencoded` body, for example:
+
+   ```curl
+   POST https://[YOUR-GITEA-URL]/login/oauth/access_token
+   ```
+
+   ```json
+   {
+     "client_id": "YOUR_CLIENT_ID",
+     "code": "RETURNED_CODE",
+     "grant_type": "authorization_code",
+     "redirect_uri": "REDIRECT_URI",
+     "code_verifier": "CODE_VERIFIER",
+   }
+   ```
+
+   Response:
+
+   ```json
+   {
+     "access_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjowLCJleHAiOjE1NTUxNzk5MTIsImlhdCI6MTU1NTE3NjMxMn0.0-iFsAwBtxuckA0sNZ6QpBQmywVPz129u75vOM7wPJecw5wqGyBkmstfJHAjEOqrAf_V5Z-1QYeCh_Cz4RiKug",
+     "token_type": "bearer",
+     "expires_in": 3600,
+     "refresh_token": "eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJnbnQiOjIsInR0IjoxLCJjbnQiOjEsImV4cCI6MTU1NzgwNDMxMiwiaWF0IjoxNTU1MTc2MzEyfQ.S_HZQBy4q9r5SEzNGNIoFClT43HPNDbUdHH-GYNYYdkRfft6XptJBkUQscZsGxOW975Yk6RbgtGvq1nkEcklOw"
+   }
+   ```
+
+   The `REDIRECT_URI` in the `access_token` request must match the `REDIRECT_URI` in the `authorize` request.
+
+3. Use the `access_token` to make [API requests](development/api-usage.md#oauth2-provider) to access the user's resources.

docs/help/_category_.json

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

docs/help/faq.md

@@ -0,0 +1,352 @@
+---
+date: "2019-04-05T16:00:00+02:00"
+slug: "faq"
+sidebar_position: 5
+aliases:
+  - /en-us/faq
+---
+
+# FAQ
+
+This page contains some common questions and answers.
+
+For more help resources, check all [Support Options](help/support.md).
+
+## Difference between 1.x and 1.x.x downloads, how can I get latest stable release with bug fixes?
+
+Version 1.20.x will be used for this example.
+
+On our [downloads page](https://dl.gitea.com/gitea/) you will see a 1.20 directory, as well as directories for 1.20.0, 1.20.1.
+
+The 1.20 directory is the nightly build, which is built on each merged commit to the [`release/v1.20`](https://github.com/go-gitea/gitea/tree/release/v1.20) branch.
+
+The 1.20.0 directory is a release build that was created when the [`v1.20.0`](https://github.com/go-gitea/gitea/releases/tag/v1.20.0) tag was created.
+
+The nightly builds (1.x) downloads will change as commits are merged to their respective branch, they contain the latest changes/fixes before a tag release is built.
+
+If a bug fix is targeted on 1.20.1 but 1.20.1 is not released yet, you can get the "1.20-nightly" build to get the bug fix.
+
+## How to find the config file "app.ini"
+
+It depends on how you installed Gitea. If you didn't set a path for custom path or config file manually,
+then the config file (app.ini) should exists in the "custom/conf" directory of your Gitea's working path.
+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 -> 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.
+In this case you need to check the container's filesystem volume mapping
+and figure out the real path of the config file on the host.
+
+## Where does Gitea store what file
+
+- _`AppWorkPath`_
+  - The `WORK_PATH` option in `app.ini`
+  - Else the `--work-path` flag
+  - Else Environment variable `GITEA_WORK_DIR`
+  - Else a built-in value set at build time
+  - Else the directory that contains the Gitea binary
+- `AppDataPath` (default for database, indexers, etc.)
+  - `APP_DATA_PATH` from `app.ini`
+  - Else _`AppWorkPath`_`/data`
+- _`CustomPath`_ (custom templates)
+  - The `--custom-path` flag
+  - Else Environment variable `GITEA_CUSTOM`
+  - Else a built-in value set at build time
+  - Else _`AppWorkPath`_`/custom`
+- HomeDir
+  - Unix: Environment variable `HOME`
+  - Windows: Environment variable `USERPROFILE`, else environment variables `HOMEDRIVE`+`HOMEPATH`
+- RepoRootPath
+  - `ROOT` in the \[repository] section of `app.ini` if absolute
+  - Else _`AppWorkPath`_`/ROOT` if `ROOT` in the \[repository] section of `app.ini` if relative
+  - Default `%(APP_DATA_PATH)/gitea-repositories`
+- INI (config file)
+  - `--config` flag
+  - A possible built-in value set a build time
+  - Else _`CustomPath`_`/conf/app.ini`
+- SQLite Database
+  - `PATH` in `database` section of `app.ini`
+  - Else `%(APP_DATA_PATH)/gitea.db`
+
+## Not seeing a clone URL or the clone URL being incorrect
+
+There are a few places that could make this show incorrectly.
+
+1. If using a reverse proxy, make sure you have followed the correction directions in the [reverse proxy guide](../administration/reverse-proxies.md)
+2. Make sure you have correctly set `ROOT_URL` in the `server` section of your `app.ini`
+
+If certain clone options aren't showing up (HTTP/S or SSH), the following options can be checked in your `app.ini`
+
+- `DISABLE_HTTP_GIT`: if set to true, there will be no HTTP/HTTPS link
+- `DISABLE_SSH`: if set to true, there will be no SSH link
+- `SSH_EXPOSE_ANONYMOUS`: if set to false, SSH links will be hidden for anonymous users
+
+## File upload fails with: 413 Request Entity Too Large
+
+This error occurs when the reverse proxy limits the file upload size.
+
+See the [reverse proxy guide](../administration/reverse-proxies.md) for a solution with nginx.
+
+## Custom Templates not loading or working incorrectly
+
+Gitea's custom templates must be added to the correct location or Gitea will not find and use them.
+
+The correct path for the template(s) will be relative to the `CustomPath`
+
+1. To find `CustomPath`, look for Custom File Root Path in Site Administration -> Configuration
+2. If you are still unable to find a path, the default can be [calculated above](#where-does-gitea-store-what-file)
+3. Once you have figured out the correct custom path, you can refer to the [customizing Gitea](../administration/customizing-gitea.md) page to add your template to the correct location.
+
+## Does Gitea have a "GitHub/GitLab pages" feature?
+
+Gitea doesn't provide a built-in Pages server. You need a dedicated domain to serve static pages to avoid CSRF security risks.
+
+For simple usage, you can use a reverse proxy to rewrite & serve static contents from Gitea's raw file URLs.
+
+And there are already available third-party services, like a standalone [pages server](https://codeberg.org/Codeberg/pages-server) or a [caddy plugin](https://github.com/42wim/caddy-gitea), that can provide the required functionality.
+
+## Active user vs login prohibited user
+
+In Gitea, an "active" user refers to a user that has activated their account via email.
+
+A "login prohibited" user is a user that is not allowed to log in to Gitea anymore
+
+
+## What is Swagger?
+
+[Swagger](https://swagger.io/) is what Gitea uses for its API documentation.
+
+All Gitea instances have the built-in API and there is no way to disable it completely.
+You can, however, disable showing its documentation by setting `ENABLE_SWAGGER` to `false` in the `api` section of your `app.ini`.
+For more information, refer to Gitea's [API docs](development/api-usage.md).
+
+You can see the latest API (for example) on https://gitea.com/api/swagger
+
+You can also see an example of the `swagger.json` file at https://gitea.com/swagger.v1.json
+
+## Adjusting your server for public/private use
+
+### Preventing spammers
+
+There are multiple things you can combine to prevent spammers.
+
+1. By whitelisting or blocklisting certain email domains
+2. By only whitelisting certain domains with OpenID (see below)
+3. Setting `ENABLE_CAPTCHA` to `true` in your `app.ini` and properly configuring `RECAPTCHA_SECRET` and `RECAPTCHA_SITEKEY`
+4. Settings `DISABLE_REGISTRATION` to `true` and creating new users via the [CLI](../administration/command-line.md), [API](development/api-usage.md), or Gitea's Admin UI
+
+### Only allow/block certain email domains
+
+You can configure `EMAIL_DOMAIN_WHITELIST` or `EMAIL_DOMAIN_BLOCKLIST` in your app.ini under `[service]`
+
+### Only allow/block certain OpenID providers
+
+You can configure `WHITELISTED_URIS` or `BLACKLISTED_URIS` under `[openid]` in your `app.ini`
+
+:::note
+Whitelisted takes precedence, so if it is non-blank then blacklisted is ignored.
+:::
+
+### Issue only users
+
+The current way to achieve this is to create/modify a user with a max repo creation limit of 0.
+
+### Restricted users
+
+Restricted users are limited to a subset of the content based on their organization/team memberships and collaborations, ignoring the public flag on organizations/repos etc.\_\_
+
+Example use case: A company runs a Gitea instance that requires login. Most repos are public (accessible/browsable by all co-workers).
+
+At some point, a customer or third party needs access to a specific repo and only that repo. Making such a customer account restricted and granting any needed access using team membership(s) and/or collaboration(s) is a simple way to achieve that without the need to make everything private.
+
+### Enable Fail2ban
+
+Use [Fail2Ban](../administration/fail2ban-setup.md) to monitor and stop automated login attempts or other malicious behavior based on log patterns
+
+## SSHD vs built-in SSH
+
+SSHD is the built-in SSH server on most Unix systems.
+
+Gitea also provides its own SSH server, for usage when SSHD is not available.
+
+## Translation is incorrect/how to add more translations
+
+Our translations are currently crowd-sourced on our [Crowdin project](https://crowdin.com/project/gitea)
+
+Whether you want to change a translation or add a new one, it will need to be there as all translations are overwritten in our CI via the Crowdin integration.
+
+## Push Hook / Webhook / Actions aren't running
+
+If you can push but can't see push activities on the home dashboard, or the push doesn't trigger webhook and Actions workflows, it's likely that the git hooks are not working.
+
+There are a few possibilities:
+
+1. The git hooks are out of sync. Run the following actions on the site admin panel:
+- "Sync missed branches from git data to databases"
+- "Sync tags from git data to database"
+- "Resynchronize pre-receive, update and post-receive hooks of all repositories"
+2. The git repositories (and hooks) are stored on some filesystems (ex: mounted by NAS) which don't support script execution, make sure the filesystem supports `chmod a+x any-script`. Also make sure that the filesystem of the repositories is not mounted with the `noexec` option.
+3. If you are using docker, make sure Docker Server (not the client) >= 20.10.6
+
+## SSH issues
+
+If you cannot reach repositories over `ssh`, but `https` works fine, consider looking into the following.
+
+First, make sure you can access Gitea via SSH.
+
+`ssh [email protected]`
+
+If the connection is successful, you should receive an error message like the following:
+
+```
+Hi there, You've successfully authenticated, but Gitea does not provide shell access.
+If this is unexpected, please log in with password and setup Gitea under another user.
+```
+
+If you do not get the above message but still connect, it means your SSH key is **not** being managed by Gitea. This means hooks won't run, among other potential problems.
+
+If you cannot connect at all, your SSH key may not be configured correctly locally.
+This is specific to SSH and not Gitea, so will not be covered here.
+
+### SSH Common Errors
+
+```
+Permission denied (publickey).
+fatal: Could not read from remote repository.
+```
+
+This error signifies that the server rejected a log in attempt, check the
+following things:
+
+- On the client:
+  - Ensure the public and private ssh keys are added to the correct Gitea user.
+  - Make sure there are no issues in the remote url. In particular, ensure the name of the
+    Git user (before the `@`) is spelled correctly.
+  - Ensure public and private ssh keys are correct on client machine.
+- On the server:
+  - Make sure the repository exists and is correctly named.
+  - Check the permissions of the `.ssh` directory in the system user's home directory.
+  - Verify that the correct public keys are added to `.ssh/authorized_keys`.
+
+    Try to run `Rewrite '.ssh/authorized_keys' file (for Gitea SSH keys)` on the
+    Gitea admin panel.
+  - Read Gitea logs.
+  - Read /var/log/auth (or similar).
+  - Check permissions of repositories.
+
+The following is an example of a missing public SSH key where authentication
+succeeded, but some other setting is preventing SSH from reaching the correct
+repository.
+
+```
+fatal: Could not read from remote repository.
+
+Please make sure you have the correct access rights
+and the repository exists.
+```
+
+In this case, look into the following settings:
+
+- On the server:
+  - Make sure that the `git` system user has a usable shell set
+    - Verify this with `getent passwd git | cut -d: -f7`
+    - `usermod` or `chsh` can be used to modify this.
+  - Ensure that the `gitea serv` command in `.ssh/authorized_keys` uses the
+    correct configuration file.
+
+## Missing releases after migrating repository with tags
+
+To migrate an repository _with_ all tags, you need to do two things:
+
+- Push tags to the repository:
+
+```
+ git push --tags
+```
+
+- (Re-)sync tags of all repositories within Gitea:
+
+```
+gitea admin repo-sync-releases
+```
+
+## How can I create users before starting Gitea
+
+Gitea provides a sub-command `gitea migrate` to initialize the database, after which you can use the [admin CLI commands](../administration/command-line.md#admin) to add users like normal.
+
+## How can I enable password reset
+
+There is no setting for password resets. It is enabled when a [mail service](../administration/email-setup.md) is configured, and disabled otherwise.
+
+## How can a user's password be changed
+
+- As an **admin**, you can change any user's password (and optionally force them to change it on next login)...
+  - By navigating to your `Site Administration -> User Accounts` page and editing a user.
+  - By using the [admin CLI commands](../administration/command-line.md#admin).
+
+    Keep in mind most commands will also need a [global flag](../administration/command-line.md#global-options) to point the CLI at the correct configuration.
+- As a **user** you can change it...
+  - In your account `Settings -> Account` page (this method **requires** you to know your current password).
+  - By using the `Forgot Password` link.
+
+    If the `Forgot Password/Account Recovery` page is disabled, please contact your administrator to configure a [mail service](../administration/email-setup.md).
+
+## Warnings about struct defaults during database startup
+
+Sometimes when there are migrations the old columns and default values may be left
+unchanged in the database schema. This may lead to warning such as:
+
+```
+2020/08/02 11:32:29 ...rm/session_schema.go:360:Sync() [W] Table user Column keep_activity_private db default is , struct default is 0
+```
+
+These can safely be ignored, but you are able to stop these warnings by getting Gitea to recreate these tables using:
+
+```
+gitea doctor recreate-table user
+```
+
+This will cause Gitea to recreate the user table and copy the old data into the new table
+with the defaults set appropriately.
+
+You can ask Gitea to recreate multiple tables using:
+
+```
+gitea doctor recreate-table table1 table2 ...
+```
+
+And if you would like Gitea to recreate all tables simply call:
+
+```
+gitea doctor recreate-table
+```
+
+It is highly recommended to back-up your database before running these commands.
+
+## How to adopt repositories from disk
+
+- 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.
+- 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.
+  - 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.
+
+## Gitea can't start on NFS
+
+In most cases, it's caused by broken NFS lock system. You can try to stop Gitea process and
+run `flock -n /data-nfs/gitea/queues/LOCK echo 'lock acquired'` to see whether the lock can be acquired immediately.
+If the lock can't be acquired, NFS might report some errors like `lockd: cannot monitor node-3, statd: server rpc.statd not responding, timed out` in its server logs.
+
+Then the NFS lock could be reset by:
+
+```bash
+# /etc/init.d/nfs stop
+# rm -rf /var/lib/nfs/sm/*
+# /etc/init.d/nfs start
+```

docs/help/support.md

@@ -0,0 +1,71 @@
+---
+date: "2018-05-21T15:00:00+00:00"
+slug: "support"
+sidebar_position: 20
+aliases:
+  - /en-us/seek-help
+---
+
+# Support Options
+
+- [Paid Commercial Support](https://about.gitea.com/)
+- [Discord](https://discord.gg/Gitea)
+- [Forum](https://forum.gitea.com/)
+- [Matrix](https://matrix.to/#/#gitea-space:matrix.org)
+  - NOTE: Most of the Matrix channels are bridged with their counterpart in Discord and may experience some degree of flakiness with the bridge process.
+- Chinese Support
+  - [Discourse Chinese Category](https://forum.gitea.com/c/5-category/5)
+  - QQ Group 328432459
+
+# Bug Report
+
+If you found a bug, please [create an issue on GitHub](https://github.com/go-gitea/gitea/issues).
+
+:::note
+When asking for support, it may be a good idea to have the following available so that the person helping has all the info they need:
+:::
+
+1. Your `app.ini` (with any sensitive data scrubbed as necessary).
+2. Any error messages you are seeing.
+3. The Gitea logs, and all other related logs for the situation.
+   - It's more useful to collect `trace` / `debug` level logs (see the next section).
+   - When using systemd, use `journalctl --lines 1000 --unit gitea` to collect logs.
+   - When using docker, use `docker logs --tail 1000 <gitea-container>` to collect logs.
+4. Reproducible steps so that others could reproduce and understand the problem more quickly and easily.
+   - [demo.gitea.com](https://demo.gitea.com) could be used to reproduce the problem.
+5. If you encounter slow/hanging/deadlock problems, please report the stacktrace when the problem occurs.
+   Go to the "Site Admin" -> "Monitoring" -> "Stacktrace" -> "Download diagnosis report".
+
+# Advanced Bug Report Tips
+
+## More Config Options for Logs
+
+By default, the logs are outputted to console with `info` level.
+If you need to set log level and/or collect logs from files,
+you could just copy the following config into your `app.ini` (remove all other `[log]` sections),
+then you will find the `*.log` files in Gitea's log directory (default: `%(GITEA_WORK_DIR)/log`).
+
+```ini
+; To show all SQL logs, you can also set LOG_SQL=true in the [database] section
+[log]
+LEVEL=debug
+MODE=console,file
+```
+
+## Collecting Stacktrace by Command Line
+
+Gitea could use Golang's pprof handler and toolchain to collect stacktrace and other runtime information.
+
+If the web UI stops working, you could try to collect the stacktrace by command line:
+
+1. Set `app.ini`:
+
+    ```
+    [server]
+    ENABLE_PPROF = true
+    ```
+
+2. Restart Gitea
+
+3. Try to trigger the bug, when the requests get stuck for a while,
+   use `curl` or browser to visit: `http://127.0.0.1:6060/debug/pprof/goroutine?debug=1` to get the stacktrace.

docs/index.md

@@ -0,0 +1,110 @@
+---
+date: "2016-11-08T16:00:00+02:00"
+slug: /
+sidebar_position: 10
+
+---
+
+# What is Gitea?
+
+Gitea is a painless, self-hosted, all-in-one software development service. It includes Git hosting, code review, team collaboration, package registry, and CI/CD. It is similar to GitHub, Bitbucket and GitLab.
+
+Gitea was originally forked from [Gogs](https://gogs.io) and almost all the code has been changed. See the [Gitea Announcement](https://blog.gitea.com/welcome-to-gitea/) blog post to read about the justification for a fork.
+
+:::warning
+
+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.
+
+:::
+
+## Purpose
+
+The goal of this project is to provide the easiest, fastest, and most painless way of setting
+up a self-hosted Git service.
+
+With Go, this can be done platform-independently across
+**all platforms** which Go supports, including Linux, macOS, and Windows,
+on x86, amd64, ARM and PowerPC architectures.
+You can try it out using [the online demo](https://demo.gitea.com).
+
+## Features
+
+- **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-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.
+
+- **Easy Deployment and Maintenance**
+
+  It can be easily deployed on various servers without complex configurations or dependencies. This makes it convenient for individual developers or small teams to set up and manage their own Git services.
+
+- **Security**
+
+  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**
+
+  Code review supports both the Pull Request workflow and AGit workflow. Reviewers can browse code online and provide review comments or feedback. Submitters can receive review comments and respond or modify code online. Code reviews can help individuals and organizations enhance code quality.
+
+- **CI/CD**
+
+  Gitea Actions supports CI/CD functionality, compatible with GitHub Actions. Users can write workflows in familiar YAML format and reuse a variety of existing Actions plugins. Actions plugins support downloading from any Git website.
+
+- **Project Management**
+
+  Gitea tracks project requirements, features, and bugs through columns and issues. Issues support features like branches, tags, milestones, assignments, time tracking, due dates, dependencies, and more.
+
+- **Artifact Repository**
+
+  Gitea supports over 20 different types of public or private software package management, including Cargo, Chef, Composer, Conan, Conda, Container, Helm, Maven, npm, NuGet, Pub, PyPI, RubyGems, Vagrant, and more.
+
+- **Open Source Community Support**
+
+  Gitea is an open-source project based on the MIT license. It has an active open-source community that continuously develops and improves the platform. The project also actively welcomes community contributions, ensuring updates and innovation.
+
+- **Multilingual Support**
+
+  Gitea provides interfaces in multiple languages, catering to users globally and promoting internationalization and localization.
+
+For more detailed information, please refer to: https://docs.gitea.com/installation/comparison#general-features
+
+## System Requirements
+
+- A Raspberry Pi 3 is powerful enough to run Gitea for small workloads.
+- 2 CPU cores and 1GB RAM is typically sufficient for small teams/projects.
+- Gitea should be run with a dedicated non-root system account on UNIX-type systems.
+  - Note: Gitea manages the `~/.ssh/authorized_keys` file. Running Gitea as a regular user could break that user's ability to log in.
+- [Git](https://git-scm.com/) version 2.0.0 or later is required.
+  - [Git Large File Storage](https://git-lfs.github.com/) will be available if enabled and if your Git version is >= 2.1.2
+  - Git commit-graph rendering will be enabled automatically if your Git version is >= 2.18
+
+## Browser Support
+
+- Last 2 versions of Chrome, Firefox, Safari and Edge
+- Firefox ESR
+
+## Components
+
+- Web server framework: [Chi](http://github.com/go-chi/chi)
+- ORM: [XORM](https://xorm.io)
+- UI frameworks:
+  - [jQuery](https://jquery.com)
+  - [Fomantic UI](https://fomantic-ui.com)
+  - [Vue3](https://vuejs.org)
+  - and various components (see package.json)
+- Editors:
+  - [CodeMirror](https://codemirror.net)
+  - [EasyMDE](https://github.com/Ionaru/easy-markdown-editor)
+  - [Monaco Editor](https://microsoft.github.io/monaco-editor)
+- Database drivers:
+  - [github.com/go-sql-driver/mysql](https://github.com/go-sql-driver/mysql)
+  - [github.com/lib/pq](https://github.com/lib/pq)
+  - [github.com/mattn/go-sqlite3](https://github.com/mattn/go-sqlite3)
+  - [github.com/denisenkom/go-mssqldb](https://github.com/denisenkom/go-mssqldb)
+
+## 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

@@ -0,0 +1,146 @@
+---
+date: "2018-05-07T13:00:00+02:00"
+slug: "comparison"
+sidebar_position: 5
+aliases:
+  - /en-us/comparison
+---
+
+# Compared to other Git hosting
+
+To help decide if Gitea is suited for your needs, here is how it compares to other Git self hosted options.
+
+Be warned that we don't regularly check for feature changes in other products, so this list may be outdated. If you find anything that needs to be updated in the table below, please [open an issue](https://github.com/go-gitea/gitea/issues/new/choose).
+
+_Symbols used in table:_
+
+- _✓ - supported_
+
+- _⁄ - supported with limited functionality_
+
+- _✘ - unsupported_
+
+- _⚙️ - supported through third-party software_
+
+## General Features
+
+| Feature                                          | Gitea                                               | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
+| ------------------------------------------------ | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
+| Open source and free                             | ✓                                                   | ✘         | ✓         | ✘         | ✘         | ✓            | ✓            |
+| Low RAM/ CPU usage                               | ✓                                                   | ✘         | ✘         | ✘         | ✘         | ✘            | ✘            |
+| Multiple database support                        | ✓                                                   | ✘         | ⁄         | ⁄         | ✓         | ✓            | ✓            |
+| Multiple OS support                              | ✓                                                   | ✘         | ✘         | ✘         | ✘         | ✓            | ✓            |
+| Easy upgrades                                    | ✓                                                   | ✘         | ✓         | ✓         | ✘         | ✓            | ✓            |
+| 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)   | ✓                                                   | ✘         | ✓         | ✓         | ✘         | ✓            | ✓            |
+| Sync commits from an external repo (pull mirror) | ✓                                                   | ✘         | ✓         | ✓         | ✘         | ✓            | ✓            |
+| Light and Dark Theme                             | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Custom Theme Support                             | ✓                                                   | ✘         | ✘         | ✘         | ✓         | ✓            | ✓            |
+| Markdown support                                 | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| CSV support                                      | ✓                                                   | ✓         | ✘         | ✘         | ✓         | ✘            | ✘            |
+| 'GitHub / GitLab pages'                          | [⚙️][gitea-pages-server], [⚙️][gitea-caddy-plugin]    | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Gists / Snippets                                 | [⚙️][opengist]                                       | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Repo-specific wiki (as a repo itself)            | ✓                                                   | ✓         | ✓         | ✓         | /         | ✘            | ✘            |
+| Deploy Tokens                                    | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Repository Tokens with write rights              | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| RSS Feeds                                        | ✓                                                   | ✓         | ✘         | ✘         | ✘         | ✓            | ✓            |
+| Built-in CI/CD                                   | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Subgroups: groups within groups                  | [✘](https://github.com/go-gitea/gitea/issues/1872)  | ✘         | ✓         | ✓         | ✘         | ✓            | ✓            |
+| Interaction with other instances                 | [/](https://github.com/go-gitea/gitea/issues/18240) | ✘         | ✘         | ✘         | ✘         | ✘            | ✘            |
+| Mermaid diagrams in Markdown                     | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Math syntax in Markdown                          | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✓            | ✓            |
+
+## Code management
+
+| Feature                                     | Gitea                                               | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
+| ------------------------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
+| Repository topics                           | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Repository code search                      | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Global code search                          | ✓                                                   | ✓         | ✘         | ✓         | ✓         | ✓            | ✓            |
+| Git LFS 2.0                                 | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Group Milestones                            | [✘](https://github.com/go-gitea/gitea/issues/14622) | ✘         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Granular user roles (Code, Issues, Wiki, …) | ✓                                                   | ✘         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Verified Committer                          | ⁄                                                   | ?         | ✓         | ✓         | ✓         | ✘            | ✘            |
+| GPG Signed Commits                          | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| SSH Signed Commits                          | ✓                                                   | ✓         | ✓         | ✓         | ?         | ✘            | ✘            |
+| Reject unsigned commits                     | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Migrating repos from other services         | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Repository Activity page                    | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Branch manager                              | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Create new branches                         | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Web code editor                             | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Commit graph                                | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Template Repositories                       | ✓                                                   | ✓         | ✘         | ✓         | ✓         | ✘            | ✘            |
+| Git Blame                                   | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Visual comparison of image changes          | ✓                                                   | ✓         | ?         | ?         | ?         | ✘            | ✘            |
+
+- Gitea has builtin repository-level code search
+- Better code search support could be achieved by [using a repository indexer](../administration/repo-indexer.md)
+
+## Issue Tracker
+
+| Feature                       | Gitea                                               | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
+| ----------------------------- | --------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
+| Issue tracker                 | ✓                                                   | ✓         | ✓         | ✓         | /         | ✘            | ✘            |
+| Issue templates               | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Labels                        | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Time tracking                 | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Multiple assignees for issues | ✓                                                   | ✓         | ✘         | ✓         | ✘         | ✘            | ✘            |
+| Related issues                | ✘                                                   | ⁄         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Confidential issues           | [✘](https://github.com/go-gitea/gitea/issues/3217)  | ✘         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Comment reactions             | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Lock Discussion               | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Batch issue handling          | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Projects                      | [/](https://github.com/go-gitea/gitea/issues/14710) | ✘         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Create branch from issue      | [✘](https://github.com/go-gitea/gitea/issues/20226) | ✘         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Convert comment to new issue  | ✓                                                   | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Issue search                  | ✓                                                   | ✓         | ✓         | ✓         | ✓         | ✘            | ✘            |
+| Global issue search           | [/](https://github.com/go-gitea/gitea/issues/2434)  | ✓         | ✓         | ✓         | ✓         | ✘            | ✘            |
+| Issue dependency              | ✓                                                   | ✘         | ✘         | ✘         | ✘         | ✘            | ✘            |
+| Create issue via email        | [✘](https://github.com/go-gitea/gitea/issues/6226)  | ✘         | ✓         | ✓         | ✓         | ✘            | ✘            |
+| Service Desk                  | [✘](https://github.com/go-gitea/gitea/issues/6219)  | ✘         | ✓         | ✓         | ✘         | ✘            | ✘            |
+
+## Pull/Merge requests
+
+| Feature                                         | Gitea                                              | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
+| ----------------------------------------------- | -------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
+| Pull/Merge requests                             | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Squash merging                                  | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Rebase merging                                  | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Pull/Merge request inline comments              | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Pull/Merge request approval                     | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Pull/Merge require approval                     | ✓                                                  | ✓         | ✘         | ✓         | ✓         | ✓            | ✓            |
+| Pull/Merge multiple reviewers                   | ✓                                                  | ✓         | ✘         | ✓         | ✓         | ✓            | ✓            |
+| Merge conflict resolution                       | [✘](https://github.com/go-gitea/gitea/issues/9014) | ✓         | ✓         | ✓         | ✓         | ✘            | ✘            |
+| Restrict push and merge access to certain users | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Revert specific commits                         | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✘            | ✘            |
+| Pull/Merge requests templates                   | ✓                                                  | ✓         | ✓         | ✓         | ✘         | ✘            | ✘            |
+| Cherry-picking changes                          | ✓                                                  | ✘         | ✓         | ✓         | ✘         | ✘            | ✓            |
+| Download Patch                                  | ✓                                                  | ✓         | ✓         | ✓         | /         | ✓            | ✓            |
+| Merge queues                                    | ✓                                                  | ✓         | ✘         | ✓         | ✘         | ✘            | ✘            |
+
+## 3rd-party integrations
+
+| Feature                                        | Gitea                                              | GitHub EE | GitLab CE | GitLab EE | BitBucket | RhodeCode CE | RhodeCode EE |
+| ---------------------------------------------- | -------------------------------------------------- | --------- | --------- | --------- | --------- | ------------ | ------------ |
+| Webhooks                                       | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Git Hooks                                      | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| AD / LDAP integration                          | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+| Multiple LDAP / AD server support              | ✓                                                  | ✘         | ✘         | ✓         | ✓         | ✓            | ✓            |
+| LDAP user synchronization                      | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✘            | ✓            |
+| SAML 2.0 service provider                      | [✘](https://github.com/go-gitea/gitea/issues/5512) | ✓         | ✓         | ✓         | ✓         | ✘            | ✓            |
+| OpenID Connect support                         | ✓                                                  | ✓         | ✓         | ✓         | ?         | ✘            | ✓            |
+| OAuth 2.0 integration (external authorization) | ✓                                                  | ⁄         | ✓         | ✓         | ?         | ✘            | ✓            |
+| Act as OAuth 2.0 provider                      | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✘            | ✘            |
+| Two factor authentication (2FA)                | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✘            | ✓            |
+| Integration with the most common services      | ✓                                                  | ⁄         | ✓         | ✓         | ⁄         | ✓            | ✓            |
+| Incorporate external CI/CD                     | ✓                                                  | ✓         | ✓         | ✓         | ✓         | ✓            | ✓            |
+
+[gitea-caddy-plugin]: https://github.com/42wim/caddy-gitea
+[gitea-pages-server]: https://codeberg.org/Codeberg/pages-server
+[opengist]: https://github.com/thomiceli/opengist

docs/installation/database-preparation.md

@@ -0,0 +1,311 @@
+---
+date: "2020-01-16"
+slug: "database-prep"
+sidebar_position: 10
+aliases:
+  - /en-us/database-prep
+---
+
+# Database Preparation
+
+You need a database to use Gitea. Gitea supports PostgreSQL (>= 12), MySQL (>= 8.0), MariaDB (>= 10.4), SQLite (builtin), and MSSQL (>= 2012 SP4). This page will guide into preparing database. Only PostgreSQL and MySQL will be covered here since those database engines are widely-used in production. If you plan to use SQLite, you can ignore this chapter.
+
+:::warning
+Converting one database type to another is not a well-tested process and you may experience issues. It is better to choose the final database type at the type of the first installation. Be aware that SQLite does not scale; if you expect your instance to grow at a later time, you should choose another database type.
+:::
+
+If you use an unsupported database version, please [get in touch](/help/support) with us for information on our Extended Support Contracts. We can provide testing and support for older databases and integrate those fixes into the Gitea codebase.
+
+Database instance can be on same machine as Gitea (local database setup), or on different machine (remote database).
+
+:::note
+All steps below requires that the database engine of your choice is installed on your system. For remote database setup, install the server application on database instance and client program on your Gitea server. The client program is used to test connection to the database from Gitea server, while Gitea itself use database driver provided by Go to accomplish the same thing. In addition, make sure you use same engine version for both server and client for some engine features to work. For security reason, protect `root` (MySQL) or `postgres` (PostgreSQL) database superuser with secure password. The steps assumes that you run Linux for both database and Gitea servers.
+:::
+
+## MySQL/MariaDB
+
+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
+    ```
+
+2. On database instance, login to database console as root:
+
+    ```sh
+    mysql -u root -p
+    ```
+
+    Enter the password as prompted.
+
+3. Create database user which will be used by Gitea, authenticated by password. This example uses `'gitea'` as password. Please use a secure password for your instance.
+
+    For local database:
+
+    ```sql
+    SET old_passwords=0;
+    CREATE USER 'gitea'@'%' IDENTIFIED BY 'gitea';
+    ```
+
+    For remote database:
+
+    ```sql
+    SET old_passwords=0;
+    CREATE USER 'gitea'@'192.0.2.10' IDENTIFIED BY 'gitea';
+    ```
+
+    where `192.0.2.10` is the IP address of your Gitea instance.
+
+    Replace username and password above as appropriate.
+
+4. Create database with UTF-8 charset and case-sensitive collation.
+
+    `utf8mb4_bin` is a common collation for both MySQL/MariaDB.
+    When Gitea starts, it will try to find a better collation (`utf8mb4_0900_as_cs` or `uca1400_as_cs`) and alter the database if it is possible.
+    If you would like to use other collation, you can set `[database].CHARSET_COLLATION` in the `app.ini` file.
+
+    ```sql
+    CREATE DATABASE giteadb CHARACTER SET 'utf8mb4' COLLATE 'utf8mb4_bin';
+    ```
+
+    Replace database name as appropriate.
+
+5. Grant all privileges on the database to database user created above.
+
+    For local database:
+
+    ```sql
+    GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea';
+    FLUSH PRIVILEGES;
+    ```
+
+    For remote database:
+
+    ```sql
+    GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'192.0.2.10';
+    FLUSH PRIVILEGES;
+    ```
+
+6. Quit from database console by `exit`.
+
+7. On your Gitea server, test connection to the database:
+
+    ```
+    mysql -u gitea -h 203.0.113.3 -p giteadb
+    ```
+
+    where `gitea` is database username, `giteadb` is database name, and `203.0.113.3` is IP address of database instance. Omit `-h` option for local database.
+
+    You should be connected to the database.
+
+## PostgreSQL
+
+1. For remote database setup, configure PostgreSQL on database instance to listen to your IP address by editing `listen_addresses` on `postgresql.conf` to:
+
+    ```ini
+    listen_addresses = 'localhost, 203.0.113.3'
+    ```
+
+2. PostgreSQL uses `md5` challenge-response encryption scheme for password authentication by default. Nowadays this scheme is not considered secure anymore. Use SCRAM-SHA-256 scheme instead by editing the `postgresql.conf` configuration file on the database server to:
+
+    ```ini
+    password_encryption = scram-sha-256
+    ```
+
+    Restart PostgreSQL to apply the setting.
+
+3. On the database server, login to the database console as superuser:
+
+    ```
+    su -c "psql" - postgres
+    ```
+
+4. Create database user (role in PostgreSQL terms) with login privilege and password. Please use a secure, strong password instead of `'gitea'` below:
+
+    ```sql
+    CREATE ROLE gitea WITH LOGIN PASSWORD 'gitea';
+    ```
+
+    Replace username and password as appropriate.
+
+5. Create database with UTF-8 charset and owned by the database user created earlier. Any `libc` collations can be specified with `LC_COLLATE` and `LC_CTYPE` parameter, depending on expected content:
+
+    ```sql
+    CREATE DATABASE giteadb WITH OWNER gitea TEMPLATE template0 ENCODING UTF8 LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8';
+    ```
+
+    Replace database name as appropriate.
+
+6. Allow the database user to access the database created above by adding the following authentication rule to `pg_hba.conf`.
+
+    For local database:
+
+    ```ini
+    local    giteadb    gitea    scram-sha-256
+    ```
+
+    For remote database:
+
+    ```ini
+    host    giteadb    gitea    192.0.2.10/32    scram-sha-256
+    ```
+
+    Replace database name, user, and IP address of Gitea instance with your own.
+
+    :::note
+    Rules on `pg_hba.conf` are evaluated sequentially, that is the first matching rule will be used for authentication. Your PostgreSQL installation may come with generic authentication rules that match all users and databases. You may need to place the rules presented here above such generic rules if it is the case.
+    :::
+
+    Restart PostgreSQL to apply new authentication rules.
+
+7. On your Gitea server, test connection to the database.
+
+    For local database:
+
+    ```bash
+    psql -U gitea -d giteadb
+    ```
+
+    For remote database:
+
+    ```bash
+    psql "postgres://gitea@203.0.113.3/giteadb"
+    ```
+
+    where `gitea` is database user, `giteadb` is database name, and `203.0.113.3` is IP address of your database instance.
+
+    You should be prompted to enter password for the database user, and connected to the database.
+
+## Database Connection over TLS
+
+If the communication between Gitea and your database instance is performed through a private network, or if Gitea and the database are running on the same server, this section can be omitted since the security between Gitea and the database instance is not critically exposed. If instead the database instance is on a public network, use TLS to encrypt the connection to the database, as it is possible for third-parties to intercept the traffic data.
+
+### Prerequisites
+
+- You need two valid TLS certificates, one for the database instance (database server) and one for the Gitea instance (database client). Both certificates must be signed by a trusted CA.
+- The database certificate must contain `TLS Web Server Authentication` in the `X509v3 Extended Key Usage` extension attribute, while the client certificate needs `TLS Web Client Authentication` in the corresponding attribute.
+- On the database server certificate, one of `Subject Alternative Name` or `Common Name` entries must be the fully-qualified domain name (FQDN) of the database instance (e.g. `db.example.com`). On the database client certificate, one of the entries mentioned above must contain the database username that Gitea will be using to connect.
+- You need domain name mappings of both Gitea and database servers to their respective IP addresses. Either set up DNS records for them or add local mappings to `/etc/hosts` (`%WINDIR%\System32\drivers\etc\hosts` in Windows) on each system. This allows the database connections to be performed by domain name instead of IP address. See documentation of your system for details.
+
+### PostgreSQL TLS
+
+The PostgreSQL driver used by Gitea supports two-way TLS. In two-way TLS, both database client and server authenticate each other by sending their respective certificates to their respective opposite for validation. In other words, the server verifies client certificate, and the client verifies server certificate.
+
+1. On the server with the database instance, place the following credentials:
+
+    - `/path/to/postgresql.crt`: Database instance certificate
+    - `/path/to/postgresql.key`: Database instance private key
+    - `/path/to/root.crt`: CA certificate chain to validate client certificates
+
+2. Add following options to `postgresql.conf`:
+
+    ```ini
+    ssl = on
+    ssl_ca_file = '/path/to/root.crt'
+    ssl_cert_file = '/path/to/postgresql.crt'
+    ssl_key_file = '/path/to/postgresql.key'
+    ssl_min_protocol_version = 'TLSv1.2'
+    ```
+
+3. Adjust credentials ownership and permission, as required by PostgreSQL:
+
+    ```
+    chown postgres:postgres /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
+    chmod 0600 /path/to/root.crt /path/to/postgresql.crt /path/to/postgresql.key
+    ```
+
+4. Edit `pg_hba.conf` rule to only allow Gitea database user to connect over SSL, and to require client certificate verification.
+
+    For PostgreSQL 12:
+
+    ```ini
+    hostssl    giteadb    gitea    192.0.2.10/32    scram-sha-256    clientcert=verify-full
+    ```
+
+    For PostgreSQL 11 and earlier:
+
+    ```ini
+    hostssl    giteadb    gitea    192.0.2.10/32    scram-sha-256    clientcert=1
+    ```
+
+    Replace database name, user, and IP address of Gitea instance as appropriate.
+
+5. Restart PostgreSQL to apply configurations above.
+
+6. On the server running the Gitea instance, place the following credentials under the home directory of the user who runs Gitea (e.g. `git`):
+
+    - `~/.postgresql/postgresql.crt`: Database client certificate
+    - `~/.postgresql/postgresql.key`: Database client private key
+    - `~/.postgresql/root.crt`: CA certificate chain to validate server certificate
+
+    :::note
+    Those file names above are hardcoded in PostgreSQL and it is not possible to change them.
+    :::
+
+7. Adjust credentials, ownership and permission as required:
+
+    ```
+    chown git:git ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
+    chown 0600 ~/.postgresql/postgresql.crt ~/.postgresql/postgresql.key ~/.postgresql/root.crt
+    ```
+
+8. Test the connection to the database:
+
+    ```
+    psql "postgres://gitea@example.db/giteadb?sslmode=verify-full"
+    ```
+
+    You should be prompted to enter password for the database user, and then be connected to the database.
+
+### MySQL/MariaDB TLS
+
+While the MySQL driver used by Gitea also supports two-way TLS, Gitea currently supports only one-way TLS. See issue #10828 for details.
+
+In one-way TLS, the database client verifies the certificate sent from server during the connection handshake, and the server assumes that the connected client is legitimate, since client certificate verification doesn't take place.
+
+1. On the database instance, place the following credentials:
+
+    - `/path/to/mysql.crt`: Database instance certificate
+    - `/path/to/mysql.key`: Database instance key
+    - `/path/to/ca.crt`: CA certificate chain. This file isn't used on one-way TLS, but is used to validate client certificates on two-way TLS.
+
+2. Add following options to `my.cnf`:
+
+    ```ini
+    [mysqld]
+    ssl-ca = /path/to/ca.crt
+    ssl-cert = /path/to/mysql.crt
+    ssl-key = /path/to/mysql.key
+    tls-version = TLSv1.2,TLSv1.3
+    ```
+
+3. Adjust credentials ownership and permission:
+
+    ```
+    chown mysql:mysql /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
+    chmod 0600 /path/to/ca.crt /path/to/mysql.crt /path/to/mysql.key
+    ```
+
+4. Restart MySQL to apply the setting.
+
+5. The database user for Gitea may have been created earlier, but it would authenticate only against the IP addresses of the server running Gitea. To authenticate against its domain name, recreate the user, and this time also set it to require TLS for connecting to the database:
+
+    ```sql
+    DROP USER 'gitea'@'192.0.2.10';
+    CREATE USER 'gitea'@'example.gitea' IDENTIFIED BY 'gitea' REQUIRE SSL;
+    GRANT ALL PRIVILEGES ON giteadb.* TO 'gitea'@'example.gitea';
+    FLUSH PRIVILEGES;
+    ```
+
+    Replace database user name, password, and Gitea instance domain as appropriate.
+
+6. Make sure that the CA certificate chain required to validate the database server certificate is on the system certificate store of both the database and Gitea servers. Consult your system documentation for instructions on adding a CA certificate to the certificate store.
+
+7. On the server running Gitea, test connection to the database:
+
+    ```
+    mysql -u gitea -h example.db -p --ssl
+    ```
+
+    You should be connected to the database.

docs/installation/from-binary.md

@@ -0,0 +1,263 @@
+---
+date: "2017-06-19T12:00:00+02:00"
+slug: "install-from-binary"
+sidebar_position: 15
+aliases:
+  - /en-us/install-from-binary
+---
+
+# Installation from binary
+
+All downloads come with SQLite, MySQL and PostgreSQL support, and are built with
+embedded assets. This can be different from Gogs.
+
+## Download
+
+You can find the file matching your platform from the [downloads page](https://dl.gitea.com/gitea/) after navigating to the version you want to download.
+
+### Choosing the right file
+
+**For Linux**, you will likely want `linux-amd64`. It's for 64-bit Intel/AMD platforms, but there are other platforms available, including `arm64` (e.g. Raspberry PI 4), `386` (i.e. 32-bit), `arm-5`, and `arm-6`.
+
+**For Windows**, you will likely want `windows-4.0-amd64`. It's for all modern versions of Windows, but there is also a `386` platform available designed for older, 32-bit versions of Windows.
+
+:::info
+There is also a `gogit-windows` file available that was created to help with some [performance problems](https://github.com/go-gitea/gitea/pull/15482) reported by some Windows users on older systems/versions. You should consider using this file if you're experiencing performance issues, and let us know if it improves performance.
+:::
+
+**For macOS**, you should choose `darwin-arm64` if your hardware uses Apple Silicon, or `darwin-amd64` for Intel.
+
+**For FreeBSD**, you should choose `freebsd12-amd64` for 64-bit Intel/AMD platforms.
+
+### Downloading with wget
+
+Copy the commands below and replace the URL within the one you wish to download.
+
+```shell
+wget -O gitea https://dl.gitea.com/gitea/@version@/gitea-@version@-linux-amd64
+chmod +x gitea
+```
+
+Note that the above command will download Gitea @version@ for 64-bit Linux.
+
+## 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-@version@-linux-amd64.sigstore.json --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 hkps://keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
+gpg --verify gitea-@version@-linux-amd64.asc 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
+Many of the following directories can be configured using [Environment Variables](../administration/environment-variables.md) as well!
+Of note, configuring `GITEA_WORK_DIR` will tell Gitea where to base its working directory, as well as ease installation.
+:::
+
+### Prepare environment
+
+Check that Git is installed on the server. If it is not, install it first. Gitea requires Git version >= 2.0.
+
+```sh
+git --version
+```
+
+Create a user to run Gitea (e.g. `git`)
+
+```sh
+# On Ubuntu/Debian:
+adduser \
+   --system \
+   --shell /bin/bash \
+   --gecos 'Git Version Control' \
+   --group \
+   --disabled-password \
+   --home /home/git \
+   git
+
+# On Fedora/RHEL/CentOS:
+groupadd --system git
+adduser \
+   --system \
+   --shell /bin/bash \
+   --comment 'Git Version Control' \
+   --gid git \
+   --home-dir /home/git \
+   --create-home \
+   git
+```
+
+### Create required directory structure
+
+```sh
+mkdir -p /var/lib/gitea/{custom,data,log}
+chown -R git:git /var/lib/gitea/
+chmod -R 750 /var/lib/gitea/
+mkdir /etc/gitea
+chown root:git /etc/gitea
+chmod 770 /etc/gitea
+```
+
+:::note
+> `/etc/gitea` is temporarily set with write permissions for user `git` so that the web installer can write the configuration file. After the installation is finished, it is recommended to set permissions to read-only using:
+:::
+
+>
+> ```sh
+> chmod 750 /etc/gitea
+> chmod 640 /etc/gitea/app.ini
+> ```
+
+If you don't want the web installer to be able to write to the config file, it is possible to make the config file read-only for the Gitea user (owner/group `root:git`, mode `0640`) however you will need to edit your config file manually to:
+
+* Set `INSTALL_LOCK= true`,
+* Ensure all database configuration details are set correctly
+* Ensure that the `SECRET_KEY` and `INTERNAL_TOKEN` values are set. (You may want to use the `gitea generate secret` to generate these secret keys.)
+* Ensure that any other secret keys you need are set.
+
+See the [command line documentation](../administration/command-line.md) for information on using `gitea generate secret`.
+
+### Configure Gitea's working directory
+
+:::note
+If you plan on running Gitea as a Linux service, you can skip this step, as the service file allows you to set `WorkingDirectory`. Otherwise, consider setting this environment variable (semi-)permanently so that Gitea consistently uses the correct working directory.
+:::
+
+```sh
+export GITEA_WORK_DIR=/var/lib/gitea/
+```
+
+### Copy the Gitea binary to a global location
+
+```sh
+cp gitea /usr/local/bin/gitea
+```
+
+
+### Adding shell autocompletion (from 1.25)
+
+Shell completion can be generated directly from binary with:
+```sh
+gitea completion <shell>
+```
+
+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)
+
+### 2. Running from command-line/terminal
+
+```sh
+GITEA_WORK_DIR=/var/lib/gitea/ /usr/local/bin/gitea web -c /etc/gitea/app.ini
+```
+
+## Updating to a new version
+
+You can update to a new version of Gitea by stopping Gitea, replacing the binary at `/usr/local/bin/gitea` and restarting the instance.
+The binary file name should not be changed during the update to avoid problems in existing repositories.
+
+It is recommended that you make a [backup](../administration/backup-and-restore.md) before updating your installation.
+
+If you have carried out the installation steps as described above, the binary should
+have the generic name `gitea`. Do not change this, i.e. to include the version number.
+
+### 1. Restarting Gitea with systemd (recommended)
+
+As we explained before, we recommend to use systemd as the service manager. In this case, `systemctl restart gitea` should be fine.
+
+### 2. Restarting Gitea without systemd
+
+To restart your Gitea instance, we recommend to use SIGHUP signal. If you know your Gitea PID, use `kill -1 $GITEA_PID`, otherwise you can use `killall -1 gitea`.
+
+To gracefully stop the Gitea instance, a simple `kill $GITEA_PID` or `killall gitea` is enough.
+
+:::note
+We don't recommend to use the SIGKILL signal (`-9`); you may be forcefully stopping some of Gitea's internal tasks, and it will not gracefully stop (tasks in queues, indexers, etc.)
+:::
+
+See below for troubleshooting instructions to repair broken repositories after
+an update of your Gitea version.
+
+## Troubleshooting
+
+### Old glibc versions
+
+Older Linux distributions (such as Debian 7 and CentOS 6) may not be able to load the
+Gitea binary, usually producing an error such as `./gitea: /lib/x86_64-linux-gnu/libc.so.6:
+version 'GLIBC\_2.14' not found (required by ./gitea)`. This is due to the integrated
+SQLite support in the binaries provided by dl.gitea.com. In this situation, it is usually
+possible to [install from source](installation/from-source.md), without including
+SQLite support.
+
+### Running Gitea on another port
+
+For errors like `702 runWeb()] [E] Failed to start server: listen tcp 0.0.0.0:3000:
+bind: address already in use`, Gitea needs to be started on another free port. This
+is possible using `./gitea web -p $PORT`. It's possible another instance of Gitea
+is already running.
+
+### Running Gitea on Raspbian
+
+As of v1.8, there is a problem with the arm7 version of Gitea, and it doesn't run on Raspberry Pis and similar devices.
+
+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 */}
+### 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,
+Git Hooks in existing repositories will not work any more. In that case, a Git
+error will be displayed when pushing to the repository.
+
+```
+remote: ./hooks/pre-receive.d/gitea: line 2: [...]: No such file or directory
+```
+
+The `[...]` part of the error message will contain the path to your previous Gitea
+binary.
+
+To solve this, go to the admin options and run the task `Resynchronize pre-receive,
+update and post-receive hooks of all repositories` to update all hooks to contain
+the new binary path. Please note that this overwrites all Git Hooks, including ones
+with customizations made.
+
+If you aren't using the Gitea built-in SSH server, you will also need to re-write
+the authorized key file by running the `Update the '.ssh/authorized_keys' file with
+Gitea SSH keys.` task in the admin options.

docs/installation/from-package.md

@@ -1,18 +1,9 @@
 ---
 date: "2016-12-01T16:00:00+02:00"
-title: "Installation from package"
 slug: "install-from-package"
 sidebar_position: 20
-toc: false
-draft: false
 aliases:
   - /en-us/install-from-package
-menu:
-  sidebar:
-    parent: "installation"
-    name: "From package"
-    sidebar_position: 20
-    identifier: "install-from-package"
 ---
 
 # Installation from Package

docs/installation/from-source.md

@@ -0,0 +1,262 @@
+---
+date: "2016-12-01T16:00:00+02:00"
+slug: "install-from-source"
+sidebar_position: 30
+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
+environment correctly. In particular, it is recommended to set the `$GOPATH`
+environment variable and to add the go bin directory or directories
+`${GOPATH//://bin:}/bin` to the `$PATH`. See the Go wiki entry for
+[GOPATH](https://github.com/golang/go/wiki/GOPATH).
+
+Next, [install Node.js with npm](https://nodejs.org/en/download/) which is
+required to build the JavaScript and CSS files. The minimum supported Node.js
+version is @minNodeVersion@ and the latest LTS version is recommended.
+
+:::note
+Go version @minGoVersion@ or higher is required. However, it is recommended to
+obtain the same version as our continuous integration, see the advice given in
+[Hacking on Gitea](https://github.com/go-gitea/gitea/blob/main/docs/build-setup.md)
+:::
+
+## Download
+
+First, we must retrieve the source code. Since, the advent of go modules, the
+simplest way of doing this is to use Git directly as we no longer have to have
+Gitea built from within the GOPATH.
+
+```bash
+git clone https://github.com/go-gitea/gitea
+```
+
+(Previous versions of this document recommended using `go get`. This is
+no longer necessary.)
+
+Decide which version of Gitea to build and install. Currently, there are
+multiple options to choose from. The `main` branch represents the current
+development version. To build with main, skip to the [build section](#build).
+
+To work with tagged releases, the following commands can be used:
+
+```bash
+git branch -a
+git checkout @sourceBranch@
+```
+
+To validate a Pull Request, first enable the new branch (`xyz` is the PR id;
+for example `2663` for [#2663](https://github.com/go-gitea/gitea/pull/2663)):
+
+```bash
+git fetch origin pull/xyz/head:pr-xyz
+```
+
+To build Gitea from source at a specific tagged release (like @sourceVersion@), list the
+available tags and check out the specific tag.
+
+List available tags with the following.
+
+```bash
+git tag -l
+git checkout @sourceVersion@  # or git checkout pr-xyz
+```
+
+## Build
+
+To build from source, the following programs must be present on the system:
+
+- `go` @minGoVersion@ or higher, see [here](https://go.dev/dl/)
+- `node` @minNodeVersion@ or higher with `npm`, see [here](https://nodejs.org/en/download/)
+- `make`, see [here](https://github.com/go-gitea/gitea/blob/main/docs/build-setup.md#make)
+
+Various [make tasks](https://github.com/go-gitea/gitea/blob/main/Makefile)
+are provided to keep the build process as simple as possible.
+
+Depending on requirements, the following build tags can be included.
+
+- `bindata`: Build a single monolithic binary, with all assets included. Required for production build.
+- `sqlite sqlite_unlock_notify`: Enable support for a
+  [SQLite3](https://sqlite.org/) database. Suggested only for tiny
+  installations.
+- `pam`: Enable support for PAM (Linux Pluggable Authentication Modules). Can
+  be used to authenticate local users or extend authentication to methods
+  available to PAM.
+- `gogit`: (EXPERIMENTAL) Use go-git variants of Git commands.
+
+Bundling all assets (JS/CSS/templates, etc) into the binary. Using the `bindata` build tag is required for
+production deployments. You could exclude `bindata` when you are developing/testing Gitea or able to separate the assets correctly.
+
+To include all assets, use the `bindata` tag:
+
+```bash
+TAGS="bindata" make build
+```
+
+In the default release build of our continuous integration system, the build
+tags are: `TAGS="bindata sqlite sqlite_unlock_notify"`. The simplest
+recommended way to build from source is therefore:
+
+```bash
+TAGS="bindata sqlite sqlite_unlock_notify" make build
+```
+
+The `build` target is split into two sub-targets:
+
+- `make backend` which requires [Go @minGoVersion@](https://go.dev/dl/) or greater.
+- `make frontend` which requires [Node.js @minNodeVersion@](https://nodejs.org/en/download/) or greater.
+
+If pre-built frontend files are present it is possible to only build the backend:
+
+```bash
+TAGS="bindata" make backend
+```
+
+## Test
+
+After following the steps above, a `gitea` binary will be available in the working directory.
+It can be tested from this directory or moved to a directory with test data. When Gitea is
+launched manually from command line, it can be killed by pressing `Ctrl + C`.
+
+```bash
+./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
+the `custom/` directory in the current working directory when running Gitea. It will also
+look for its configuration file _`CustomConf`_ in `$(CustomPath)/conf/app.ini`, and will use the
+current working directory as the relative base path _`AppWorkPath`_ for a number configurable
+values. Finally the static files will be served from _`StaticRootPath`_ which defaults to the _`AppWorkPath`_.
+
+These values, although useful when developing, may conflict with downstream users preferences.
+
+One option is to use a script file to shadow the `gitea` binary and create an appropriate
+environment before running Gitea. However, when building you can change these defaults
+using the `LDFLAGS` environment variable for `make`. The appropriate settings are as follows
+
+- To set the _`CustomPath`_ use `LDFLAGS="-X \"code.gitea.io/gitea/modules/setting.CustomPath=custom-path\""`
+- For _`CustomConf`_ you should use `-X \"code.gitea.io/gitea/modules/setting.CustomConf=conf.ini\"`
+- For _`AppWorkPath`_ you should use `-X \"code.gitea.io/gitea/modules/setting.AppWorkPath=working-path\"`
+- For _`StaticRootPath`_ you should use `-X \"code.gitea.io/gitea/modules/setting.StaticRootPath=static-root-path\"`
+- To change the default PID file location use `-X \"code.gitea.io/gitea/cmd.PIDFile=/run/gitea.pid\"`
+
+Add as many of the strings with their preceding `-X` to the `LDFLAGS` variable and run `make build`
+with the appropriate `TAGS` as above.
+
+Running `gitea help` will allow you to review what the computed settings will be for your `gitea`.
+
+## Cross Build
+
+The `go` compiler toolchain supports cross-compiling to different architecture targets that are supported by the toolchain. See [`GOOS` and `GOARCH` environment variable](https://go.dev/doc/install/source#environment) for the list of supported targets. Cross compilation is helpful if you want to build Gitea for less-powerful systems (such as Raspberry Pi).
+
+To cross build Gitea with build tags (`TAGS`), you also need a C cross compiler which targets the same architecture as selected by the `GOOS` and `GOARCH` variables. For example, to cross build for Linux ARM64 (`GOOS=linux` and `GOARCH=arm64`), you need the `aarch64-unknown-linux-gnu-gcc` cross compiler. This is required because Gitea build tags uses `cgo`'s foreign-function interface (FFI).
+
+Cross-build Gitea for Linux ARM64, without any tags:
+
+```
+GOOS=linux GOARCH=arm64 make build
+```
+
+Cross-build Gitea for Linux ARM64, with recommended build tags:
+
+```
+CC=aarch64-unknown-linux-gnu-gcc GOOS=linux GOARCH=arm64 TAGS="bindata sqlite sqlite_unlock_notify" make build
+```
+
+Replace `CC`, `GOOS`, and `GOARCH` as appropriate for your architecture target.
+
+You will sometimes need to build a static compiled image. To do this you will need to add:
+
+```
+LDFLAGS="-linkmode external -extldflags '-static' $LDFLAGS" TAGS="netgo osusergo $TAGS" make build
+```
+
+This can be combined with `CC`, `GOOS`, and `GOARCH` as above.
+
+### Adding shell autocompletion (from 1.25)
+
+Shell completion can be generated directly from binary with:
+```sh
+gitea completion <shell>
+```
+
+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.
+
+## Compile or cross-compile using Linux with Zig
+
+Follow [Getting Started of Zig](https://ziglang.org/learn/getting-started/#installing-zig) to install zig.
+
+- Compile (Linux ➝ Linux)
+
+```sh
+CC="zig cc -target x86_64-linux-gnu" \
+CGO_ENABLED=1 \
+CGO_CFLAGS="-O2 -g -pthread" \
+CGO_LDFLAGS="-linkmode=external -v"
+GOOS=linux \
+GOARCH=amd64 \
+TAGS="bindata sqlite sqlite_unlock_notify" \
+make build
+```
+
+- Cross-compile (Linux ➝ Windows)
+
+```sh
+CC="zig cc -target x86_64-windows-gnu" \
+CGO_ENABLED=1 \
+CGO_CFLAGS="-O2 -g -pthread" \
+GOOS=windows \
+GOARCH=amd64 \
+TAGS="bindata sqlite sqlite_unlock_notify" \
+make build
+```
+
+## Compile or cross-compile with Zig using Windows
+
+Compile with `GIT BASH`.
+
+- Compile (Windows ➝ Windows)
+
+```sh
+CC="zig cc -target x86_64-windows-gnu" \
+CGO_ENABLED=1 \
+CGO_CFLAGS="-O2 -g -pthread" \
+GOOS=windows \
+GOARCH=amd64 \
+TAGS="bindata sqlite sqlite_unlock_notify" \
+make build
+```
+
+- Cross-compile (Windows ➝ Linux)
+
+```sh
+CC="zig cc -target x86_64-linux-gnu" \
+CGO_ENABLED=1 \
+CGO_CFLAGS="-O2 -g -pthread" \
+CGO_LDFLAGS="-linkmode=external -v"
+GOOS=linux \
+GOARCH=amd64 \
+TAGS="bindata sqlite sqlite_unlock_notify" \
+make build
+```
+
+## Source Maps
+
+By default, gitea generates reduced source maps for frontend files to conserve space. This can be controlled with the `ENABLE_SOURCEMAP` environment variable:
+
+- `ENABLE_SOURCEMAP=true` generates all source maps, the default for development builds
+- `ENABLE_SOURCEMAP=reduced` generates limited source maps, the default for production builds
+- `ENABLE_SOURCEMAP=false` generates no source maps

docs/installation/on-kubernetes.md

@@ -1,21 +1,12 @@
 ---
 date: "2020-03-19T19:27:00+02:00"
-title: "Install on Kubernetes"
 slug: "install-on-kubernetes"
 sidebar_position: 80
-toc: false
-draft: false
 aliases:
   - /en-us/install-on-kubernetes
-menu:
-  sidebar:
-    parent: "installation"
-    name: "Kubernetes"
-    sidebar_position: 80
-    identifier: "install-on-kubernetes"
 ---
 
-# Installation with Helm (on Kubernetes)
+# Install on Kubernetes
 
 Gitea provides a Helm Chart to allow for installation on kubernetes.
 
@@ -46,7 +37,7 @@ Gitea comes with a health check endpoint `/api/healthz`, you can configure it in
 
 a successful health check response will respond with http code `200`, here's example:
 
-```
+```json
 HTTP/1.1 200 OK
 
 {

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

@@ -0,0 +1,68 @@
+---
+date: "2017-07-21T12:00:00+02:00"
+slug: "linux-service"
+sidebar_position: 40
+aliases:
+  - /en-us/linux-service
+---
+
+# Run as a Linux service
+
+You can run Gitea as a Linux service, using either systemd or supervisor. The steps below tested on Ubuntu 16.04, but those should work on any Linux distributions (with little modification).
+
+## Using systemd
+
+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.
+
+Change the user, home directory, and other required startup values. Change the
+PORT or remove the -p flag if default port is used.
+
+Enable and start Gitea at boot:
+
+```
+sudo systemctl enable gitea
+sudo systemctl start gitea
+```
+
+If you have systemd version 220 or later, you can enable and immediately start Gitea at once by:
+
+```
+sudo systemctl enable gitea --now
+```
+
+## Using supervisor
+
+Install supervisor by running below command in terminal:
+
+```
+sudo apt install supervisor
+```
+
+Create a log dir for the supervisor logs:
+
+```
+# assuming Gitea is installed in /home/git/gitea/
+mkdir /home/git/gitea/log/supervisor
+```
+
+Append the configuration from the sample
+[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
+or remove the -p flag if default port is used.
+
+Lastly enable and start supervisor at boot:
+
+```
+sudo systemctl enable supervisor
+sudo systemctl start supervisor
+```
+
+If you have systemd version 220 or later, you can enable and immediately start supervisor by:
+
+```
+sudo systemctl enable supervisor --now
+```

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/upgrade-from-gitea.md

@@ -1,18 +1,9 @@
 ---
 date: "2021-09-02T16:00:00+08:00"
-title: "Upgrade from an old Gitea"
 slug: "upgrade-from-gitea"
 sidebar_position: 100
-toc: false
-draft: false
 aliases:
   - /en-us/upgrade-from-gitea
-menu:
-  sidebar:
-    parent: "installation"
-    name: "Upgrade From Old Gitea"
-    sidebar_position: 100
-    identifier: "upgrade-from-gitea"
 ---
 
 # Upgrade from an old Gitea

docs/installation/windows-service.md

@@ -1,26 +1,18 @@
 ---
 date: "2016-12-21T15:00:00-02:00"
-title: "Register as a Windows service"
 slug: "windows-service"
 sidebar_position: 50
-toc: false
-draft: false
 aliases:
   - /en-us/windows-service
-menu:
-  sidebar:
-    parent: "installation"
-    name: "Windows Service"
-    sidebar_position: 50
-    identifier: "windows-service"
 ---
+
 # Register as a Windows service
 
 ## Prerequisites
 
 The following changes are made in C:\gitea\custom\conf\app.ini:
 
-```
+```ini title="app.ini"
 RUN_USER = COMPUTERNAME$
 ```
 
@@ -32,7 +24,7 @@ COMPUTERNAME is whatever the response is from `echo %COMPUTERNAME%` on the comma
 
 If you use SQLite3, change the `PATH` to include the full path:
 
-```
+```ini title="app.ini"
 [database]
 PATH     = c:/gitea/data/gitea.db
 ```
@@ -42,7 +34,7 @@ PATH     = c:/gitea/data/gitea.db
 To register Gitea as a Windows service, open a command prompt (cmd) as an Administrator,
 then run the following command:
 
-```
+```sh
 sc.exe create gitea start= auto binPath= "\"C:\gitea\gitea.exe\" web --config \"C:\gitea\custom\conf\app.ini\""
 ```
 
@@ -57,7 +49,7 @@ that was configured).
 It was observed that on loaded systems during boot Gitea service may fail to start with timeout records in Windows Event Log.
 In that case change startup type to `Automatic-Delayed`. This can be done during service creation, or by running config command
 
-```
+```sh
 sc.exe config gitea start= delayed-auto
 ```
 
@@ -65,7 +57,7 @@ sc.exe config gitea start= delayed-auto
 
 To add a startup dependency to the Gitea Windows service (eg Mysql, Mariadb), as an Administrator, then run the following command:
 
-```
+```sh
 sc.exe config gitea depend= mariadb
 ```
 
@@ -75,6 +67,6 @@ This will ensure that when the Windows machine restarts, the automatic starting
 
 To unregister Gitea as a Windows service, open a command prompt (cmd) as an Administrator and run:
 
-```
+```sh
 sc.exe delete gitea
 ```

docs/installation/with-docker-rootless.md

@@ -0,0 +1,123 @@
+---
+date: "2020-02-09T20:00:00+02:00"
+slug: "install-with-docker-rootless"
+sidebar_position: 60
+aliases:
+  - /en-us/install-with-docker-rootless
+---
+
+# Installation with Docker (rootless)
+
+## Relation to rootful image
+
+* 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.
+
+Except the differences above, the rootless image shares the same mechanism with rootful image,
+including: port mapping, custimzation, upgrading, environment variables, etc.
+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.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`:
+
+```sh
+mkdir -p gitea/{data,config}
+cd gitea
+touch docker-compose.yml
+```
+
+Then paste the following content into a file named `docker-compose.yml`:
+
+```yaml
+services:
+  server:
+    image: docker.gitea.com/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"
+```
+
+Note that the volume should be owned by the user/group with the UID/GID specified in the config file. By default Gitea in docker will use uid:1000 gid:1000. If needed you can set ownership on those folders with the command:
+
+```sh
+sudo chown 1000:1000 config/ data/
+```
+
+> If you don't give the volume correct permissions, the container may present the following errors in the logs:
+
+```sh
+server-1  | 2026-03-11T12:57:50.794102045Z mkdir: can't create directory '/var/lib/gitea/git': Permission denied
+server-1  | 2026-03-11T12:57:50.796198843Z /var/lib/gitea/git is not writable
+server-1  | 2026-03-11T12:57:50.796235667Z docker setup failed
+```
+
+For a stable release you could use `:latest-rootless`, `:1-rootless` or specify a certain release like `:@dockerVersion@-rootless`, but if you'd like to use the latest development version then `:main-nightly-rootless` would be an appropriate tag. If you'd like to run the latest commit from a release branch you can use the `:1.x-nightly-rootless` tag, where x is the minor version of Gitea. (e.g. `:1.27-nightly-rootless`)
+
+## Named volumes
+
+To use named volumes instead of host volumes, define and use the named volume
+within the `docker-compose.yml` configuration. This change will automatically
+create the required volume. You don't need to worry about permissions with
+named volumes; Docker will deal with that automatically.
+
+```diff
++volumes:
++  gitea-data:
++    driver: local
++  gitea-config:
++    driver: local
++
+services:
+  server:
+    image: docker.gitea.com/gitea:@dockerVersion@-rootless
+    restart: always
+    volumes:
+-      - ./data:/var/lib/gitea
++      - gitea-data:/var/lib/gitea
+-      - ./config:/etc/gitea
++      - gitea-config:/etc/gitea
+      - /etc/timezone:/etc/timezone:ro
+      - /etc/localtime:/etc/localtime:ro
+    ports:
+      - "3000:3000"
+      - "2222:2222"
+```
+
+MySQL or PostgreSQL containers will need to be created separately.
+
+## Custom user
+
+You can choose to use a custom user (following --user flag definition https://docs.docker.com/engine/reference/run/#user).
+As an example to clone the host user `git` definition use the command `id -u git` and add it to `docker-compose.yml` file:
+Please make sure that the mounted folders are writable by the user.
+
+```diff
+services:
+  server:
+    image: docker.gitea.com/gitea:@dockerVersion@-rootless
+    restart: always
++    user: 1001
+    volumes:
+      - ./data:/var/lib/gitea
+      - ./config:/etc/gitea
+      - /etc/timezone:/etc/timezone:ro
+      - /etc/localtime:/etc/localtime:ro
+    ports:
+      - "3000:3000"
+      - "2222:2222"
+```

docs/installation/with-docker.md

@@ -0,0 +1,336 @@
+---
+date: "2020-03-19T19:27:00+02:00"
+slug: "install-with-docker"
+sidebar_position: 70
+aliases:
+  - /en-us/install-with-docker
+---
+
+# Installation with Docker
+
+Gitea provides automatically updated Docker images within its Docker Hub organization. It is
+possible to always use the latest stable tag or to use another service that handles updating
+Docker images.
+
+This reference setup guides users through the setup based on `docker compose`.
+Docker compose has been included in the Docker Engine since the shift to Compose v2.
+If, for some reason, compose is not available on your system, follow the official [install instructions](https://docs.docker.com/compose/install/).
+
+This document targets for the default rootful image. For the rootless image,
+see "[Installation with Docker (rootless)](./with-docker-rootless.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.gitea.com/gitea:latest`
+image as a service. Since there is no database available, one can be initialized using SQLite3.
+Create a directory like `gitea` and paste the following content into a file named `docker-compose.yml`.
+Note that the volume should be owned by the user/group with the UID/GID specified in the config file.
+If you don't give the volume correct permissions, the container may not start.
+For a stable release you can use `:latest`, `:1` or specify a certain release like `:@dockerVersion@`, but if you'd like to use the latest development version of Gitea then you could use the `:main-nightly` tag. If you'd like to run the latest commit from a release branch you can use the `:1.x-nightly` tag, where x is the minor version of Gitea. (e.g. `:1.27-nightly`)
+
+```yaml
+networks:
+  gitea:
+    external: false
+
+services:
+  server:
+    image: docker.gitea.com/gitea:@dockerVersion@
+    container_name: gitea
+    environment:
+      - USER_UID=1000
+      - USER_GID=1000
+    restart: always
+    networks:
+      - gitea
+    volumes:
+      - ./gitea:/data
+      - /etc/timezone:/etc/timezone:ro
+      - /etc/localtime:/etc/localtime:ro
+    ports:
+      - "3000:3000"
+      - "222:22"
+```
+
+## Ports
+
+To bind the integrated OpenSSH daemon 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
+networks:
+  gitea:
+    external: false
+
+services:
+  server:
+    image: docker.gitea.com/gitea:@dockerVersion@
+    container_name: gitea
+    environment:
+      - USER_UID=1000
+      - USER_GID=1000
+    restart: always
+    networks:
+      - gitea
+    volumes:
+      - ./gitea:/data
+      - /etc/timezone:/etc/timezone:ro
+      - /etc/localtime:/etc/localtime:ro
+    ports:
+-     - "3000:3000"
+-     - "222:22"
++     - "8080:3000"
++     - "2221:22"
+```
+
+## Databases
+
+### MySQL database
+
+To start Gitea in combination with a MySQL database, apply these changes to the
+`docker-compose.yml` file created above.
+
+```diff
+networks:
+  gitea:
+    external: false
+
+services:
+  server:
+    image: docker.gitea.com/gitea:@dockerVersion@
+    container_name: gitea
+    environment:
+      - USER_UID=1000
+      - USER_GID=1000
++      - GITEA__database__DB_TYPE=mysql
++      - GITEA__database__HOST=db:3306
++      - GITEA__database__NAME=gitea
++      - GITEA__database__USER=gitea
++      - GITEA__database__PASSWD=gitea
+    restart: always
+    networks:
+      - gitea
+    volumes:
+      - ./gitea:/data
+      - /etc/timezone:/etc/timezone:ro
+      - /etc/localtime:/etc/localtime:ro
+    ports:
+      - "3000:3000"
+      - "222:22"
++    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
++    networks:
++      - 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.
+
+:::note
+The example pins a major version on purpose: PostgreSQL does not upgrade its data
+directory on its own, moving to a newer major version later requires `pg_upgrade`
+or a dump and restore. Start a new instance on the newest version Gitea supports,
+see [database preparation](database-preparation.md) for the supported versions.
+:::
+
+```diff
+networks:
+  gitea:
+    external: false
+
+services:
+  server:
+    image: docker.gitea.com/gitea:@dockerVersion@
+    container_name: gitea
+    environment:
+      - USER_UID=1000
+      - USER_GID=1000
++      - GITEA__database__DB_TYPE=postgres
++      - GITEA__database__HOST=db:5432
++      - GITEA__database__NAME=gitea
++      - GITEA__database__USER=gitea
++      - GITEA__database__PASSWD=gitea
+    restart: always
+    networks:
+      - gitea
+    volumes:
+      - ./gitea:/data
+      - /etc/timezone:/etc/timezone:ro
+      - /etc/localtime:/etc/localtime:ro
+    ports:
+      - "3000:3000"
+      - "222:22"
++    depends_on:
++      - db
++
++  db:
++    image: docker.io/library/postgres:18
++    restart: always
++    environment:
++      - POSTGRES_USER=gitea
++      - POSTGRES_PASSWORD=gitea
++      - POSTGRES_DB=gitea
++    networks:
++      - gitea
++    volumes:
++      - ./postgres:/var/lib/postgresql
+```
+
+## Named volumes
+
+To use named volumes instead of host volumes, define and use the named volume
+within the `docker-compose.yml` configuration. This change will automatically
+create the required volume. You don't need to worry about permissions with
+named volumes; Docker will deal with that automatically.
+
+```diff
+networks:
+  gitea:
+    external: false
+
++volumes:
++  gitea:
++    driver: local
++
+services:
+  server:
+    image: docker.gitea.com/gitea:@dockerVersion@
+    container_name: gitea
+    restart: always
+    networks:
+      - gitea
+    volumes:
+-      - ./gitea:/data
++      - gitea:/data
+      - /etc/timezone:/etc/timezone:ro
+      - /etc/localtime:/etc/localtime:ro
+    ports:
+      - "3000:3000"
+      - "222:22"
+```
+
+MySQL or PostgreSQL containers will need to be created separately.
+
+## Startup
+
+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/`.
+:::
+
+## Installation
+
+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.
+
+## Configure the user inside Gitea using environment variables
+
+- `USER`: **git**: The username of the user that runs Gitea within the container.
+- `USER_UID`: **1000**: The UID (Unix user ID) of the user that runs Gitea within the container. Match this to the UID of the owner of the `/data` volume if using host volumes (this is not necessary with named volumes).
+- `USER_GID`: **1000**: The GID (Unix group ID) of the user that runs Gitea within the container. Match this to the GID of the owner of the `/data` volume if using host volumes (this is not necessary with named volumes).
+
+## Customization
+
+Customization files described [here](../administration/customizing-gitea.md) should
+be placed in `/data/gitea` 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/_data`. The configuration file will be saved at
+`/data/gitea/conf/app.ini` after the installation.
+
+Example: Analogous to the non-docker-installation customization linked above, you can create a `/public` folder within `/data/gitea` and place your custom `robots.txt` there which will then be served normally.
+
+## Upgrading
+
+:::warning
+Make sure you have volumed data to somewhere outside Docker container
+:::
+
+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
+```
+
+## 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=value`.
+These settings are applied each time the docker container starts by `environment-to-ini` command
+(a warpper of `gitea config edit-ini`), and won't be passed into Gitea's sub-processes.
+See `./gitea config edit-ini --help` for more details.
+
+These environment variables can be passed to the docker container in `docker-compose.yml`.
+The following example will enable an 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.
+
+```yaml
+...
+services:
+  server:
+    environment:
+      - GITEA__mailer__ENABLED=true
+      - GITEA__mailer__FROM=${GITEA__mailer__FROM:?GITEA__mailer__FROM not set}
+      - GITEA__mailer__PROTOCOL=smtps
+      - GITEA__mailer__SMTP_ADDR=${GITEA__mailer__SMTP_ADDR:?GITEA__mailer__SMTP_ADDR not set}
+      - GITEA__mailer__SMTP_PORT=${GITEA__mailer__SMTP_PORT:?GITEA__mailer__SMTP_PORT not set}
+      - GITEA__mailer__USER=${GITEA__mailer__USER:-apikey}
+      - GITEA__mailer__PASSWD="""${GITEA__mailer__PASSWD:?GITEA__mailer__PASSWD not set}"""
+```
+
+Gitea will generate new secrets/tokens for every new installation automatically and write them into the app.ini. If you want to set the secrets/tokens manually, you can use the following docker commands to use of Gitea's built-in [generate utility functions](../administration/command-line.md#generate). Do not lose/change your SECRET_KEY after the installation, otherwise the encrypted data can not be decrypted anymore.
+
+The following commands will output a new `SECRET_KEY` and `INTERNAL_TOKEN` to `stdout`, which you can then place in your environment variables.
+
+```bash
+docker run -it --rm docker.gitea.com/gitea:1 gitea generate secret SECRET_KEY
+docker run -it --rm docker.gitea.com/gitea:1 gitea generate secret INTERNAL_TOKEN
+```
+
+```yaml
+...
+services:
+  server:
+    environment:
+      - GITEA__security__SECRET_KEY=[value returned by generate secret SECRET_KEY]
+      - GITEA__security__INTERNAL_TOKEN=[value returned by generate secret INTERNAL_TOKEN]
+```
+
+### SSH with multiple IP addresses
+
+This assumes that the host machine has more than one reachable IP address: `192.168.1.1` (host) `192.168.1.2` (gitea)
+On the host machine, configure SSHD in `/etc/ssh/sshd_config` to listen on one IP address `ListenAddress 192.168.1.1`. In the compose file the SSH port forwarding then needs to be changed to `"192.168.1.2:22:22"`. The port forwarding needs to be adjusted similarily for all other forwarded ports to avoid problems with DNS.

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)

docs/usage/access-control/permissions.md

@@ -1,18 +1,10 @@
 ---
 date: "2021-12-13:10:10+08:00"
-title: "Permissions"
 slug: "permissions"
 sidebar_position: 14
-toc: false
-draft: false
 aliases:
   - /en-us/permissions
-menu:
-  sidebar:
-    parent: "usage"
-    name: "Permissions"
-    sidebar_position: 14
-    identifier: "permissions"
+  - /permissions
 ---
 
 # Permissions

docs/usage/access-control/protected-branches.md

@@ -0,0 +1,102 @@
+---
+date: "2025-11-20T00:00:00-07:00"
+slug: "protected-branches"
+sidebar_position: 44
+aliases:
+  - /en-us/protected-branches
+  - /en-us/protected-branch
+  - /protected-branches
+---
+
+# Protected branches
+
+Protected branches prevent unwanted changes by enforcing push, deletion, and merge policies on selected branches. The rules are enforced for every Git protocol (HTTP(S), SSH), the web editor, the API, and background jobs such as auto-merge. Only repository owners and administrators can manage the rules, and the Branches page is read-only while a repository is archived.
+
+## Creating or editing a rule
+
+1. Open the repository and select **Settings → Branches** (repository admin permission required).
+2. Select **Add new rule** or **Edit** next to an existing rule.
+3. Fill in the **Protected branch name pattern** and optional file patterns, then configure the push, deletion, merge, and review options described below.
+4. Select **Save rule**.
+
+The rule immediately applies to all matching branches, even if the branches are created in the future.
+
+## Rule matching and priorities
+
+- The **Protected branch name pattern** accepts [glob](https://github.com/gobwas/glob) expressions and matches the entire branch name. Patterns are case-sensitive. Using a simple name such as `main` without glob special characters always matches that specific branch (case-insensitive).
+- If multiple rules match the same branch, only the first rule is used. Reorder the list on the **Branches** page by dragging the grab handle. The first entry (priority 1) has the highest priority, so place patterns such as `main` or `release/*` before generic fallbacks such as `*`.
+
+Example patterns:
+
+| Pattern        | Matches                         |
+| -------------- | ------------------------------- |
+| `main`         | The `main` branch only          |
+| `release/*`    | `release/v1.0`, `release/april` |
+| `hotfix/**`    | Nested branches such as `hotfix/security/CVE` |
+| `*`            | Every branch (use as a fallback) |
+
+### File-level pattern controls
+
+- **Protected file patterns** block changes to sensitive files (for example `.drone.yml` or `/docs/**/*.txt`). Patterns are case-insensitive and separated by semicolons. Commits and merge attempts that touch one of the files are rejected.
+- **Unprotected file patterns** do the opposite: if pushes are blocked, users with write access can still push commits that modify only the listed files. This is useful for letting contributors update documentation while still requiring pull requests for code.
+
+Both fields use the same `glob` syntax and match paths relative to the repository root.
+
+## Controlling direct pushes
+
+The **Push** section controls direct pushes (including the web editor and API).
+
+- **Disable push** makes the branch read-only. Any attempt to push directly fails, and changes must be merged through pull requests.
+- **Enable push** allows anyone with [write access](./permissions.md) to push (force pushes are still blocked unless explicitly allowed).
+- **Allowlist restricted push** requires being on the allowlist. Choose users and, for organization-owned repositories, teams.
+
+The user allowlists for push, force-push and deletion can include the **Gitea Actions** and **Deploy Key** system users. They still require write access; **Deploy Key** also covers deploy tokens.
+
+When a push is blocked, the server-side hook rejects the update with an explanation.
+
+### Force pushes
+
+Force pushes have their own set of options:
+
+- **Disable force push** completely forbids rewriting history on the branch.
+- **Enable force push** allows anyone who can push to also force push.
+- **Allowlist restricted force push** limits force pushes to a separate allowlist of users or teams **and** requires regular push access.
+
+## Branch deletion
+
+The **Branch Deletion** section controls whether matching protected branches can be deleted:
+
+- **Disable branch deletion** prevents deletion. This is the default.
+- **Enable branch deletion** allows anyone who can push to delete the branch.
+- **Allowlist restricted branch deletion** limits deletion to a separate allowlist of users or teams **and** requires regular push access.
+
+These rules apply to Git (`git push --delete`), the API, the web interface and post-merge cleanup. The default branch and configured default pull request target branch cannot be deleted.
+
+## Pull request merges and approvals
+
+- **Merge allowlist**: keep the default to let anyone with write access merge pull requests, or enable the allowlist to restrict merges to selected users/teams.
+- **Required approvals**: specify how many approvals are needed before a merge is allowed. Reviews from users with write access count, unless the **Restrict approvals to allowlisted users or teams** option is enabled.
+- **Dismiss stale approvals** removes existing approvals whenever new commits that change the pull request content are pushed.
+- **Ignore stale approvals** keeps approvals but does not count reviews that were made on older commits. This option is disabled while dismissal of stale approvals is enabled.
+- **Block merge on rejected reviews** prevents merging while any official reviewer has requested changes.
+- **Block merge on official review requests** blocks merges while there are outstanding review requests (for example when CODEOWNERS requires a review).
+- **Block merge if the pull request is outdated** makes sure the head branch is up to date with the base branch before it can be merged.
+- **Administrators must follow branch protection rules** removes the ability for repository administrators to bypass the rules with the "Force merge" button.
+
+Protected file patterns apply to pull requests as well. When a pull request changes one of the protected files, the pull request banner shows the affected paths and merging stays disabled.
+
+## Status checks
+
+Enable status checks to require one or more CI jobs to succeed before merging:
+
+1. Check **Enable status check**.
+2. Enter one pattern per line in **Status check patterns**. Each pattern is a `glob` expression that matches the context name reported by Actions, Drone, Woodpecker, or another Check API client (for example `actions/test-*`).
+3. Pick contexts from the table of jobs that have reported results in the last week to verify their names.
+
+When the option is active, Gitea requires at least one context that matches each pattern to report success on the pull request head commit. An empty list is not allowed; use `*` to require the latest commit to be successful regardless of the context name.
+
+## Signed commits and other safeguards
+
+- **Require signed commits** rejects pushes that contain unsigned or unverifiable commits. The check runs inside the server hook before the push is accepted.
+- **Protected file patterns** (see above) prevent both pushes and merges that modify sensitive files.
+- **Unprotected file patterns** allow limited pushes while keeping the branch protected.

docs/usage/access-control/protected-tags.md

@@ -1,18 +1,10 @@
 ---
 date: "2021-05-14T00:00:00-00:00"
-title: "Protected tags"
 slug: "protected-tags"
 sidebar_position: 45
-toc: false
-draft: false
 aliases:
   - /en-us/protected-tags
-menu:
-  sidebar:
-    parent: "usage"
-    name: "Protected tags"
-    sidebar_position: 45
-    identifier: "protected-tags"
+  - /protected-tags
 ---
 
 # Protected tags

docs/usage/actions/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Actions",
+  "position": 30,
+  "link": {
+    "type": "generated-index",
+    "slug": "/usage/actions",
+    "description": "Automating workflows with Actions"
+  }
+}

docs/usage/actions/artifacts.md

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

docs/usage/actions/badge.md

@@ -1,18 +1,7 @@
 ---
 date: "2023-02-25T00:00:00+00:00"
-title: "Badge"
 slug: "badge"
-sidebar_position: 11
-toc: false
-draft: false
-aliases:
-  - /en-us/badge
-menu:
-  sidebar:
-    parent: "usage"
-    name: "Badge"
-    sidebar_position: 11
-    identifier: "Badge"
+sidebar_position: 110
 ---
 
 # Badge
@@ -27,7 +16,7 @@ It is designed to be compatible with [GitHub Actions workflow badge](https://doc
 You can use the following URL to get the badge:
 
 ```
-https://your-gitea-instance.com/{owner}/{repo}/actions/workflows/{workflow_file}?branch={branch}&event={event}
+https://your-gitea-instance.com/{owner}/{repo}/actions/workflows/{workflow_file}/badge.svg?branch={branch}&event={event}&style={style}
 ```
 
 - `{owner}`: The owner of the repository.
@@ -35,3 +24,4 @@ https://your-gitea-instance.com/{owner}/{repo}/actions/workflows/{workflow_file}
 - `{workflow_file}`: The name of the workflow file.
 - `{branch}`: Optional. The branch of the workflow. Default to your repository's default branch.
 - `{event}`: Optional. The event of the workflow. Default to none.
+- `{style}`: Optional. Style of the badge, either `flat` or `flat-square`. Default to `flat`.

docs/usage/actions/comparison.md

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

docs/usage/actions/design.md

@@ -0,0 +1,98 @@
+---
+date: "2023-04-27T15:00:00+08:00"
+slug: "design"
+sidebar_position: 140
+---
+
+# Design of Gitea Actions
+
+Gitea Actions has multiple components. This document describes them individually.
+
+## Gitea Runner
+
+Gitea Runner is based on a hard fork of [nektos/act](https://github.com/nektos/act).
+
+Like other CI runners, we designed it as an external part of Gitea, which means it should run on a different server than Gitea.
+
+To ensure that the runner connects to the correct Gitea instance, we need to register it with a token.
+Additionally, the runner will introduce itself to Gitea and declare what kind of jobs it can run by reporting its labels.
+
+Earlier, we mentioned that `runs-on: ubuntu-latest` in a workflow file means that the job will be run on a runner with the `ubuntu-latest` label.
+But how does the runner know to run `ubuntu-latest`? The answer lies in mapping the label to an environment.
+That's why each label of a runner names an environment, like `my_custom_label:docker://centos:7`.
+This means that the runner can take the job which needs to run on `my_custom_label`, and it will run it via a docker container with the image `centos:7`.
+
+Docker isn't the only option, though.
+The runner also supports running jobs directly on the host.
+This is achieved through labels like `linux_arm:host`.
+This label indicates that the runner can take a job that needs to run on `linux_arm` and run it directly on the host.
+
+The label's design follows the format `label[:schema[:args]]`.
+If the schema is omitted, it defaults to `host`.
+So,
+
+- `my_custom_label:docker://node:18`: Run jobs labeled with `my_custom_label` using the `node:18` Docker image.
+- `my_custom_label:host`: Run jobs labeled with `my_custom_label` directly on the host.
+- `my_custom_label`: Same as `my_custom_label:host`.
+
+## Communication protocol
+
+As the runner is an independent part of Gitea, we needed a protocol for runners to communicate with the Gitea instance.
+However, we did not think it was a good idea to have Gitea listen on a new port.
+Instead, we wanted to reuse the HTTP port, which means we needed a protocol that is compatible with HTTP.
+We chose to use gRPC over HTTP.
+
+The protocol is defined in [actions-proto-def](https://gitea.com/gitea/actions-proto-def), its Go code lives in [actionslib](https://gitea.com/gitea/actionslib).
+More information about gRPC can be found on [its website](https://grpc.io/).
+
+## Network architecture
+
+Let's examine the overall network architecture.
+This will help you troubleshoot some problems and explain why it's a bad idea to register a runner with a loopback address of the Gitea instance.
+
+![network](/images/usage/actions/network.png)
+
+There are four network connections marked in the picture, and the direction of the arrows indicates the direction of establishing the connections.
+
+### Connection 1, runner to Gitea instance
+
+The runner must be able to connect to Gitea to receive tasks and send back the execution results.
+
+### Connection 2, job containers to Gitea instance
+
+The job containers have different network namespaces than the runner, even if they are on the same machine.
+They need to connect to Gitea to fetch codes if there is `actions/checkout@v4` in the workflow, for example.
+Fetching code is not always necessary to run some jobs, but it is required in most cases.
+
+If you use a loopback address to register a runner, the runner can connect to Gitea when it is on the same machine.
+However, if a job container tries to fetch code from localhost, it will fail because Gitea is not in the same container.
+
+### Connection 3, runner to internet
+
+When you use some actions like `actions/checkout@v4`, the runner downloads the scripts, not the job containers.
+By default, it downloads them from [github.com](https://github.com/), which requires internet access.
+With `DEFAULT_ACTIONS_URL` set to `self`, or with `uses: self:owner/repo@ref`, it downloads them from your Gitea instance instead.
+It also downloads some docker images from Docker Hub by default, which also requires internet access.
+
+However, internet access is not strictly necessary.
+You can configure your Gitea instance to fetch actions or images from your intranet facilities.
+
+In fact, your Gitea instance can serve as both the actions marketplace and the image registry.
+You can mirror actions repositories from GitHub to your Gitea instance, and use them as normal.
+And [Gitea Container Registry](usage/packages/container.md) can be used as a Docker image registry.
+
+### Connection 4, job containers to internet
+
+When using actions such as `actions/setup-go@v5`, it may be necessary to download resources from the internet to set up the Go language environment in job containers.
+Therefore, access to the internet is required for the successful completion of these actions.
+
+However, it is optional as well.
+You can use your own custom actions to avoid relying on internet access, or you can use your packaged Docker image to run jobs with all dependencies installed.
+
+## Summary
+
+Using Gitea Actions only requires ensuring that the runner can connect to the Gitea instance.
+Internet access is optional, but not having it will require some additional work.
+In other words: The runner works best when it can query the internet itself, but you don't need to expose it to the internet (in either direction).
+
+If you encounter any network issues while using Gitea Actions, hopefully the image above can help you troubleshoot them.

docs/usage/actions/faq.md

@@ -0,0 +1,127 @@
+---
+date: "2023-04-27T15:00:00+08:00"
+slug: "faq"
+sidebar_position: 200
+---
+
+# Frequently Asked Questions
+
+This page contains some common questions and answers about Gitea Actions.
+
+## Is it possible to disable Actions for new repositories by default for my own instance?
+
+Yes, when you enable Actions for the instance, you can choose to enable the `actions` unit for all new repositories by default.
+
+```ini
+[repository]
+; remove repo.actions will not enable actions for newly created repositories.
+DEFAULT_REPO_UNITS = ...,repo.actions
+```
+
+## Should we use `${{ github.xyz }}` or `${{ gitea.xyz }}`  in workflow files?
+
+You can use `github.xyz` and Gitea will work fine.
+As mentioned, Gitea Actions is designed to be compatible with GitHub Actions.
+However, we recommend using `gitea.xyz` in case Gitea adds something that GitHub does not have to avoid different kinds of secrets in your workflow file (and because you are using this workflow on Gitea, not GitHub).
+Still, this is completely optional since both options have the same effect at the moment.
+
+## Where will the runner download scripts when using actions such as `actions/checkout@v4`?
+
+From `https://github.com` by default, or from your own instance when `[actions].DEFAULT_ACTIONS_URL` is `self`, see the [Configuration Cheat Sheet](../../administration/config-cheat-sheet.md#actions-actions).
+
+To use an action from elsewhere, name its host:
+
+- `uses: https://gitea.com/owner/repo@ref`
+- `uses: http://your_gitea_instance.com/owner/repo@ref`
+- `uses: self:owner/repo@ref` for your own Gitea instance
+
+## How to limit the permission of the runners?
+
+Runners only connect to your Gitea instance.
+For each job, a runner gets a `GITEA_TOKEN` limited to the job's repository, see [Actions job token permissions](token-permissions.md).
+To give a job access to more private repositories or external systems, pass it [secrets](usage/actions/secrets.md).
+
+## Which operating systems are supported by Gitea Runner?
+
+Official binaries are released for Linux, macOS and Windows.
+Other systems supported by Go and Docker work in theory.
+
+## How to avoid being hacked?
+
+There are two types of possible attacks: unknown runner stealing the code or secrets from your repository, or malicious scripts controlling your runner.
+
+Avoiding the former means not allowing people you don't know to register runners for your repository, organization, or instance.
+
+The latter is a bit more complicated.
+If you're using a private Gitea instance for your company, you may not need to worry about security since you trust your colleagues and can hold them accountable.
+
+For public instances, things are a little different.
+Here's how we do it on [gitea.com](http://gitea.com/):
+
+- We only register runners for the "gitea" organization, so our runners will not execute jobs from other repositories.
+- Our runners always run jobs with isolated containers. While it is possible to do this directly on the host, we choose not to for more security.
+- To run actions for fork pull requests, approval is required. See [#22803](https://github.com/go-gitea/gitea/pull/22803).
+- If someone registers their own runner for their repository or organization on [gitea.com](http://gitea.com/), we have no objections and will just not use it in our org. However, they should take care to ensure that the runner is not used by other users they do not know.
+
+## Why choose GitHub Actions? Why not something compatible with GitLab CI/CD?
+
+[@lunny](https://gitea.com/lunny) has explained this in the [issue to implement actions](https://github.com/go-gitea/gitea/issues/13539).
+Furthermore, Actions is not only a CI/CD system but also an automation tool.
+
+There have also been numerous [marketplace actions](https://github.com/marketplace?type=actions) implemented in the open-source world.
+It is exciting to be able to reuse them.
+
+## What if it runs on multiple labels, such as `runs-on: [label_a, label_b]`?
+
+The job runs on a runner that has all of the labels, as on [GitHub](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on).
+The runner uses the environment of the first label it has.
+
+## What is the difference between agent labels and custom labels for a runner?
+
+Gitea no longer has custom labels.
+A runner declares its labels every time it starts, from its `runner.labels` configuration or the labels given at registration, so change them there and restart the runner.
+
+## Will there be more implementations for Gitea Actions runner?
+
+Although we would like to provide more options, our limited manpower means that Gitea Runner will be the only officially supported runner at the moment.
+
+However, both Gitea and Gitea Runner are completely open source under MIT License, so anyone can modify the code to satisfy their requirements.
+
+In case you fork Gitea Runner to create your own version: Please contribute the changes back if you can and if you think your changes will help others as well.
+
+## What workflow trigger events does Gitea support?
+
+All events listed in this table are supported events and are compatible with GitHub.
+For events supported only by GitHub, see GitHub's [documentation](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows).
+
+| trigger event                                | activity types                                                                                                                                                             |
+|----------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+| create                                       | not applicable                                                                                                                                                             |
+| delete                                       | not applicable                                                                                                                                                             |
+| fork                                         | not applicable                                                                                                                                                             |
+| gollum                                       | not applicable                                                                                                                                                             |
+| push                                         | not applicable                                                                                                                                                             |
+| schedule                                     | not applicable                                                                                                                                                             |
+| workflow_dispatch                            | not applicable                                                                                                                                                             |
+| workflow_call                                | not applicable                                                                                                                                                             |
+| issues                                       | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `milestoned`, `demilestoned`, `labeled`, `unlabeled`                                                    |
+| issue_comment                                | `created`, `edited`, `deleted`                                                                                                                                             |
+| pull_request<br/>pull_request_target         | `opened`, `edited`, `closed`, `reopened`, `assigned`, `unassigned`, `synchronize`, `labeled`, `unlabeled`, `milestoned`, `demilestoned`, `review_requested`, `review_request_removed` |
+| pull_request_review                          | `submitted`, `edited`                                                                                                                                                      |
+| pull_request_review_comment                  | `created`, `edited`                                                                                                                                                        |
+| release                                      | `published`, `edited`                                                                                                                                                      |
+| registry_package                             | `published`                                                                                                                                                                |
+| workflow_run                                 | `requested`, `in_progress`, `completed`                                                                                                                                    |
+
+> Without an explicit `types:` filter, `pull_request` and `pull_request_target` only run on `opened`, `reopened` and `synchronize`, matching GitHub. All other events run on every activity type they support.
+
+> For `pull_request` events, in [GitHub Actions](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request), the `ref` is `refs/pull/:prNumber/merge`, which is a reference to the merge commit preview. However, Gitea has no such reference.
+> Therefore, the `ref` in Gitea Actions is `refs/pull/:prNumber/head`, which points to the head of pull request rather than the preview of the merge commit.
+
+## How to share actions and reusable workflows from private repositories?
+
+Go to the repository's **Settings** > **Actions** > **General** page and add collaborative owners.
+The private repositories of collaborative owners are allowed to access the actions and workflows in the current repository.
+
+To share within the same user or organization, add the private repositories under its **Settings** > **Actions** > **General** > **Cross-Repository Access** instead.
+See [Cross-repository access](token-permissions.md#cross-repository-access).

docs/usage/actions/openid-connect.md

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

docs/usage/actions/overview.md

@@ -0,0 +1,38 @@
+---
+date: "2023-04-27T15:00:00+08:00"
+slug: "overview"
+sidebar_position: 1
+---
+
+# Overview
+
+Starting with Gitea **1.19**, Gitea Actions are available as a built-in CI/CD solution.
+
+## Name
+
+It is similar and mostly compatible to [GitHub Actions](https://github.com/features/actions), and its name is inspired by it too.
+To avoid confusion, we have clarified the spelling here:
+
+- "Gitea Actions" (with an "s", both words capitalized) is the name of the Gitea feature.
+- "GitHub Actions" is the name of the GitHub feature.
+- "Actions" could refer to either of the above, depending on the context. So it refers to "Gitea Actions" in this document.
+- "action" or "actions" refer to some scripts/plugins to be used, like "actions/checkout@v4" or "actions/cache@v3".
+
+## Runners
+
+Just like other CI/CD solutions, Gitea doesn't run the jobs itself, but delegates the jobs to runners.
+The runner of Gitea Actions is called [Gitea Runner](https://gitea.com/gitea/runner), it is a standalone program and also written in Go.
+An important part of the application comes from a hard fork of [nektos/act](http://github.com/nektos/act).
+
+Because the runner is deployed independently, there could be potential security issues.
+To avoid them, please follow two simple rules:
+
+- Don't use a runner you don't trust for your repository, organization or instance.
+- Don't provide a runner to a repository, organization or instance you don't trust.
+
+For Gitea instances used internally, such as instances used by enterprises or individuals, neither of these two rules is a problem, they are naturally so.
+However, for public Gitea instances, such as [gitea.com](https://gitea.com), these two rules should be kept in mind when adding or using runners.
+
+## Status
+
+Gitea Actions is stable enough for production usage and we use Gitea Actions in all the repositories in https://gitea.com/gitea.

docs/usage/actions/quickstart.md

@@ -0,0 +1,138 @@
+---
+date: "2023-04-27T15:00:00+08:00"
+slug: "quickstart"
+sidebar_position: 10
+---
+
+# Quick Start
+
+This page will guide you through the process of using Gitea Actions.
+
+## Set up Gitea
+
+First of all, you need a Gitea instance.
+You can follow the [documentation](installation/from-package.md) to set up a new instance or upgrade your existing one.
+It doesn't matter how you install or run Gitea, as long as its version is 1.19.0 or higher.
+
+Since 1.21.0, Actions are enabled by default. If you are using versions before 1.21.0, you need to add the following to the configuration file to enable it:
+
+```ini
+[actions]
+ENABLED=true
+```
+
+If you want to learn more or encounter any problems while configuring it, please refer to the [Configuration Cheat Sheet](../../administration/config-cheat-sheet.md#actions-actions).
+
+### Set up runner
+
+Gitea Actions requires [Gitea Runner](https://gitea.com/gitea/runner) to run the jobs.
+In order to avoid consuming too many resources and affecting the Gitea instance, it is recommended to start runners on separate machines from the Gitea instance.
+
+You can use the [pre-built binaries](http://dl.gitea.com/gitea-runner) or the [docker images](https://hub.docker.com/r/gitea/runner/tags) to set up the runner.
+
+Before proceeding any further, we suggest running it as a command line with pre-built binaries to ensure that it works with your environment, especially if you are running a runner on your localhost.
+And it could be easier to debug if something goes wrong.
+
+The runner can run the jobs in isolated Docker containers, so you need to make sure that the Docker has been installed and Docker daemon is running.
+While it is not strictly necessary, because the runner can also run the jobs directly on the host, it depends on how you configure it.
+However, it is recommended to use Docker to run the jobs, because it is more secure and easier to manage.
+
+Before running a runner, you should first register it to your Gitea instance using the following command:
+
+```bash
+gitea-runner register --no-interactive --instance <instance> --token <token>
+```
+
+There are two arguments required, `instance` and `token`.
+
+`instance` refers to the address of your Gitea instance, like `http://192.168.8.8:3000` or `https://gitea.com`.
+The runner and job containers (which are started by the runner to execute jobs) will connect to this address.
+This means that it could be different from the `ROOT_URL` of your Gitea instance, which is configured for web access.
+It is always a bad idea to use a loopback address such as `127.0.0.1` or `localhost`.
+If you are unsure which address to use, the LAN address is usually the right choice.
+
+`token` is used for authentication and identification, such as `P2U1U0oB4XaRCi8azcngmPCLbRpUGapalhmddh23`.
+Each token can be used to create multiple runners, until it is replaced with a new token using the reset link.
+You can obtain different levels of 'tokens' from the following places to create the corresponding level of 'runners':
+
+- Instance level: The admin settings page, like `<your_gitea.com>/-/admin/actions/runners`.
+- Organization level: The organization settings page, like `<your_gitea.com>/<org>/settings/actions/runners`.
+- Repository level: The repository settings page, like `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`.
+
+![register runner](/images/usage/actions/register-runner.png)
+
+After registering, a new file named `.runner` will appear in the current directory.
+This file stores the registration information.
+Please do not edit it manually.
+If this file is missing or corrupted, you can simply remove it and register again.
+
+Finally, it's time to start the runner:
+
+```bash
+gitea-runner daemon
+```
+
+And you can see the new runner in the management page:
+
+![view runner](/images/usage/actions/view-runner.png)
+
+You can find more information by visiting [Gitea Runner](runner.mdx).
+
+### Use Actions
+
+Even if Actions is enabled for the Gitea instance, repositories still disable Actions by default.
+
+To enable it, go to the settings page of your repository like `your_gitea.com/<owner>/repo/settings` and enable `Enable Repository Actions`.
+
+![enable actions](/images/usage/actions/enable-actions.png)
+
+The next steps may be rather complicated.
+You will need to study [the workflow syntax](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions) for Actions and write the workflow files you want.
+
+However, we can just start from a simple demo:
+
+```yaml
+name: Gitea Actions Demo
+run-name: ${{ gitea.actor }} is testing out Gitea Actions 🚀
+on: [push]
+
+jobs:
+  Explore-Gitea-Actions:
+    runs-on: ubuntu-latest
+    steps:
+      - run: echo "🎉 The job was automatically triggered by a ${{ gitea.event_name }} event."
+      - run: echo "🐧 This job is now running on a ${{ runner.os }} server hosted by Gitea!"
+      - run: echo "🔎 The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
+      - name: Check out repository code
+        uses: actions/checkout@v4
+      - run: echo "💡 The ${{ gitea.repository }} repository has been cloned to the runner."
+      - run: echo "🖥️ The workflow is now ready to test your code on the runner."
+      - name: List files in the repository
+        run: |
+          ls ${{ gitea.workspace }}
+      - run: echo "🍏 This job's status is ${{ job.status }}."
+```
+
+:::warning
+
+Certain actions may not function correctly within SHA256 repositories or when Gitea runs on subpath. This includes [actions/checkout](https://github.com/actions/checkout/issues/1843).
+
+:::
+
+You can upload it as a file with the extension `.yaml` in the directory `.gitea/workflows/` of the repository, for example `.gitea/workflows/demo.yaml`.
+You might notice that this is fairly similar from the [Quickstart for GitHub Actions](https://docs.github.com/en/actions/quickstart).
+That is because  Gitea Actions is designed to be compatible with GitHub Actions wherever possible.
+
+Be careful, the demo file contains some emojis.
+Please make sure your database supports them, especially when using MySQL.
+If the charset is not `utf8mb4`, errors will occur, such as `Error 1366 (HY000): Incorrect string value: '\\xF0\\x9F\\x8E\\x89 T...' for column 'name' at row 1`.
+See [Database Preparation](../../installation/database-preparation.md#mysqlmariadb) for more information.
+
+Alternatively, you can remove all emojis from the demo file and try again.
+
+The line `on: [push]` indicates that the workflow will be triggered when you push commits to this repository.
+However, when you upload the YAML file, it also pushes a commit, so you should see a new task in the Actions tab.
+
+![view job](/images/usage/actions/view-job.png)
+
+Great job! You have successfully started working with Actions.

docs/usage/actions/runner.mdx

@@ -0,0 +1,53 @@
+---
+date: "2023-04-27T15:00:00+08:00"
+slug: "runner"
+sidebar_position: 20
+---
+
+# Gitea Runner
+
+This page will introduce the [Gitea Runner](https://gitea.com/gitea/runner), which is the runner for Gitea Actions.
+
+:::tip
+For detailed installation, configuration, and usage instructions, see the [Gitea Runner documentation](/runner/).
+:::
+
+## Obtain a registration token
+
+You can register a runner at different levels. It can be:
+
+- Instance level: The runner will run jobs for all repositories in the instance.
+- Organization level: The runner will run jobs for all repositories in the organization.
+- Repository level: The runner will run jobs for the repository it belongs to.
+
+Note that the repository may still use instance-level or organization-level runners even if it has its own repository-level runners. A future release may provide an option to allow more control over this.
+
+Before registering the runner and running it, you need a registration token. The level of the runner determines where to obtain the registration token.
+
+- Instance level: The admin settings page, like `<your_gitea.com>/-/admin/actions/runners`.
+- Organization level: The organization settings page, like `<your_gitea.com>/<org>/settings/actions/runners`.
+- Repository level: The repository settings page, like `<your_gitea.com>/<owner>/<repo>/settings/actions/runners`.
+
+If you cannot see the settings page, please make sure that you have the right permissions and that Actions have been enabled.
+
+The format of the registration token is a random string `D0gvfu2iHfUjNqCYVljVyRV14fISpJxxxxxxxxxx`.
+
+A registration token can also be obtained from the Gitea [command-line interface](../../administration/command-line.md#actions-generate-runner-token):
+
+```
+gitea --config /etc/gitea/app.ini actions generate-runner-token
+```
+
+You can also use `GITEA_RUNNER_REGISTRATION_TOKEN`/`GITEA_RUNNER_REGISTRATION_TOKEN_FILE` environment variables to set a global runner registration token when Gitea starts, for example:
+
+```
+openssl rand -hex 24 > /some-dir/runner-token
+export GITEA_RUNNER_REGISTRATION_TOKEN_FILE=/some-dir/runner-token
+./gitea --config ...
+```
+
+The token from the environment is valid until you reset the token (re-create a new one) via the web UI or API.
+
+Tokens are valid for registering multiple runners, until they are revoked and replaced by a new token using the token reset link in the web interface.
+
+Once you have a registration token, follow the [Gitea Runner documentation](/runner/) to install, configure, and run your runner.

docs/usage/actions/scoped-workflows.md

@@ -0,0 +1,119 @@
+---
+date: "2026-06-26T00:00:00+00:00"
+slug: "scoped-workflows"
+sidebar_position: 60
+---
+
+# Scoped Workflows
+
+Scoped workflows let you maintain Actions workflows in one central **source** repository and have them run automatically on many other repositories, without copying the workflow files into each one.
+
+A workflow file committed under a source repository's scoped-workflow directory runs on every repository that the source applies to (a "consuming" repository). Each run executes **in the consuming repository's own context**: its runners, secrets, `GITEA_TOKEN`, and branch, while the workflow **content is read from the source repository**. This is useful for mandating shared CI across an organization or instance: linting, security scans, compliance or policy checks, and similar.
+
+## Levels
+
+A source repository can be registered at two levels:
+
+- **Owner level**: registered by an organization or user. The source's workflows run on every repository owned by that organization or user.
+- **Instance level**: registered by a site administrator. The source's workflows run on **every** repository on the instance.
+
+The same repository may be registered at both levels; it is still evaluated once per matching event.
+
+:::note
+Instance-level sources apply to **every** repository on the instance, and a required one cannot be opted out. Detection runs on every repository's events. Register them deliberately.
+:::
+
+## Configuration
+
+Scoped workflows live in a directory that is separate from regular workflows. It is controlled by `SCOPED_WORKFLOW_DIRS` in the `[actions]` section of `app.ini`:
+
+```ini
+[actions]
+SCOPED_WORKFLOW_DIRS = .gitea/scoped_workflows
+```
+
+- The default is `.gitea/scoped_workflows`.
+- It may list multiple directories (comma-separated).
+- It **must not overlap** with `WORKFLOW_DIRS` (the regular workflow directories, by default `.gitea/workflows` and `.github/workflows`).
+- Leaving it empty means no directory holds scoped workflows, so none are found or run. The settings page still appears and sources can still be registered, but no scoped workflow runs.
+
+Keeping scoped workflows in their own directory means a source repository's *own* Actions are unaffected: only files under `SCOPED_WORKFLOW_DIRS` are treated as scoped workflows.
+
+## Providing scoped workflows from a repository
+
+1. In the would-be source repository, commit your workflow files under the scoped-workflow directory on its **default branch**, for example `.gitea/scoped_workflows/lint.yaml`:
+
+   ```yaml
+   name: Lint
+   on: [push, pull_request]
+   jobs:
+     lint:
+       runs-on: ubuntu-latest
+       steps:
+         - uses: actions/checkout@v4
+         - run: echo "lint the consuming repository here"
+   ```
+
+2. Register the repository as a source:
+
+   - **Organization**: *Organization Settings -> Actions -> Scoped Workflows*
+   - **User**: *User Settings -> Actions -> Scoped Workflows*
+   - **Instance (admin)**: *Site Administration -> Actions -> Scoped Workflows*
+
+   Search for and add the repository. From then on, its scoped workflows apply to the consuming repositories at that level.
+
+The source repository is within its own scope, so it runs these workflows on itself like any other consumer.
+
+## How scoped workflows run
+
+- The run belongs to the **consuming** repository and uses its runners, secrets, `GITEA_TOKEN`, and ref. It behaves like a normal run there, including rerun, logs, and commit statuses.
+- The workflow **content is read from the source** repository, pinned to the source's default-branch commit at the time of the event.
+- Detection uses the consuming repository's event, so the workflow's `on:` triggers (such as `push` and `pull_request`) must match that event.
+
+## Opting out
+
+A consuming repository can disable a scoped workflow it does not want, from its **Actions** page (the workflow appears under its source). A workflow that has been marked **required** (see below) can never be disabled or opted out by a consuming repository.
+
+## Required workflows and the merge gate
+
+On the Scoped Workflows settings page you can mark individual workflows as **required** and give each one or more **status-check patterns** (one glob per line). A required scoped workflow:
+
+- Cannot be disabled by consuming repositories.
+- Gates pull-request merges: a consuming pull request can only be merged once a commit status matching **every** pattern has **passed** (must-present-and-pass). A required check that never posts a status **blocks** the merge rather than being silently skipped, so disabling Actions on the consumer cannot bypass it.
+
+The status-check context a scoped run posts has the form:
+
+```
+<source repo full name>: <workflow display name> / <job> (<event>)
+```
+
+The settings page previews these "Expected status checks" for each workflow and marks the ones your patterns match, so you can confirm a pattern is correct. A common pattern wildcards the job and event, for example `my-org/ci-repo: Lint / *`.
+
+Enforcement scope:
+
+- A required check is enforced on any target branch that has a **branch protection rule**, even one whose own status checks are disabled.
+- A target branch with **no** protection rule is not gated.
+
+:::warning
+Only a workflow that runs on an event that posts a commit status (`push`, `pull_request`, `pull_request_target`, `release`) can be required. A workflow that runs only on events like `workflow_dispatch`, `schedule` or `workflow_call` posts no status, so marking it required would block every consuming pull request forever. The settings page warns you in this case.
+:::
+
+## Reusable workflows (`uses:`)
+
+Scoped workflows can call reusable workflows:
+
+- A **local** reference (`uses: ./...` or `uses: $/...`) resolves against the **source** repository: the repository the calling workflow's content came from, not the consuming repository.
+- A **cross-repository** reference (`uses: owner/repo/...@ref` or `uses: self:owner/repo/...@ref`) is resolved with the **consuming repository's** read permission. If it points to a private repository, make sure every consuming repository can read it; otherwise the workflow will fail there.
+
+A reusable workflow can live under `SCOPED_WORKFLOW_DIRS` (or `WORKFLOW_DIRS`) of the source repository.
+
+## Security considerations
+
+A source repository's workflow content is executed in every repository it applies to, and its step scripts and their output are written to that repository's Actions logs, readable by anyone who can view the consuming repository's Actions.
+
+- Registering a **private** repository as a source therefore discloses its workflow logic through those logs. Only register repositories whose workflow content may be shared with every consuming repository.
+
+## Limitations
+
+- `on: schedule` and `on: workflow_run` are currently not supported as scoped workflow triggers.
+- Scoped workflow content is read from the source's default branch; other branches of the source are not used.

docs/usage/actions/secrets.md

@@ -1,18 +1,7 @@
 ---
-date: "2022-12-19T21:26:00+08:00"
-title: "Secrets"
+date: "2024-07-10T09:23:00+02:00"
 slug: "secrets"
 sidebar_position: 50
-draft: false
-toc: false
-aliases:
-  - /en-us/secrets
-menu:
-  sidebar:
-    parent: "usage"
-    name: "Secrets"
-    sidebar_position: 50
-    identifier: "usage-secrets"
 ---
 
 # Secrets
@@ -36,4 +25,11 @@ The following rules apply to secret names:
 
 For example, a secret created at the repository level must have a unique name in that repository, and a secret created at the organization level must have a unique name at that level.
 
+### Using secrets
+
+After creating configuration variables, they will be automatically filled in the `secrets` context.
+They can be accessed through expressions like `${{ secrets.SECRET_NAME }}` in the workflow.
+
+### Precedence
+
 If a secret with the same name exists at multiple levels, the secret at the lowest level takes precedence. For example, if an organization-level secret has the same name as a repository-level secret, then the repository-level secret takes precedence.

docs/usage/actions/token-permissions.md

@@ -0,0 +1,123 @@
+---
+date: "2026-03-19T00:00:00+01:00"
+slug: "token-permissions"
+sidebar_position: 30
+---
+
+# Actions job token permissions (`GITEA_TOKEN`)
+
+Every Actions job receives a built-in token (`GITEA_TOKEN`) which can be used to access Gitea (Git over HTTP(S), API requests, etc.).
+This page documents how Gitea decides what the token is allowed to do.
+
+In workflows, it is available as `${{ secrets.GITEA_TOKEN }}`. These settings and `permissions:` only affect `GITEA_TOKEN` (not other secrets like personal access tokens). For API calls, see [API authentication](../../development/api-usage.md#authentication).
+
+## Where permissions come from
+
+Gitea determines the job token permissions in this order:
+
+1. Job-level `permissions:` (`jobs.<job_id>.permissions`)
+2. Workflow-level `permissions:` (top-level)
+3. Default permissions from settings (owner or repository)
+
+The result is then **clamped** by the configured maximum token permissions (see below).
+
+## Supported workflow syntax
+
+Gitea supports the GitHub Actions-compatible `permissions:` keyword.
+
+### Scalar values
+
+```yaml
+permissions: read-all   # or: write-all
+```
+
+### Scoped mapping
+
+```yaml
+permissions:
+  contents: read
+  issues: write
+  pull-requests: none
+```
+
+Valid access mode values for each scope are `read`, `write`, and `none`.
+
+### Supported scopes
+
+- `contents` (applies to `code` and `releases`)
+- `code`
+- `releases`
+- `issues`
+- `pull-requests`
+- `actions`
+- `wiki`
+- `projects`
+- `packages` (if supported by the target feature)
+- `id-token` (`write` allows requesting [OpenID Connect tokens](openid-connect.md), `read` grants nothing)
+
+If you specify both `contents` and a more granular scope (like `code` or `releases`), the granular scope wins for that unit.
+
+### Compatibility notes
+
+Gitea supports a subset of GitHub Actions permission scopes.
+GitHub-only scopes such as `statuses`, `checks`, `deployments`, `security-events`, and `pages` are not currently supported by Gitea Actions.
+
+Gitea also exposes repository-unit scopes that do not exist as separate scopes in GitHub Actions:
+
+- `code`
+- `releases`
+- `wiki`
+- `projects`
+
+## Default permission mode
+
+If neither the workflow nor the job defines `permissions:`, Gitea uses the configured default mode:
+
+- **Permissive**: read and write permissions for most units in the job's repository (backwards-compatible default).
+- **Restricted**: read-only permissions for `code`, `releases`, and `packages` in the job's repository, and no access to other units by default.
+
+Neither mode includes `id-token`.
+
+## Maximum token permissions (clamping)
+
+You can configure a maximum permission per repository unit and for `id-token`.
+The job's effective permissions are computed as:
+
+`effective = min(requested, maximum)`
+
+This means workflows can reduce permissions for a job, but cannot exceed your configured maximum.
+If you don't configure a maximum, the maximum defaults to `write` for all scopes.
+Maximums saved before Gitea supported `id-token` deny it until you set it to `write`.
+
+## Where to configure
+
+You can configure defaults and maximums at:
+
+- **User / Organization**: `Settings` → `Actions` → `General`
+- **Repository**: `Settings` → `Actions` → `General`
+  - For repositories in an organization, the repository can follow the owner-level configuration, or opt out with **Override owner-level configuration**.
+
+Note: Repository-level token permission settings are only shown once **Repository Actions** are enabled.
+
+## Protected branches
+
+Actions job tokens must have code write permission and satisfy [branch protection rules](../access-control/protected-branches.md), including any **Gitea Actions** allowlist requirements.
+
+## Fork pull requests
+
+For security reasons, workflows triggered by pull requests from forks are always restricted to read-only permissions for repository contents, regardless of workflow `permissions:` or settings. They also get no OpenID Connect tokens.
+
+## Cross-repository access
+
+By default, `GITEA_TOKEN` only has access to:
+
+- The job's repository (according to the computed permissions)
+- Public repositories (read-only)
+
+Access to other private repositories is denied by default.
+A user or organization can allow read-only access to selected private repositories via **Settings → Actions → General → Cross-Repository Access**.
+
+Private repositories can also allow selected collaborative owners via **Settings → Actions → General**.
+This allows the private repositories of those owners to read the current private repository for Actions use, such as private actions and reusable workflows.
+
+Fork pull request workflows never gain cross-repository access to private repositories, even if those repositories are listed.

docs/usage/actions/variables.md

@@ -0,0 +1,192 @@
+---
+date: "2024-04-10T22:21:00+08:00"
+slug: "actions-variables"
+sidebar_position: 25
+---
+
+# Variables
+
+## Environment variables
+
+These environment variables are set automatically in every workflow run and can be accessed directly (e.g. `$CI` in shell scripts).
+
+| Name | Description | Example |
+|---|---|---|
+| `CI` | Always set to `true`. | `true` |
+| `GITEA_ACTIONS` | Always set to `true`. Useful to distinguish Gitea Actions from other CI systems. | `true` |
+| `GITEA_ACTIONS_RUNNER_VERSION` | The version of the runner executing the workflow. | `1.0.8` |
+| `GITEA_DOCKER_WORKSPACE` | The workspace path as the Docker daemon sees it, for bind mounts into containers a job starts, e.g. `${GITEA_DOCKER_WORKSPACE:-.}/data:/app/data` in a compose file. Only set for jobs running in a container. | `/var/lib/docker/volumes/GITEA-ACTIONS-TASK-42_***/_data` |
+| `GITEA_ENV`<br/>`GITHUB_ENV` | Path to the file that sets environment variables for subsequent steps. | `/home/runner/work/_temp/_runner_file_commands/set_env_***` |
+| `GITEA_OUTPUT`<br/>`GITHUB_OUTPUT` | Path to the file that sets step output parameters. | `/home/runner/work/_temp/_runner_file_commands/set_output_***` |
+| `GITEA_PATH`<br/>`GITHUB_PATH` | Path to the file that adds system `PATH` entries for subsequent steps. | `/home/runner/work/_temp/_runner_file_commands/add_path_***` |
+| `GITEA_STATE`<br/>`GITHUB_STATE` | Path to the file that sets step state variables. | `/home/runner/work/_temp/_runner_file_commands/save_state_***` |
+| `GITEA_STEP_SUMMARY`<br/>`GITHUB_STEP_SUMMARY` | Path to the file for writing job summaries. | `/home/runner/work/_temp/_runner_file_commands/step_summary_***` |
+| `GITHUB_ACTIONS` | Always set to `true`. | `true` |
+| `GITHUB_ACTION` | The name of the action currently running, or the step `id`. | `__run` |
+| `GITHUB_ACTION_PATH` | The path where the action is located. | `/home/runner/work/_actions/actions/checkout/v4` |
+| `GITHUB_ACTION_REF` | The ref of the action being executed. | `v4` |
+| `GITHUB_ACTION_REPOSITORY` | The owner and repository of the action. | `actions/checkout` |
+| `GITHUB_ACTOR` | The username of the user that triggered the workflow. | `silverwind` |
+| `GITHUB_API_URL` | The URL of the REST API. | `https://gitea.com/api/v1` |
+| `GITHUB_BASE_REF` | The target branch of a pull request. | `main` |
+| `GITHUB_EVENT_NAME` | The name of the event that triggered the workflow. | `push` |
+| `GITHUB_EVENT_PATH` | Path to the file containing the event webhook payload. | `/home/runner/work/_temp/_github_workflow/event.json` |
+| `GITHUB_GRAPHQL_URL` | Empty in Gitea (GraphQL is not supported). | _(empty)_ |
+| `GITHUB_HEAD_REF` | The source branch of a pull request. | `feature-branch` |
+| `GITHUB_JOB` | The `job_id` of the current job. | `build` |
+| `GITHUB_REF` | The fully-formed ref that triggered the workflow. | `refs/heads/main` |
+| `GITHUB_REF_NAME` | The short ref name. | `main` |
+| `GITHUB_REF_TYPE` | The type of ref: `branch` or `tag`. | `branch` |
+| `GITHUB_REPOSITORY` | The owner and repository name. | `gitea/docs` |
+| `GITHUB_REPOSITORY_OWNER` | The repository owner's username. | `gitea` |
+| `GITHUB_RETENTION_DAYS` | The number of days that artifacts are kept, empty when kept forever. | `90` |
+| `GITHUB_RUN_ATTEMPT` | The attempt number of the workflow run. | `1` |
+| `GITHUB_RUN_ID` | A unique number for each workflow run. | `1234` |
+| `GITHUB_RUN_NUMBER` | A unique number for each run of a particular workflow. | `42` |
+| `GITHUB_SERVER_URL` | The URL of the Gitea instance. | `https://gitea.com` |
+| `GITHUB_SHA` | The commit SHA that triggered the workflow. | `a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2` |
+| `GITHUB_WORKFLOW` | The name of the workflow. | `CI` |
+| `GITHUB_WORKSPACE` | The default working directory on the runner. | `/workspace/gitea/docs` |
+
+### Runner environment variables
+
+| Name | Description | Example |
+|---|---|---|
+| `RUNNER_ARCH` | The architecture of the runner. | `X64` |
+| `RUNNER_OS` | The operating system of the runner. | `Linux` |
+| `RUNNER_TEMP` | Path to a temporary directory on the runner. | `/tmp` |
+| `RUNNER_TOOL_CACHE` | Path to the tool cache directory on the runner. | `/opt/hostedtoolcache` |
+
+### Internal environment variables
+
+These are used internally by the runner and actions. They are typically not needed in workflows directly.
+
+| Name | Description | Example |
+|---|---|---|
+| `ACTIONS_CACHE_URL` | URL for the actions cache service. | `http://192.168.1.10:8088/` |
+| `ACTIONS_ID_TOKEN_REQUEST_TOKEN` | Token for OIDC requests. Only set when `id-token: write` is granted. | `***` |
+| `ACTIONS_ID_TOKEN_REQUEST_URL` | URL to request OIDC tokens. Only set when `id-token: write` is granted. | `https://gitea.com/api/actions/oidc/token?` |
+| `ACTIONS_RESULTS_URL` | URL for storing artifacts. | `https://gitea.com` |
+| `ACTIONS_RUNTIME_TOKEN` | Authentication token for the Actions pipeline API. | `***` |
+| `ACTIONS_RUNTIME_URL` | URL for the Gitea Actions pipeline API. | `https://gitea.com/api/actions_pipeline/` |
+
+## Context variables
+
+These variables are available in workflow expressions via `${{ gitea.<name> }}`. For compatibility, `${{ github.<name> }}` works as an alias.
+
+| Name | Description | Example |
+|---|---|---|
+| `gitea.action`<br/>`github.action` | The name of the action currently running, or the `id` of a step. | `__run` |
+| `gitea.action_path`<br/>`github.action_path` | The path where an action is located. Only supported in composite actions. | `/home/runner/work/_actions/actions/checkout/v4` |
+| `gitea.action_ref`<br/>`github.action_ref` | The ref of the action being executed. | `v4` |
+| `gitea.action_repository`<br/>`github.action_repository` | The owner and repository name of the action. | `actions/checkout` |
+| `gitea.action_status`<br/>`github.action_status` | The current result of a composite action. | `success` |
+| `gitea.actor`<br/>`github.actor` | The username of the user that triggered the initial workflow run. | `silverwind` |
+| `gitea.api_url`<br/>`github.api_url` | The URL of the REST API. | `https://gitea.com/api/v1` |
+| `gitea.base_ref`<br/>`github.base_ref` | The target branch of a pull request. Only set for `pull_request` and `pull_request_target` events. | `main` |
+| `gitea.env`<br/>`github.env` | Path on the runner to the file that sets environment variables from workflow commands. Unique to each step. | `/home/runner/work/_temp/_runner_file_commands/set_env_***` |
+| `gitea.event`<br/>`github.event` | The full event webhook payload as an object. See [Event payload](#event-payload). | `{...}` |
+| `gitea.event_name`<br/>`github.event_name` | The name of the event that triggered the workflow run. | `push` |
+| `gitea.event_path`<br/>`github.event_path` | Path on the runner to the file containing the full event webhook payload. | `/home/runner/work/_temp/_github_workflow/event.json` |
+| `gitea.head_ref`<br/>`github.head_ref` | The source branch of a pull request. Only set for `pull_request` and `pull_request_target` events. | `feature-branch` |
+| `gitea.job`<br/>`github.job` | The `job_id` of the current job. | `build` |
+| `gitea.ref`<br/>`github.ref` | The fully-formed ref that triggered the workflow. | `refs/heads/main` |
+| `gitea.ref_name`<br/>`github.ref_name` | The short ref name. | `main` |
+| `gitea.ref_protected`<br/>`github.ref_protected` | `true` if branch protections are configured for the ref that triggered the workflow run. | `true` |
+| `gitea.ref_type`<br/>`github.ref_type` | The type of ref: `branch` or `tag`. | `branch` |
+| `gitea.path`<br/>`github.path` | Path on the runner to the file that sets system `PATH` variables from workflow commands. Unique to each step. | `/home/runner/work/_temp/_runner_file_commands/add_path_***` |
+| `gitea.repository`<br/>`github.repository` | The owner and repository name. | `gitea/docs` |
+| `gitea.repository_owner`<br/>`github.repository_owner` | The repository owner's username. | `gitea` |
+| `gitea.repositoryUrl`<br/>`github.repositoryUrl` | The HTML URL to the repository. | `https://gitea.com/gitea/docs` |
+| `gitea.retention_days`<br/>`github.retention_days` | The number of days that artifacts are kept, empty when kept forever. | `90` |
+| `gitea.run_id`<br/>`github.run_id` | A unique number for each workflow run within a repository. Does not change on re-run. | `1234` |
+| `gitea.run_number`<br/>`github.run_number` | A unique number for each run of a particular workflow. Starts at 1 and increments with each new run. | `42` |
+| `gitea.run_attempt`<br/>`github.run_attempt` | A unique number for each re-run attempt. Starts at 1 and increments with each re-run. | `1` |
+| `gitea.secret_source`<br/>`github.secret_source` | The source of a secret used in a workflow. Always `Actions` in Gitea. | `Actions` |
+| `gitea.server_url`<br/>`github.server_url` | The URL of the Gitea instance. | `https://gitea.com` |
+| `gitea.sha`<br/>`github.sha` | The commit SHA that triggered the workflow. | `a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2` |
+| `gitea.token`<br/>`github.token` | A token to authenticate on behalf of the Gitea App installed on the repository. See [Token permissions](token-permissions.md). | `ghs_***` |
+| `gitea.triggering_actor`<br/>`github.triggering_actor` | The username of the user that initiated the workflow run. May differ from `actor` on re-runs. | `silverwind` |
+| `gitea.workflow`<br/>`github.workflow` | The name of the workflow. If unnamed, the full path of the workflow file. | `CI` |
+| `gitea.workspace`<br/>`github.workspace` | The default working directory on the runner and the default location of your repository when using the `checkout` action. | `/workspace/gitea/docs` |
+| `gitea.gitea_default_actions_url` | The default URL for downloading actions. Gitea-specific. | `https://github.com` |
+
+### Event payload
+
+`gitea.event` is the webhook payload of the event that triggered the run, so which fields exist depends on `gitea.event_name`.
+The same payload is written as JSON to the file at `gitea.event_path`.
+
+Payloads use Gitea's webhook format, which is close to GitHub's but not identical. Differences are noted below.
+Reading a field that the payload does not have returns an empty value instead of failing, so `${{ gitea.event.pull_request.number }}` is empty on a `push` run.
+
+These fields exist in almost every payload:
+
+| Name | Description | Example |
+|---|---|---|
+| `gitea.event.action` | The activity type. Only set for events that have activity types, see [supported events](faq.md#what-workflow-trigger-events-does-gitea-support). | `opened` |
+| `gitea.event.repository.full_name` | The owner and name of the repository. | `gitea/docs` |
+| `gitea.event.repository.default_branch` | The default branch of the repository. | `main` |
+| `gitea.event.repository.private` | Whether the repository is private. | `false` |
+| `gitea.event.repository.html_url` | The HTML URL of the repository. | `https://gitea.com/gitea/docs` |
+| `gitea.event.sender.login` | The username of the user that triggered the event. Also available as `sender.username`. | `silverwind` |
+
+The remaining fields are specific to one or a few events:
+
+| Name | Events | Description | Example |
+|---|---|---|---|
+| `gitea.event.schedule` | `schedule` | The cron expression that triggered the run. | `*/5 * * * *` |
+| `gitea.event.inputs.<name>` | `workflow_dispatch`, `workflow_call` | A raw input value. Prefer `${{ inputs.<name> }}`, which also applies the input's `default`. | `true` |
+| `gitea.event.workflow` | `workflow_dispatch` | The file name of the dispatched workflow. | `ci.yaml` |
+| `gitea.event.ref` | `push`, `create`, `delete`, `workflow_dispatch` | The ref of the event. Unlike GitHub, `create` and `delete` use the full ref instead of the short name. | `refs/heads/main` |
+| `gitea.event.ref_type` | `create`, `delete` | The type of ref: `branch` or `tag`. | `tag` |
+| `gitea.event.before`<br/>`gitea.event.after` | `push` | The commit SHA before and after the push. | `a1b2c3d4e5f6a1b2c3d4e5f6a1b2c3d4e5f6a1b2` |
+| `gitea.event.commits` | `push` | The commits contained in the push, each with `id`, `message`, `url`, `author`, `added`, `removed` and `modified`. | `[{...}]` |
+| `gitea.event.head_commit.message` | `push` | The message of the most recent commit of the push. | `fix: broken link` |
+| `gitea.event.total_commits` | `push` | The number of commits in the push. Gitea-specific. | `3` |
+| `gitea.event.compare_url` | `push` | The URL comparing `before` with `after`. GitHub names this field `compare`. | `https://gitea.com/gitea/docs/compare/a1b2c3d...e5f6a1b` |
+| `gitea.event.pusher.login` | `push` | The username of the user that pushed. | `silverwind` |
+| `gitea.event.forkee.full_name` | `fork` | The owner and name of the new fork. | `silverwind/docs` |
+| `gitea.event.page` | `gollum` | The name of the wiki page. | `Home` |
+| `gitea.event.number` | `issues`, `pull_request`, `pull_request_target`, `pull_request_review`, `pull_request_review_comment` | The index of the issue or pull request. Not set for `issue_comment`, use `gitea.event.issue.number` there. | `386` |
+| `gitea.event.issue.number`<br/>`gitea.event.issue.title`<br/>`gitea.event.issue.body`<br/>`gitea.event.issue.state`<br/>`gitea.event.issue.labels`<br/>`gitea.event.issue.user.login` | `issues`, `issue_comment` | The issue the event happened on. | `Expand gitea.event in actions docs` |
+| `gitea.event.comment.body` | `issue_comment` | The body of the comment. | `LGTM` |
+| `gitea.event.is_pull` | `issue_comment` | Whether the comment was made on a pull request. Gitea-specific, GitHub sets `issue.pull_request` on the issue object instead. | `true` |
+| `gitea.event.pull_request.number`<br/>`gitea.event.pull_request.title`<br/>`gitea.event.pull_request.body`<br/>`gitea.event.pull_request.draft`<br/>`gitea.event.pull_request.merged`<br/>`gitea.event.pull_request.state`<br/>`gitea.event.pull_request.labels`<br/>`gitea.event.pull_request.user.login` | `pull_request`, `pull_request_target`, `pull_request_review`, `pull_request_review_comment` | The pull request the event happened on. | `Add caching to CI` |
+| `gitea.event.pull_request.head.ref`<br/>`gitea.event.pull_request.head.sha`<br/>`gitea.event.pull_request.head.repo.full_name` | `pull_request`, `pull_request_target`, `pull_request_review`, `pull_request_review_comment` | The source branch of the pull request. | `feature-branch` |
+| `gitea.event.pull_request.base.ref`<br/>`gitea.event.pull_request.base.sha` | `pull_request`, `pull_request_target`, `pull_request_review`, `pull_request_review_comment` | The target branch of the pull request. | `main` |
+| `gitea.event.review.type` | `pull_request_review`, `pull_request_review_comment` | The kind of review: `pull_request_review_approved`, `pull_request_review_rejected` or `pull_request_review_comment`. GitHub uses `review.state` with the values `approved`, `changes_requested` and `commented`. | `pull_request_review_approved` |
+| `gitea.event.review.content` | `pull_request_review`, `pull_request_review_comment` | The body of the review. GitHub names this field `review.body`. | `Ship it` |
+| `gitea.event.changes.title.from`<br/>`gitea.event.changes.body.from` | `issues`, `issue_comment`, `pull_request` | The previous value. Only set when `action` is `edited`. | `Old title` |
+| `gitea.event.release.tag_name`<br/>`gitea.event.release.name`<br/>`gitea.event.release.body`<br/>`gitea.event.release.draft`<br/>`gitea.event.release.prerelease` | `release` | The release the event happened on. | `v1.2.3` |
+| `gitea.event.package.name`<br/>`gitea.event.package.type`<br/>`gitea.event.package.version` | `registry_package` | The package the event happened on. | `gitea` |
+| `gitea.event.workflow_run.id`<br/>`gitea.event.workflow_run.event`<br/>`gitea.event.workflow_run.status`<br/>`gitea.event.workflow_run.conclusion`<br/>`gitea.event.workflow_run.head_branch`<br/>`gitea.event.workflow_run.head_sha` | `workflow_run` | The workflow run that the event reports on. | `success` |
+
+`schedule` runs have no webhook of their own. Their payload is the payload of the push that registered the schedule, with `schedule`, `repository`, `sender` and, for organization-owned repositories, `organization` filled in.
+Only those fields are meaningful, and `sender.login` is always `gitea-actions`.
+
+## User-defined variables
+
+You can create configuration variables on the user, organization and repository level.
+The level of the variable depends on where you created it. When creating a variable, the
+key will be converted to uppercase. You need use uppercase on the yaml file.
+
+### Naming conventions
+
+The following rules apply to variable names:
+
+- Variable names can only contain alphanumeric characters (`[a-z]`, `[A-Z]`, `[0-9]`) or underscores (`_`). Spaces are not allowed.
+- Variable names must not start with the `GITHUB_` and `GITEA_` prefix.
+- Variable names must not start with a number.
+- Variable names are case-insensitive.
+- Variable names must be unique at the level they are created at.
+- Variable names must not start with `CI`.
+
+### Using variables
+
+After creating configuration variables, they will be automatically filled in the `vars` context.
+They can be accessed through expressions like `${{ vars.VARIABLE_NAME }}` in the workflow.
+
+### Precedence
+
+If a variable with the same name exists at multiple levels, the variable at the lowest level takes precedence:
+A repository variable will always be chosen over an organization/user variable.

docs/usage/issues-prs/_category_.json

@@ -0,0 +1,9 @@
+{
+  "label": "Issues & Pull Requests",
+  "position": 20,
+  "link": {
+    "type": "generated-index",
+    "slug": "/usage/issues-prs",
+    "description": "Issues and Pull Requests workflow, templates, and collaboration features"
+  }
+}

docs/usage/issues-prs/agit.md

@@ -0,0 +1,52 @@
+---
+date: "	2022-09-01T20:50:42+0000"
+slug: "agit"
+sidebar_position: 12
+aliases:
+  - /en-us/agit-setup
+  - /agit-setup
+  - /agit
+---
+
+# AGit
+
+In Gitea `1.13`, support for [AGit](https://git-repo.info/en/2020/03/agit-flow-and-git-repo/) was added. AGit enables users to create pull requests directly, even without write permissions of the repository, eliminating the need to fork it. This helps reduce the number of duplicated repositories and minimizes unnecessary disk usage.
+
+:::note
+Git version 2.29 or higher is required on the server side for this to work.
+:::
+
+## Creating PRs with AGit
+
+AGit allows to create PRs while pushing code to the remote repo.
+This can be done by pushing to a special refspec (a location identifier known to git) instead of to a branch.
+The following example illustrates this:
+
+```shell
+git push origin HEAD:refs/for/main -o topic="topic_of_my_PR"
+```
+
+The command has the following structure:
+
+```shell
+git push <remote> <local-rev>:refs/for/<branch>[/<topic>] [-o <option>[=<value>] ...]
+```
+
+- `<remote>`: The remote pointing at the target repository (not a fork!), `origin` in the example above
+- `<local-rev>`: The local branch or commit containing the changes you are proposing, `HEAD` in the example above
+- `refs/for/<branch>`: The target PR type and configuration
+  - `for`: Create a normal PR with `<branch>` as the target branch. This is the only prefix supported at the moment, `refs/draft/...` and `refs/for-review/...` are reserved for future use and do not create a PR.
+  - `<branch>`: The branch you want your changes to be merged into
+  - `<topic>`: Optional, an alternative to `-o topic=<topic>`. The push is rejected with `topic-branch is not set` if the topic is given in neither place.
+- `-o <option>[=<value>]`: Options for the PR
+  - `topic`: The topic of this change. It will become the name of the branch holding the changes waiting for review (prefixed with your user name). This is REQUIRED to trigger a pull request, unless it is already part of the refspec.
+  - `title`: The PR title (optional but recommended), only used for topics not already having an associated PR.
+  - `description`: The PR description (optional but recommended), only used for topics not already having an associated PR.
+  - `force-push=true`: Specifies whether to force-update the target branch.
+    - Note: omitting the value and using just `-o force-push` will also work.
+
+Here's another example for creating a new PR targeting `main` with `topic`, `title`, and `description`:
+
+```shell
+git push origin HEAD:refs/for/main -o topic="topic_of_my_PR" -o title="Title of the PR" -o description="# The PR Description\nThis can be **any** markdown content.\n- [x] Ok"
+```

docs/usage/issues-prs/issue-pull-request-templates.md

@@ -0,0 +1,331 @@
+---
+date: "2018-05-10T16:00:00+02:00"
+slug: "issue-pull-request-templates"
+sidebar_position: 15
+aliases:
+  - /en-us/issue-pull-request-templates
+---
+
+# Issue and Pull Request Templates
+
+Some projects have a standard list of questions that users need to answer
+when creating an issue or pull request. Gitea supports adding templates to the
+**default branch of the repository** so that they can autopopulate the form when users are
+creating issues and pull requests. This will cut down on the initial back and forth
+of getting some clarifying details.
+It is currently not possible to provide generic issue/pull-request templates globally.
+
+Additionally, the New Issue page URL can be suffixed with `?title=Issue+Title&body=Issue+Text` and the form will be populated with those strings. Those strings will be used instead of the template if there is one. See [Pre-filling Issues and Pull Requests](prefill-issues-pull-requests.md) for all parameters.
+
+## File names
+
+Possible file names for issue templates:
+
+- `ISSUE_TEMPLATE.md`
+- `ISSUE_TEMPLATE.yaml`
+- `ISSUE_TEMPLATE.yml`
+- `issue_template.md`
+- `issue_template.yaml`
+- `issue_template.yml`
+- `.gitea/ISSUE_TEMPLATE.md`
+- `.gitea/ISSUE_TEMPLATE.yaml`
+- `.gitea/ISSUE_TEMPLATE.yml`
+- `.gitea/issue_template.md`
+- `.gitea/issue_template.yaml`
+- `.gitea/issue_template.yml`
+- `.github/ISSUE_TEMPLATE.md`
+- `.github/ISSUE_TEMPLATE.yaml`
+- `.github/ISSUE_TEMPLATE.yml`
+- `.github/issue_template.md`
+- `.github/issue_template.yaml`
+- `.github/issue_template.yml`
+
+Possible file names for issue config:
+
+- `.gitea/ISSUE_TEMPLATE/config.yaml`
+- `.gitea/ISSUE_TEMPLATE/config.yml`
+- `.gitea/issue_template/config.yaml`
+- `.gitea/issue_template/config.yml`
+- `.github/ISSUE_TEMPLATE/config.yaml`
+- `.github/ISSUE_TEMPLATE/config.yml`
+- `.github/issue_template/config.yaml`
+- `.github/issue_template/config.yml`
+
+Possible file names for PR templates:
+
+- `PULL_REQUEST_TEMPLATE.md`
+- `PULL_REQUEST_TEMPLATE.yaml`
+- `PULL_REQUEST_TEMPLATE.yml`
+- `pull_request_template.md`
+- `pull_request_template.yaml`
+- `pull_request_template.yml`
+- `.gitea/PULL_REQUEST_TEMPLATE.md`
+- `.gitea/PULL_REQUEST_TEMPLATE.yaml`
+- `.gitea/PULL_REQUEST_TEMPLATE.yml`
+- `.gitea/pull_request_template.md`
+- `.gitea/pull_request_template.yaml`
+- `.gitea/pull_request_template.yml`
+- `.github/PULL_REQUEST_TEMPLATE.md`
+- `.github/PULL_REQUEST_TEMPLATE.yaml`
+- `.github/PULL_REQUEST_TEMPLATE.yml`
+- `.github/pull_request_template.md`
+- `.github/pull_request_template.yaml`
+- `.github/pull_request_template.yml`
+
+## Directory names
+
+Alternatively, users can create multiple issue templates inside a special directory and allow users to choose one that more specifically
+addresses their problem.
+
+Possible directory names for issue templates:
+
+- `ISSUE_TEMPLATE`
+- `issue_template`
+- `.gitea/ISSUE_TEMPLATE`
+- `.gitea/issue_template`
+- `.github/ISSUE_TEMPLATE`
+- `.github/issue_template`
+- `.gitlab/ISSUE_TEMPLATE`
+- `.gitlab/issue_template`
+
+Inside the directory can be multiple markdown (`.md`) or yaml (`.yaml`/`.yml`) issue templates of the form.
+
+## Syntax for markdown template
+
+```md
+---
+
+name: "Template Name"
+about: "This template is for testing!"
+title: "[TEST] "
+ref: "main"
+assignees: ["user1"]
+projects:
+  - Example Project
+labels:
+
+- bug
+- "help needed"
+
+---
+
+This is the template!
+```
+
+In the above example, when a user is presented with the list of issues they can submit, this would show as `Template Name` with the description
+`This template is for testing!`. When submitting an issue with the above example, the issue title would be pre-populated with
+`[TEST] ` while the issue body would be pre-populated with `This is the template!`.
+The issue would be assigned to `user1`.
+The issue would be assigned to the project `Example Project`.
+The issue would also be assigned two labels,
+`bug` and `help needed`, and the issue will have a reference to `main`.
+
+## Syntax for yaml template
+
+This example YAML configuration file defines an issue form using several inputs to report a bug.
+
+```yaml
+name: Bug Report
+about: File a bug report
+title: "[Bug]: "
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to fill out this bug report!
+  # some markdown that will only be visible once the issue has been created
+  - type: markdown
+    attributes:
+      value: |
+        This issue was created by an issue **template** :)
+    visible: [content]
+  - type: input
+    id: contact
+    attributes:
+      label: Contact Details
+      description: How can we get in touch with you if we need more info?
+      placeholder: ex. email@example.com
+    validations:
+      required: false
+  - type: textarea
+    id: what-happened
+    attributes:
+      label: What happened?
+      description: Also tell us, what did you expect to happen?
+      placeholder: Tell us what you see!
+      value: "A bug happened!"
+    validations:
+      required: true
+  - type: dropdown
+    id: version
+    attributes:
+      label: Version
+      description: What version of our software are you running?
+      options:
+        - 1.0.2 (Default)
+        - 1.0.3 (Edge)
+    validations:
+      required: true
+  - type: dropdown
+    id: browsers
+    attributes:
+      label: What browsers are you seeing the problem on?
+      multiple: true
+      options:
+        - Firefox
+        - Chrome
+        - Safari
+        - Microsoft Edge
+  - type: textarea
+    id: logs
+    attributes:
+      label: Relevant log output
+      description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
+      render: shell
+  - type: checkboxes
+    id: terms
+    attributes:
+      label: Code of Conduct
+      hide_label: true
+      description: By submitting this issue, you agree to follow our [Code of Conduct](https://example.com)
+      options:
+        - label: I agree to follow this project's Code of Conduct
+          required: true
+        - label: I have also read the CONTRIBUTION.MD
+          required: true
+          visible: [form]
+        - label: This is a TODO only visible after issue creation
+          visible: [content]
+```
+
+### Markdown
+
+You can use a `markdown` element to display Markdown in your form that provides extra context to the user, but is not submitted by default.
+
+Attributes:
+
+| Key   | Description                                                  | Required | Type   | Default | Valid values |
+|-------|--------------------------------------------------------------|----------|--------|---------|--------------|
+| value | The text that is rendered. Markdown formatting is supported. | Required | String | -       | -            |
+
+visible: Default is **[form]**
+
+### Textarea
+
+You can use a `textarea` element to add a multi-line text field to your form. Contributors can also attach files in `textarea` fields.
+
+Attributes:
+
+| Key         | Description                                                                                                                                                                   | Required | Type    | Default      | Valid values              |
+|-------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------|---------|--------------|---------------------------|
+| label       | A brief description of the expected user input, which is also displayed in the form.                                                                                          | Required | String  | -            | -                         |
+| hide_label  | If true, the label normally used as a headline is not visible.                                                                                                                | Optional | Boolean | false        | -                         |
+| description | A description of the text area to provide context or guidance, which is displayed in the form.                                                                                | Optional | String  | Empty String | -                         |
+| placeholder | A semi-opaque placeholder that renders in the text area when empty.                                                                                                           | Optional | String  | Empty String | -                         |
+| value       | Text that is pre-filled in the text area.                                                                                                                                     | Optional | String  | -            | -                         |
+| render      | If a value is provided, submitted text will be formatted into a codeblock. When this key is provided, the text area will not expand for file attachments or Markdown editing. | Optional | String  | -            | Languages known to Gitea. |
+
+Validations:
+
+| Key      | Description                                          | Required | Type    | Default | Valid values |
+|----------|------------------------------------------------------|----------|---------|---------|--------------|
+| required | Prevents form submission until element is completed. | Optional | Boolean | false   | -            |
+
+visible: Default is **[form, content]**
+
+### Input
+
+You can use an `input` element to add a single-line text field to your form.
+
+Attributes:
+
+| Key         | Description                                                                                | Required | Type    | Default      | Valid values |
+|-------------|--------------------------------------------------------------------------------------------|----------|---------|--------------|--------------|
+| label       | A brief description of the expected user input, which is also displayed in the form.       | Required | String  | -            | -            |
+| hide_label  | If true, the label normally used as a headline is not visible.                             | Optional | Boolean | false        | -            |
+| description | A description of the field to provide context or guidance, which is displayed in the form. | Optional | String  | Empty String | -            |
+| placeholder | A semi-transparent placeholder that renders in the field when empty.                       | Optional | String  | Empty String | -            |
+| value       | Text that is pre-filled in the field.                                                      | Optional | String  | -            | -            |
+
+Validations:
+
+| Key       | Description                                                                                      | Required | Type    | Default | Valid values                                                             |
+|-----------|--------------------------------------------------------------------------------------------------|----------|---------|---------|--------------------------------------------------------------------------|
+| required  | Prevents form submission until element is completed.                                             | Optional | Boolean | false   | -                                                                        |
+| is_number | Prevents form submission until element is filled with a number.                                  | Optional | Boolean | false   | -                                                                        |
+| regex     | Prevents form submission until element is filled with a value that match the regular expression. | Optional | String  | -       | a [regular expression](https://en.wikipedia.org/wiki/Regular_expression) |
+
+visible: Default is **[form, content]**
+
+### Dropdown
+
+You can use a `dropdown` element to add a dropdown menu in your form.
+
+Attributes:
+
+| Key         | Description                                                                                         | Required | Type         | Default      | Valid values |
+|-------------|-----------------------------------------------------------------------------------------------------|----------|--------------|--------------|--------------|
+| label       | A brief description of the expected user input, which is displayed in the form.                     | Required | String       | -            | -            |
+| hide_label  | If true, the label normally used as a headline is not visible.                                      | Optional | Boolean | false        | -            |
+| description | A description of the dropdown to provide extra context or guidance, which is displayed in the form. | Optional | String       | Empty String | -            |
+| multiple    | Determines if the user can select more than one option.                                             | Optional | Boolean      | false        | -            |
+| list        | If true, display as a list. If false, print items on one line with commas.                          | Optional | Boolean      | false        | -            |
+| options     | An array of options the user can choose from. Cannot be empty and all choices must be distinct.     | Required | String array | -            | -            |
+
+Validations:
+
+| Key      | Description                                          | Required | Type    | Default | Valid values |
+|----------|------------------------------------------------------|----------|---------|---------|--------------|
+| required | Prevents form submission until element is completed. | Optional | Boolean | false   | -            |
+
+visible: Default is **[form, content]**
+
+### Checkboxes
+
+You can use the `checkboxes` element to add a set of checkboxes to your form.
+
+Attributes:
+
+| Key         | Description                                                                                           | Required | Type    | Default      | Valid values |
+|-------------|-------------------------------------------------------------------------------------------------------|----------|---------|--------------|--------------|
+| label       | A brief description of the expected user input, which is displayed in the form.                       | Required | String  | -            | -            |
+| hide_label  | If true, the label normally used as a headline is not visible.                                        | Optional | Boolean | false        | -            |
+| description | A description of the set of checkboxes, which is displayed in the form. Supports Markdown formatting. | Optional | String  | Empty String | -            |
+| options     | An array of checkboxes that the user can select. For syntax, see below.                               | Required | Array   | -            | -            |
+
+For each value in the options array, you can set the following keys.
+
+| Key          | Description                                                                                                                              | Required | Type         | Default | Options |
+|--------------|------------------------------------------------------------------------------------------------------------------------------------------|----------|--------------|---------|---------|
+| label        | The identifier for the option, which is displayed in the form. Markdown is supported for bold or italic text formatting, and hyperlinks. | Required | String       | -       | -       |
+| required     | Prevents form submission until element is completed.                                                                                     | Optional | Boolean      | false   | -       |
+| visible      | Whether a specific checkbox appears in the form only, in the created issue only, or both. Valid options are "form" and "content".        | Optional | String array | false   | -       |
+
+visible: Default is **[form, content]**
+
+## Syntax for issue config
+
+This is a example for a issue config file
+
+```yaml
+blank_issues_enabled: true
+contact_links:
+  - name: Gitea
+    url: https://gitea.com
+    about: Visit the Gitea Website
+```
+
+### Possible Options
+
+| Key                  | Description                                           | Type               | Default     |
+|----------------------|-------------------------------------------------------|--------------------|-------------|
+| blank_issues_enabled | If set to false, the User is forced to use a Template | Boolean            | true        |
+| contact_links        | Custom Links to show in the Choose Box                | Contact Link Array | Empty Array |
+
+### Contact Link
+
+| Key   | Description                      | Type   | Required |
+|-------|----------------------------------|--------|----------|
+| name  | the name of your link            | String | true     |
+| url   | The URL of your Link             | String | true     |
+| about | A short description of your Link | String | true     |

docs/usage/issues-prs/labels.md

@@ -0,0 +1,33 @@
+---
+date: "2023-03-04T19:00:00+00:00"
+slug: "labels"
+sidebar_position: 13
+aliases:
+  - /en-us/labels
+---
+
+# Labels
+
+You can use labels to classify issues and pull requests and to improve your overview over them.
+
+## Creating Labels
+
+For repositories, labels can be created by going to `Issues` and clicking on `Labels`.
+
+For organizations, you can define organization-wide labels that are shared with all organization repositories, including both already-existing repositories as well as newly created ones. Organization-wide labels can be created in the organization `Settings`.
+
+Labels have a mandatory name, a mandatory color, an optional description, and must either be exclusive or not (see `Scoped Labels` below).
+
+When you create a repository, you can ensure certain labels exist by using the `Issue Labels` option. This option lists a number of available label sets that are [configured globally on your instance](../../administration/customizing-gitea.md#labels). Its contained labels will all be created as well while creating the repository.
+
+## Scoped Labels
+
+Scoped labels are used to ensure at most a single label with the same scope is assigned to an issue or pull request. For example, if labels `kind/bug` and `kind/enhancement` have the Exclusive option set, an issue can only be classified as a bug or an enhancement.
+
+A scoped label must contain `/` in its name (not at either end of the name). The scope of a label is determined based on the **last** `/`, so for example the scope of label `scope/subscope/item` is `scope/subscope`.
+
+## Filtering by Label
+
+Issue and pull request lists can be filtered by label. Selecting multiple labels shows issues and pull requests that have all selected labels assigned.
+
+By holding alt to click the label, issues and pull requests with the chosen label are excluded from the list.

docs/usage/issues-prs/linked-references.md

@@ -0,0 +1,194 @@
+---
+date: "2019-11-21T17:00:00-03:00"
+slug: "automatically-linked-references"
+sidebar_position: 15
+aliases:
+  - /en-us/automatically-linked-references
+---
+
+# Automatically Linked References
+
+When an issue, pull request or comment is posted, the text description is parsed
+in search for references. These references will be shown as links in the Issue View
+and, in some cases, produce certain _actions_.
+
+Likewise, commit messages are parsed when they are listed, and _actions_
+can be triggered when they are pushed to the main branch.
+
+To prevent the creation of unintended references, there are certain rules
+for them to be recognized. For example, they should not be included inside code
+text. They should also be reasonably cleared from their surrounding text
+(for example, using spaces).
+
+## User, Team and Organization Mentions
+
+When a text in the form `@username` is found and `username` matches the name
+of an existing user, a _mention_ reference is created. This will be shown
+by changing the text into a link to said user's profile, and possibly create
+a notification for the mentioned user depending on whether they have
+the necessary permission to access the contents.
+
+Example:
+
+> [@John](#), can you give this a look?
+
+This is also valid for teams and organizations:
+
+> [@Documenters](#), we need to plan for this.
+> [@CoolCompanyInc](#), this issue concerns us all!
+
+Teams will receive mail notifications when appropriate, but whole organizations won't.
+
+Commit messages do not produce user notifications.
+
+## Commits
+
+Commits can be referenced using their SHA1 hash, or a portion of it of
+at least seven characters. They will be shown as a link to the corresponding
+commit.
+
+Example:
+
+> This bug was introduced in [e59ff077](#)
+
+## Issues and Pull Requests
+
+A reference to another issue or pull request can be created using the simple
+notation `#1234`, where _1234_ is the number of an issue or pull request
+in the same repository. These references will be shown as links to the
+referenced content.
+
+The effect of creating this type of reference is that a _notice_ will be
+created in the referenced document, provided the creator of the reference
+has reading permissions on it.
+
+Example:
+
+> This seems related to [#1234](#)
+
+Issues and pull requests in other repositories can be referred to as well
+using the form `owner/repository#1234`:
+
+> This seems related to [mike/compiler#1234](#)
+
+Alternatively, the `!1234` notation can be used as well. Even when in Gitea
+a pull request is a form of issue, the `#1234` form will always link to
+an issue; if the linked entry happens to be a pull request instead, Gitea
+will redirect as appropriate. With the `!1234` notation, a pull request
+link will be created, which will be redirected to an issue if required.
+However, this distinction could be important if an external tracker is
+used, where links to issues and pull requests are not interchangeable.
+
+## Actionable References in Pull Requests and Commit Messages
+
+Sometimes a commit or pull request may fix or bring back a problem documented
+in a particular issue. Gitea supports closing and reopening the referenced
+issues by preceding the reference with a particular _keyword_. Common keywords
+include "closes", "fixes", "reopens", etc. This list can be
+[customized](../../administration/config-cheat-sheet.md) by the
+site administrator.
+
+Example:
+
+> This PR _closes_ [#1234](#)
+
+If the actionable reference is accepted, this will create a notice on the
+referenced issue announcing that it will be closed when the referencing PR
+is merged.
+
+For an actionable reference to be accepted, _at least one_ of the following
+conditions must be met:
+
+- The commenter has permissions to close or reopen the issue at the moment
+  of creating the reference.
+- The reference is inside a commit message.
+- The reference is posted as part of the pull request description.
+
+In the last case, the issue will be closed or reopened only if the merger
+of the pull request has permissions to do so.
+
+Additionally, only pull requests and commit messages can create an action,
+and only issues can be closed or reopened this way.
+
+The default _keywords_ are:
+
+- **Closing**: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved
+- **Reopening**: reopen, reopens, reopened
+
+## Time tracking in Pull Requests and Commit Messages
+
+When commit or merging of pull request results in automatic closing of issue
+it is possible to also add spent time resolving this issue through commit message.
+
+To specify spent time on resolving issue you need to specify time in format
+`@<number><time-unit>` after issue number. In one commit message you can specify
+multiple fixed issues and spent time for each of them.
+
+Supported time units (`<time-unit>`):
+
+- `m` - minutes
+- `h` - hours
+- `d` - days (equals to 8 hours)
+- `w` - weeks (equals to 5 days)
+- `mo` - months (equals to 4 weeks)
+
+Numbers to specify time (`<number>`) can be also decimal numbers, ex. `@1.5h` would
+result in one and half hours. Multiple time units can be combined, ex. `@1h10m` would
+mean 1 hour and 10 minutes.
+
+Example of commit message:
+
+> Fixed #123 spent @1h, refs #102, fixes #124 @1.5h
+
+This would result in 1 hour added to issue #123 and 1 and half hours added to issue #124.
+
+## External Trackers
+
+Gitea supports the use of external issue trackers, and references to issues
+hosted externally can be created in pull requests. However, if the external
+tracker uses numbers to identify issues, they will be indistinguishable from
+the pull requests hosted in Gitea. To address this, Gitea allows the use of
+the `!` marker to identify pull requests. For example:
+
+> This is issue [#1234](#), and links to the external tracker.
+> This is pull request [!1234](#), and links to a pull request in Gitea.
+
+The `!` and `#` can be used interchangeably for issues and pull request _except_
+for this case, where a distinction is required. If the repository uses external
+tracker, commit message for squash merge will use `!` as reference by default.
+
+## Issues and Pull Requests References Summary
+
+This table illustrates the different kinds of cross-reference for issues and pull requests.
+In the examples, `User1/Repo1` refers to the repository where the reference is used, while
+`UserZ/RepoZ` indicates a different repository.
+
+| Reference in User1/Repo1    | Repo1 issues are external | RepoZ issues are external | Should render                                           |
+| --------------------------- | :-----------------------: | :-----------------------: | ------------------------------------------------------- |
+| `#1234`                     |            no             |            -              | A link to issue/pull 1234 in `User1/Repo1`              |
+| `!1234`                     |            no             |            -              | A link to issue/pull 1234 in `User1/Repo1`              |
+| `#1234`                     |            yes            |            -              | A link to _external issue_ 1234 for `User1/Repo1`       |
+| `!1234`                     |            yes            |            -              | A link to _PR_ 1234 for `User1/Repo1`                   |
+| `User1/Repo1#1234`          |            no             |            -              | A link to issue/pull 1234 in `User1/Repo1`              |
+| `User1/Repo1!1234`          |            no             |            -              | A link to issue/pull 1234 in `User1/Repo1`              |
+| `User1/Repo1#1234`          |            yes            |            -              | A link to _external issue_ 1234 for `User1/Repo1`       |
+| `User1/Repo1!1234`          |            yes            |            -              | A link to _PR_ 1234 for `User1/Repo1`                   |
+| `UserZ/RepoZ#1234`          |            -              |            no             | A link to issue/pull 1234 in `UserZ/RepoZ`              |
+| `UserZ/RepoZ!1234`          |            -              |            no             | A link to issue/pull 1234 in `UserZ/RepoZ`              |
+| `UserZ/RepoZ#1234`          |            -              |            yes            | A link to _external issue_ 1234 for `UserZ/RepoZ`       |
+| `UserZ/RepoZ!1234`          |            -              |            yes            | A link to _PR_ 1234 for `UserZ/RepoZ`                   |
+| **Alphanumeric issue IDs:** |             -             |             -             | -                                                       |
+| `AAA-1234`                  |            yes            |            -              | A link to _external issue_ `AAA-1234` for `User1/Repo1` |
+| `!1234`                     |            yes            |            -              | A link to _PR_ 1234 for `User1/Repo1`                   |
+| `User1/Repo1!1234`          |            yes            |            -              | A link to _PR_ 1234 for `User1/Repo1`                   |
+| _Not supported_             |            -              |            yes            | A link to _external issue_ `AAA-1234` for `UserZ/RepoZ` |
+| `UserZ/RepoZ!1234`          |            -              |            yes            | A link to _PR_ 1234 in `UserZ/RepoZ`                    |
+
+_The last section is for repositories with external issue trackers that use alphanumeric format._
+
+_**-**: not applicable._
+
+:::note
+Automatic references between repositories with different types of issues (external vs. internal) are not fully supported
+and may render invalid links.
+:::

docs/usage/issues-prs/merge-message-templates.md

@@ -0,0 +1,47 @@
+---
+date: "2022-08-31T17:35:40+08:00"
+slug: "merge-message-templates"
+sidebar_position: 15
+aliases:
+  - /en-us/merge-message-templates
+---
+
+# Merge Message templates
+
+## File names
+
+Possible file names for PR default merge message templates:
+
+- `.gitea/default_merge_message/DEFAULT_TEMPLATE.md`: the default message template for all merge styles if they don't have their own templates.
+- `.gitea/default_merge_message/MERGE_TEMPLATE.md`
+- `.gitea/default_merge_message/REBASE_TEMPLATE.md`
+- `.gitea/default_merge_message/REBASE-MERGE_TEMPLATE.md`
+- `.gitea/default_merge_message/SQUASH_TEMPLATE.md`
+- `.gitea/default_merge_message/MANUALLY-MERGED_TEMPLATE.md`
+- `.gitea/default_merge_message/REBASE-UPDATE-ONLY_TEMPLATE.md`
+
+## Variables
+
+You can use the following variables enclosed in `${}` inside these templates which follow [os.Expand](https://pkg.go.dev/os#Expand) syntax:
+
+- BaseRepoOwnerName: Base repository owner name of this pull request
+- BaseRepoName: Base repository name of this pull request
+- BaseBranch: Base repository target branch name of this pull request
+- HeadRepoOwnerName: Head repository owner name of this pull request
+- HeadRepoName: Head repository name of this pull request
+- HeadBranch: Head repository branch name of this pull request
+- PullRequestTitle: Pull request's title
+- PullRequestDescription: Pull request's description
+- PullRequestPosterName: Pull request's poster name
+- PullRequestIndex: Pull request's index number
+- PullRequestReference: Pull request's reference char with index number. i.e. #1, !2
+- ClosingIssues: return a string contains all issues which will be closed by this pull request i.e. `close #1, close #2`
+- ReviewedOn: Which pull request this commit belongs to. For example `Reviewed-on: https://gitea.com/foo/bar/pulls/1`
+- ReviewedBy: Who approved the pull request before the merge. For example `Reviewed-by: Jane Doe <[email protected]>`
+
+## Rebase
+
+When rebasing without a merge commit, `REBASE_TEMPLATE.md` modifies the message of the last commit. The following additional variables are available in this template:
+
+- CommitTitle: Commit's title
+- CommitBody: Commits's body text