集成 Gitea 和 Jenkins 最推荐的方式是使用Gitea Plugin，它能让 Jenkins 自动识别 Gitea 上的仓库，并通过 Webhook 实现代码推送即触发构建。
配置过程主要分为两大步：先让 Jenkins 认识 Gitea，再设置好触发方式。
🛠️ 第一步：在 Jenkins 中配置 Gitea 插件
安装插件：在 Jenkins 的“插件管理”中，搜索并安装Gitea Plugin，然后重启 Jenkins 生效。
配置 Gitea 服务器：进入“系统管理” -> “系统配置”，找到“Gitea Servers”区域，添加你的 Gitea 服务器信息：
Name：给服务器起个名字。
URL：你的 Gitea 实例地址（例如
https://gitea.your-company.com）。Credentials：点击“添加”，选择“Gitea Personal Access Token”，填入你从 Gitea 用户设置中生成的 API Token。为了能自动管理 Webhook，记得勾选“Manage hooks”。
创建并配置任务：
新建任务：在 Jenkins 首页点击“新建任务”。
选择任务类型：推荐选择Organization Folder，它会自动扫描你 Gitea 组织或用户下的所有仓库，并为包含
Jenkinsfile的仓库自动创建流水线。当然，你也可以选择创建单独的Multibranch Pipeline或Freestyle项目。配置源码：在任务的“Repository Sources”中，添加一个 Gitea 源。选择你刚配置的 Gitea 服务器和 Credentials，并在“Owner”字段填写你要集成的 Gitea 组织或用户名。
🔗 第二步：设置 Webhook 实现自动触发
这一步是让 Gitea 在代码变动时“通知”Jenkins。
推荐方式（自动）：如果你在配置 Gitea 服务器时勾选了“Manage hooks”，Jenkins 在扫描或首次构建后会自动为你在 Gitea 的对应仓库中创建所需的 Webhook，不需要你手动干预。
备选方式（手动）：你也可以手动在 Gitea 仓库的“设置” -> “Webhook”中添加：
Payload URL：填写
http://<你的Jenkins地址>/gitea-webhook/post。Content Type：选择
application/json。触发事件：勾选你希望触发构建的事件，如“推送事件”。
💡 进阶技巧与排坑
在流水线中使用 Token：如果你的流水线需要拉取私有仓库，可以在 Pipeline 脚本中使用
withCredentials步骤安全地引用你的 Gitea Personal Access Token。显示构建状态：可以安装Gitea Checks Plugin，它能让 Jenkins 把每次构建的状态（成功/失败）直接显示在 Gitea 的 Pull Request 或 Commit 页面上，方便团队协作。
常见错误：
403 错误：检查用于集成的 Jenkins 用户在 Gitea 仓库中是否拥有写（Write）权限，以便能正确提交构建状态。
CSRF 保护：如果 Webhook 因为 CSRF 问题被拒绝，可以尝试在 Jenkins 启动参数中添加
-Dhudson.security.csrf.GlobalCrumbIssuerConfiguration.DISABLE_CSRF_PROTECTION=true，但这不推荐用于生产环境。更好的方式是确保插件为最新版。
没有Gitea Plugin也不影响集成。核心思路是：让 Gitea 在代码变动时，通过 Webhook 给 Jenkins 发个“通知”，Jenkins 收到后按既定流程工作就行。这里有几种替代方案，你可以根据情况选择。
⚙️ 方案一：使用 Generic Webhook Trigger 插件（最推荐）
这是最灵活通用的办法，通过 Jenkins 的Generic Webhook Trigger Plugin来接收和处理 Gitea 的 Webhook 请求。
在 Jenkins 中：安装Generic Webhook Trigger插件。在项目的“构建触发器”中，勾选“Generic Webhook Trigger”，定义一个你喜欢的 Token（比如
my-token），并可以解析 Gitea Webhook 传递的 JSON 数据作为构建参数。在 Gitea 中：在仓库的“设置” -> “Webhook”里添加一个 Webhook。
Payload URL：填入
http://<你的Jenkins地址>/generic-webhook-trigger/invoke?token=my-token。Content Type：选择
application/json。触发事件：勾选你需要的，比如“推送事件”。
在 Jenkins Pipeline 中：用
pipeline脚本定义你的构建、测试、部署流程。
🔌 方案二：用 Gitea API 写个“胶水”脚本
如果不想依赖额外插件，可以自己写个轻量脚本（比如用 Shell 或 Python）来充当桥梁。
获取 Token：在 Gitea 用户设置里生成一个 Personal Access Token，用于后续 API 调用。
编写脚本：脚本需要完成两件事：
通过 Gitea API 检测代码库的变动（或者监听 Webhook）。
一旦检测到变动，就调用 Jenkins API 来触发对应的构建任务。
有用户在 Gitea 官方论坛分享过类似的实现思路，但这种方式更偏定制化，需要一定的开发量。
💡 方案三：换个思路，试试 Gitea Actions
如果你的 Gitea 版本在1.19 及以上，其实可以考虑直接用 Gitea 内置的Gitea Actions来做 CI/CD。它能帮你省掉 Jenkins 这一整台服务器的开销和运维成本。
轻量且集成：Gitea Actions 是原生集成的，资源占用极低（Runner 容器内存占用约200MB），相比之下 Jenkins 实例通常需要1GB以上内存。
配置简单：只需要在仓库根目录的
.gitea/workflows/*.yml文件中定义流程即可，语法和 GitHub Actions 高度相似，学习成本很低。
⚠️ 补充说明：Gitea Plugin 的现状
Jenkins 官方插件库中其实是有Gitea Plugin的，它专门用于和 Gitea 深度集成，可以自动管理 Webhook、提交构建状态等。
根据社区用户的反馈，这个插件在与“Organization Folder”类型任务配合时表现更好，如果你想为单个仓库配置 Pipeline，可能会遇到一些不便，需要额外配置或寻找替代方案（比如用通用 Webhook 触发插件）。这可能是你“找不到”它的一个原因，但这不影响我们用更通用的方式来实现集成。
所以，如果你的需求是快速搞定自动触发，方案一（Generic Webhook Trigger）是最推荐的通用做法。如果想更轻量、减少外部依赖，可以试试方案三（Gitea Actions）。