Gitea与Jenkins联动：Webhook自动化构建实战指南

最新推荐文章于 2026-06-13 15:51:20 发布
原创 最新推荐文章于 2026-06-13 15:51:20 发布 · 273 阅读 · 2 ·
本内容遵循CC 4.0 BY-SA版权协议
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
GEO检测

AI 驱动代码审查实战

Claude code-review 插件深度解析，把 AI 智能审查接进 CI/CD 流水线

一键订阅

1. 为什么你需要Gitea+Jenkins的自动化构建？

如果你和我一样，是个喜欢折腾代码的开发者，肯定经历过这样的场景：每次在本地写完一段代码，提交到仓库后，还得手动登录到服务器，执行一堆构建、测试、部署的命令。一次两次还行，项目迭代频繁的时候，这种重复劳动简直让人抓狂。更别提有时候提交完就忘了去构建，导致测试环境还是老代码，测试同学跑过来问：“你这功能怎么没生效啊？” 场面一度十分尴尬。

所以，自动化构建就成了我们“偷懒”的刚需。它的核心思想很简单：让代码提交这个动作，自动触发后续的构建、测试、部署等一系列流水线操作。你只管提交代码，剩下的交给机器。这不仅能解放我们的双手，更重要的是能确保每次提交都能得到一致的、可重复的构建结果，是保障软件质量、实现持续集成（CI）的第一步。

在众多的自动化方案里，Gitea + Jenkins 的组合是我个人非常推荐，尤其适合中小团队或个人开发者的黄金搭档。为什么这么说呢？

  • Gitea：一个用Go语言写的轻量级Git服务，你可以把它理解成一个自建的、功能精简版的GitHub或Gitee。它部署简单，资源占用小，完全由你自己掌控，不用担心代码托管在第三方平台的安全和隐私问题。对于公司内部项目或者个人私有项目，Gitea是绝佳选择。
  • Jenkins：自动化界的老牌王者，一个开源的、功能极其强大的持续集成和持续交付（CI/CD）工具。它就像一个万能的工作流引擎，你可以通过它来定义任何你想要的自动化任务，比如编译Java项目、运行Python脚本、构建Docker镜像、部署到服务器等等。

把它们俩用Webhook这个“小钩子”连起来，整个流程就通了：你在Gitea上提交代码，Gitea会通过Webhook主动给Jenkins发送一个“代码有更新啦”的HTTP通知，Jenkins收到通知后，立刻启动你预设好的构建任务。整个过程全自动，无需人工干预。

我自己的几个个人项目和小团队项目，都是用这套组合拳搭建的自动化流水线。实测下来非常稳，再也没为手动构建烦心过。接下来，我就手把手带你从零开始，把这套系统搭起来，并且把我在搭建过程中踩过的坑、总结的经验都分享给你，保证你跟着做一遍就能成功。

2. 搭建前的环境准备与规划

俗话说，磨刀不误砍柴工。在开始敲命令之前，我们先花点时间把环境和思路理清楚，能避免后面很多莫名其妙的错误。我最初就是没规划好，导致网络不通，调试了大半天。

2.1 选择你的部署方式

首先，你得决定Gitea和Jenkins以什么形式运行。现在主流就两种方式：直接在宿主机上安装，或者用Docker容器化部署。

  • 宿主机直接安装：最传统的方式。你需要分别在服务器上安装Java环境（Jenkins需要）、Git、以及Gitea或Jenkins的安装包。优点是直观，进程管理简单；缺点是环境容易污染，升级和迁移比较麻烦。
  • Docker容器化部署：我强烈推荐的方式。用Docker把Gitea和Jenkins分别装在独立的容器里。好处太多了：环境隔离干净，不会互相影响；一个docker run命令就能启动，部署极其简单；版本升级和备份恢复也方便。本文的实战也将以Docker部署为主来讲解，因为它更符合现代运维的习惯。

我的生产环境选择是：Gitea用Docker部署，Jenkins也采用Docker部署。这样两者地位对等，都通过Docker管理，非常清爽。

2.2 搞定网络访问：最关键的一步

这是新手最容易栽跟头的地方，也是我踩过最深的一个坑。我们必须要明确：Gitea的Webhook需要能通过网络成功访问到Jenkins提供的URL。

假设你的服务器IP是 192.168.1.100。

  • Jenkins容器内部可能监听 8080 端口。
  • 你通过Docker将宿主机的 8080 端口映射到了Jenkins容器的 8080 端口。所以，你在浏览器访问 http://192.168.1.100:8080 就能看到Jenkins。
  • 那么，Gitea的Webhook里填写的目标URL，也必须是 http://192.168.1.100:8080/... 这个宿主机地址。

问题来了：如果Gitea也运行在容器里，那么从Gitea容器内部，是否能访问到宿主机的 192.168.1.100:8080 呢？这取决于Docker的网络模式和你服务器的防火墙设置。

我的经验是：为了简单起见，在测试环境或内部网络中，你可以让Gitea容器使用 host 网络模式（--network host），这样它就直接使用宿主机的网络栈，访问 localhost:8080 就等于访问宿主机端口，非常方便。但在更严谨的生产环境，或者需要跨主机访问时，你需要确保容器能访问到宿主机的真实IP，并且宿主机的防火墙（如firewalld、iptables）开放了相应端口。

我当初在Azure的虚拟机上就遇到了大麻烦。Azure默认的网络策略和防火墙规则非常严格，导致容器既访问不了宿主机，也访问不了外网，Webhook测试永远失败。后来就是通过调整防火墙规则，将Docker的网桥接口（通常是docker0）加入到“信任区域”，才解决了问题。这个具体的排错命令，我会在后面的疑难解答章节详细给出。

2.3 安装必要的软件

假设你有一台干净的CentOS 8或者Ubuntu 20.04/22.04的服务器。我们需要先安装Docker和Docker Compose。

安装Docker：

# 卸载旧版本（如果有）
sudo yum remove docker*  # CentOS
# 或 sudo apt-get remove docker docker-engine docker.io containerd runc # Ubuntu

# 安装yum-utils / apt-transport-https等工具
sudo yum install -y yum-utils
# 或 sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl gnupg lsb-release

# 添加Docker官方仓库
sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
# 或 curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
# 然后添加源

# 安装Docker引擎
sudo yum install -y docker-ce docker-ce-cli containerd.io
# 或 sudo apt-get update && sudo apt-get install -y docker-ce docker-ce-cli containerd.io

# 启动Docker并设置开机自启
sudo systemctl start docker
sudo systemctl enable docker

# 将当前用户加入docker组，避免每次都要sudo
sudo usermod -aG docker $USER
# 退出终端重新登录生效

安装Docker Compose：

# 下载最新稳定版的Docker Compose
sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

# 赋予执行权限
sudo chmod +x /usr/local/bin/docker-compose

# 验证安装
docker-compose --version

好了，基础环境准备完毕。接下来，我们就正式进入实战环节，先把两位“主角”请上场。

3. 实战第一步：用Docker快速部署Gitea和Jenkins

我们用Docker Compose来管理这两个服务，这样只需要一个配置文件，就能统一启动、停止和管理，比单独运行两条docker run命令要优雅得多。

3.1 编写Docker Compose配置文件

在你的服务器上创建一个目录，比如 ~/ci-cd，然后进入这个目录，创建 docker-compose.yml 文件。

mkdir ~/ci-cd && cd ~/ci-cd
vim docker-compose.yml

将以下内容粘贴进去。这是我调整过多次，比较稳定的一个配置：

version: '3.8'

services:
  gitea:
    image: gitea/gitea:latest
    container_name: my_gitea
    restart: always
    environment:
      - USER_UID=1000
      - USER_GID=1000
      - DB_TYPE=sqlite3 # 使用SQLite，简单。生产环境建议用MySQL/PostgreSQL
    volumes:
      - ./gitea_data:/data
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "3000:3000" # 网页访问端口
      - "2222:22"   # SSH克隆端口
    # network_mode: "host" # 如果网络有问题，可以尝试启用host模式，注释掉ports

  jenkins:
    image: jenkins/jenkins:lts-jdk11
    container_name: my_jenkins
    restart: always
    user: root # 为了避免权限问题，这里使用root，生产环境建议细粒度控制
    environment:
      - JAVA_OPTS=-Djenkins.install.runSetupWizard=false # 跳过初始安装向导（需要提前初始化）
    volumes:
      - ./jenkins_home:/var/jenkins_home
      - /var/run/docker.sock:/var/run/docker.sock # 挂载Docker套接字，让Jenkins能调用宿主机的Docker（用于构建镜像等）
      - /usr/bin/docker:/usr/bin/docker # 挂载Docker客户端（可选，但推荐）
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    ports:
      - "8080:8080"
      - "50000:50000" # Jenkins Agent端口

对这个配置的几点关键解释：

  1. 数据持久化：volumes 部分把容器内的 /data（Gitea）和 /var/jenkins_home（Jenkins）目录映射到了宿主机的当前目录下的子文件夹。这样即使容器删除，你的代码仓库和Jenkins的所有配置、任务都不会丢失。
  2. 时区设置：挂载了宿主机的时区文件，确保容器内时间显示正确。
  3. Jenkins的Docker in Docker（DinD）：我们挂载了 /var/run/docker.sock 和 /usr/bin/docker。这允许在Jenkins的构建任务中，直接使用宿主机的Docker引擎来构建和推送镜像，这是实现CI/CD流水线的关键一步。注意：这带来了一定的安全风险，在生产环境中需要结合其他安全措施。
  4. 网络：目前两个容器都使用Docker Compose创建的默认网络，它们之间可以通过服务名（gitea, jenkins）互相访问。但Webhook需要从Gitea访问Jenkins的宿主机端口，所以URL里还是得用宿主机的IP。

3.2 启动服务并完成初始化

保存文件后，在 ~/ci-cd 目录下执行：

docker-compose up -d

-d 参数代表后台运行。用 docker-compose ps 可以查看状态，用 docker-compose logs -f [service_name] 可以查看实时日志。

等待几十秒，服务启动后：

  1. 访问 http://你的服务器IP:3000，你会看到Gitea的首次安装界面。按照提示设置管理员账号、数据库路径（保持默认的SQLite即可）、站点名称等。完成后登录。
  2. 访问 http://你的服务器IP:8080，你会看到Jenkins的解锁页面。你需要从日志中获取初始管理员密码。
    docker-compose logs jenkins | grep -A 2 -B 2 "password"
    找到密码后，在网页输入，然后选择“安装推荐的插件”。等待插件安装完成，创建第一个管理员用户。

至此，Gitea和Jenkins就已经在容器中欢快地跑起来了。接下来，我们要让它们认识一下，并建立起“代码一提交，Jenkins就开工”的自动触发机制。

4. 核心联动：配置Gitea Webhook触发Jenkins构建

这是整个自动化流程的“神经中枢”。原理就是：Gitea在发生特定事件（如推送代码）时，向一个预设的URL（Jenkins提供的地址）发送一个HTTP POST请求，请求中携带了这次提交的详细信息。Jenkins有一个插件专门监听这个URL，收到请求后，就解析其中的数据，并触发对应的构建任务。

4.1 在Jenkins中安装并配置Gitea插件

Jenkins默认可能不支持Gitea的Webhook，我们需要安装一个插件来增强它的能力。

  1. 安装插件：登录Jenkins，点击 系统管理 -> 插件管理 -> 可选插件。在搜索框输入 Gitea，找到名为 “Gitea” 的插件，勾选并安装。安装完成后需要重启Jenkins（安装界面通常有重启按钮）。
  2. 配置Gitea服务器连接：重启后，进入 系统管理 -> 系统配置。滚动找到 “Gitea” 配置区域。
    • Gitea 服务器：点击“添加Gitea服务器”。
    • 名称：随便起，比如 MyGitea。
    • 服务器URL：填写你的Gitea访问地址，例如 http://你的服务器IP:3000。这里有个大坑：如果Jenkins容器内无法直接通过宿主机IP访问Gitea（比如在复杂的Docker网络下），你可能需要填写Gitea容器的内部服务名和端口，如 http://gitea:3000。但Webhook是Gitea发起的，所以这个地址主要是用于Jenkins在界面上显示仓库信息等，Webhook触发本身不依赖这个地址。可以先按宿主机IP填写。
    • 凭据：点击“添加”，选择“Jenkins”。在弹窗中，种类选择“Username with password”。用户名和密码填写你在Gitea上登录的账号密码。这个凭据用于Jenkins拉取Gitea私有仓库的代码。添加成功后，在下拉框中选择它。
    • 其他保持默认，点击“保存”。

4.2 在Gitea上准备一个测试项目

登录Gitea，点击右上角的 “+” 号，创建一个新的仓库，比如叫 hello-ci。创建时可以选择初始化README文件。创建好后，将其克隆到你的本地开发机：

git clone http://你的服务器IP:3000/你的用户名/hello-ci.git
cd hello-ci

创建一个简单的文件，比如一个 index.html，或者一个 main.py，然后提交并推送到Gitea。

echo "# Hello CI/CD Pipeline" >> README.md
git add .
git commit -m "Initial commit with README"
git push origin main

这样，我们的代码仓库就有了内容，可以用来触发构建。

4.3 创建Jenkins的自动化构建任务

现在回到Jenkins，我们要创建一个任务，当Gitea的Webhook通知到来时，就执行这个任务。

  1. 新建任务：点击Jenkins首页的“新建任务”。
  2. 输入任务名称，例如 hello-ci-pipeline，选择“构建一个自由风格的软件项目”，点击确定。
  3. 源码管理：在配置页面，找到“源码管理”部分，选择 Git。
    • Repository URL：填写你的Gitea仓库的克隆地址，例如 http://你的服务器IP:3000/你的用户名/hello-ci.git。
    • Credentials：选择你刚才在系统配置里添加的Gitea用户名密码凭据。如果没出现，点“添加”按钮现场创建一个。
    • 分支：在“指定分支”处填写 */main（如果你的主分支叫main）。
  4. 构建触发器：这是最关键的一步！找到“构建触发器”部分。
    • 勾选“触发远程构建”。这会生成一个认证令牌和一个URL。
    • 在“身份验证令牌”输入框里，设置一个密码，比如 MY_SECRET_TOKEN_123。这个令牌很重要，相当于Webhook请求的密码，防止别人随意触发你的构建。记下这个令牌。
    • 勾选后，页面上方会显示一行提示，告诉你远程构建的URL格式是：JENKINS_URL/job/JOB_NAME/build?token=TOKEN_NAME。例如：http://192.168.1.100:8080/job/hello-ci-pipeline/build?token=MY_SECRET_TOKEN_123。把这个完整的URL复制下来，我们马上要在Gitea里用到它。
  5. 构建步骤：在“构建”部分，点击“增加构建步骤”，选择“执行shell”（如果是Linux）或“Execute Windows batch command”（如果是Windows）。在命令框里，我们可以写一些简单的命令来验证构建被触发了。例如：
    echo "=== 构建开始 ==="
echo "当前目录："
pwd
echo "代码仓库内容："
ls -la
echo "构建时间：$(date)"
echo "=== 构建结束 ==="
  6. 点击页面底部的“保存”。

4.4 在Gitea中配置Webhook

现在，我们去告诉Gitea：“当这个仓库有推送时，请通知上面那个Jenkins URL”。

  1. 登录Gitea，进入你的 hello-ci 仓库。
  2. 点击“设置” -> “Web钩子” -> “添加Web钩子”。
  3. 钩子类型：选择 “Gitea”。（如果没看到Gitea，选择“Generic”通用型也可以，但Gitea类型能传递更丰富的信息）。
  4. 目标URL：粘贴你从Jenkins任务配置里复制的那个URL，即 http://你的服务器IP:8080/job/hello-ci-pipeline/build?token=MY_SECRET_TOKEN_123。
  5. HTTP请求方法：选择 POST。这里特别注意：原始文章里选了GET，但对于传递较多数据的Webhook，POST是更标准和安全的方式。Jenkins的“触发远程构建”也支持POST请求。
  6. POST Content Type：选择 application/json。
  7. 触发事件：至少勾选“推送事件”。这样每次 git push 就会触发。
  8. 其他选项可以保持默认，然后点击“添加Web钩子”。

4.5 进行首次测试

钩子添加成功后，页面会显示出来。你可以直接点击右侧的“测试推送”按钮。Gitea会模拟一次推送事件，向Jenkins发送Webhook请求。

然后，立刻切换到Jenkins页面，进入 hello-ci-pipeline 任务。你应该会看到任务队列里多了一个构建任务，或者正在构建中。点击进入构建历史，查看“控制台输出”。如果一切顺利，你会看到你刚才在Shell里写的那些echo命令的输出，最后显示“Finished: SUCCESS”。

恭喜！ 至此，最核心的自动化链路已经打通了。你现在可以尝试在本地修改 hello-ci 仓库的代码，然后执行 git add, git commit, git push。推送到Gitea后，稍等几秒钟，刷新Jenkins页面，你会发现一个新的构建自动开始了。这种“代码即部署”的自动化感觉，是不是很棒？

5. 进阶配置与优化技巧

基础流程跑通后，我们可以让它变得更强大、更智能。这里分享几个我实践中觉得非常有用的进阶配置。

5.1 使用Pipeline as Code（Jenkinsfile）

上面我们创建的是“自由风格”项目，构建步骤在Jenkins网页上配置。这种方式对于简单任务还行，但无法进行版本控制，也不利于复杂流水线的编写和维护。更好的方式是使用 Jenkins Pipeline，并将流水线脚本（Jenkinsfile）放在代码仓库的根目录下。这样，流水线的定义就和代码在一起，可以跟随代码一起被版本管理、评审和修改。

  1. 在代码仓库创建Jenkinsfile： 在你的 hello-ci 项目根目录，创建一个名为 Jenkinsfile 的文件（没有后缀）。
    pipeline {
    agent any // 在任何可用的代理上执行
    stages {
        stage('Checkout') {
            steps {
                checkout scm // 拉取代码
            }
        }
        stage('Build & Test') {
            steps {
                sh 'echo "开始构建..."'
                // 这里可以放入你真实的构建命令，例如：
                // sh 'mvn clean package' // 对于Java Maven项目
                // sh 'npm install && npm run build' // 对于Node.js项目
                sh 'echo "模拟运行单元测试..."'
            }
        }
        stage('Deploy') {
            steps {
                sh 'echo "部署到测试环境..."'
                // 例如：将构建产物拷贝到服务器，或调用部署脚本
            }
        }
    }
    post {
        always {
            echo '当前流水线阶段已结束。'
            // 可以在这里发送构建通知，如邮件、钉钉、Slack等
        }
        success {
            echo '构建成功！'
        }
        failure {
            echo '构建失败！'
        }
    }
}
    将这个文件提交并推送到Gitea。
  2. 修改Jenkins任务：
    • 回到Jenkins，修改 hello-ci-pipeline 任务的配置。
    • 在“流水线”部分（如果你创建的是流水线类型任务），或者将项目类型改为“流水线”。
    • 在“定义”处，选择 “Pipeline script from SCM”。
    • SCM选择Git，并填写你的仓库地址和凭据。
    • 在“脚本路径”中，填写 Jenkinsfile（默认就是它）。
    • 保存配置。

现在，你的整个构建流程都由仓库里的 Jenkinsfile 定义了。每次推送代码，Jenkins会拉取最新的代码和最新的 Jenkinsfile，然后按照里面定义的阶段（stage）依次执行。这种方式清晰、强大，是Jenkins CI/CD的最佳实践。

5.2 优化Webhook触发条件

在Gitea的Webhook设置里，除了“推送事件”，你还可以精细化控制触发条件：

  • 仅推送特定分支：比如只监听 main 或 develop 分支的推送。
  • 仅推送特定标签。
  • 监听Pull Request事件：当有新的PR创建、更新或合并时触发。这对于需要跑PR预合并检查（如代码风格检查、单元测试）的场景非常有用。

你可以在Gitea Webhook的“触发事件”部分，根据需要勾选更多事件类型。在Jenkins这边，Gitea插件也能很好地解析这些事件，你可以在Pipeline脚本中通过环境变量（如 env.giteaEvent）来判断是什么事件，从而执行不同的逻辑。

5.3 安全加固：使用Webhook Secret

我们之前使用了URL中的token参数作为认证，这已经有一定安全性。但更推荐的方式是使用 Webhook Secret。Gitea在发送Webhook请求时，会在HTTP头中携带一个签名（通常放在 X-Gitea-Signature 或 X-Hub-Signature-256 头中），这个签名由你设置的Secret和请求体内容计算得出。Jenkins端用同样的Secret进行验证，只有签名匹配的请求才会被处理，这能有效防止伪造的Webhook请求。

  1. 在Gitea Webhook设置中：找到“密钥”或“Secret”输入框，填入一个复杂的字符串，例如 MySuperSecret123!@#。
  2. 在Jenkins任务配置中：在“构建触发器”部分，取消“触发远程构建”的勾选。找到“Gitea触发器”相关的选项（需要Gitea插件支持），勾选“根据Gitea的推送事件触发构建”，并在“Secret”字段填入和Gitea中一样的密钥。

这样配置后，安全性就更高了。

6. 疑难杂症与排错指南

自动化流程搭建过程中，十有八九会遇到问题。我把最常见的问题和解决方法总结在这里，希望能帮你快速排雷。

6.1 Webhook测试失败：网络连接问题

这是头号杀手。表现是：在Gitea点击“测试推送”，一直显示失败（红色叉号），或者超时。

排查思路：

  1. 从Gitea容器内部测试连接Jenkins URL：

    # 进入Gitea容器
docker exec -it my_gitea /bin/sh
# 尝试用curl访问Jenkins的触发URL
curl -v http://宿主机IP:8080/job/hello-ci-pipeline/build?token=MY_SECRET_TOKEN_123
    • 如果 curl 成功并返回类似“Triggered”的响应，说明网络是通的，问题可能出在别处。
    • 如果 curl 报错 Connection refused 或超时，那肯定是网络不通。

  2. 解决网络不通：

    • 检查Jenkins容器端口映射：确保 docker-compose.yml 中Jenkins的 8080 端口已正确映射到宿主机。
    • 检查宿主机防火墙：这是最可能的原因。你需要开放宿主机的8080端口（以及Jenkins的端口）。
      # 对于firewalld（CentOS/RHEL）
sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --permanent --add-port=3000/tcp # Gitea端口也一并开放
sudo firewall-cmd --reload
    • 解决容器无法访问宿主机IP的问题（特别是云服务器）：我在Azure上遇到的正是这个问题。容器网络与宿主机防火墙策略冲突。解决方案是调整防火墙规则，允许容器网络流量。根据我找到的资料，执行了以下命令：
      # 将Docker的默认网桥docker0加入到防火墙的信任区域
sudo firewall-cmd --permanent --zone=trusted --change-interface=docker0
# 允许Docker守护进程的API端口（非必须，但有时需要）
sudo firewall-cmd --permanent --zone=trusted --add-port=4243/tcp
# 重载防火墙规则
sudo firewall-cmd --reload
      执行后，再从Gitea容器内 ping 一个外网地址（如新浪）或 curl 宿主机IP，应该就能通了。注意：不同云厂商和系统版本，防火墙配置可能不同，此方法仅供参考，核心思路是找到并信任Docker的网络接口。

6.2 Webhook成功但Jenkins不构建

表现是：Gitea显示Webhook发送成功（绿色勾），但Jenkins那边毫无反应。

排查思路：

  1. 检查Jenkins的认证令牌：确认Gitea Webhook里填写的URL中的 token 参数，和Jenkins任务里配置的“身份验证令牌”完全一致，包括大小写。
  2. 检查Jenkins任务名称：URL中的 JOB_NAME（hello-ci-pipeline）必须和Jenkins任务的实际名称完全一致。
  3. 查看Jenkins系统日志：进入Jenkins的 系统管理 -> 系统日志，查看所有日志或 Gitea 相关的日志，看是否有关于Webhook请求的错误信息。
  4. 检查Gitea插件版本：确保你安装的Gitea插件是最新或兼容的版本。

6.3 Jenkins拉取Gitea代码失败

表现是：构建被触发了，但在“源码管理”步骤就失败了，报错无法克隆仓库。

排查思路：

  1. 检查凭据：确认Jenkins里配置的Git仓库地址和凭据是正确的。可以尝试在Jenkins服务器上（或Jenkins容器内）手动执行 git clone 命令，看是否需要密码。
  2. 检查网络连通性：确保Jenkins容器能访问Gitea服务器的IP和端口（3000）。可以在Jenkins容器内用 curl 测试。
  3. 如果是SSH克隆：需要将Jenkins用户的SSH公钥添加到Gitea的个人设置或部署密钥中。使用HTTP(S)+密码的方式在初期更简单。

6.4 构建脚本中的权限问题

如果你的构建步骤中涉及到文件操作、执行脚本等，可能会遇到权限不足的错误。

解决方案：

  • 确保Jenkins容器运行的用户（我们在docker-compose.yml里用了root）有足够的权限访问挂载的卷和宿主机Docker。
  • 在Shell脚本中，对于需要权限的操作，可以提前用 chmod 命令修改文件权限，或者使用 sudo（如果配置了免密）。
  • 更安全的做法是，在宿主机上为Jenkins使用的目录设置合适的用户组和权限。

搭建和调试的过程就是不断遇到问题、解决问题的过程。当你看到第一次自动化构建成功运行的那一刻，所有的折腾都是值得的。这套Gitea+Jenkins+Webhook的组合，为你构建了一个完全自主可控、高度灵活的自动化开发基础设施。你可以在此基础上，继续扩展，加入代码质量扫描、自动化测试、镜像构建与推送、自动部署等更多阶段，打造出一条完整的、属于你自己的CI/CD流水线。

AI 驱动代码审查实战

Claude code-review 插件深度解析，把 AI 智能审查接进 CI/CD 流水线

一键订阅
标签
#Gitea #Jenkins #Webhook #自动化构建
Gitea代码提交联动Jenkins自动构建：Webhook配置全攻略
weixin_29196613的博客
03-08 124
本文详细介绍了如何配置Gitea与Jenkins的Webhook联动，实现代码提交后自动触发构建的完整流程。从环境准备、网络连通性检查，到Jenkins任务创建、Gitea Webhook配置，再到流水线脚本编写与安全加固，提供了全攻略指南，帮助开发者搭建高效、稳定的自动化CI/CD流水线。
Jenkins+Gitea自动化部署实战：5分钟搞定Webhook配置（含常见错误排查）
weixin_30897233的博客
03-21 157
本文详细介绍了如何通过Jenkins与Gitea实现自动化部署，包括Webhook配置、常见错误排查及优化技巧。通过5分钟快速配置指南，帮助开发者高效搭建CI/CD流程，提升团队开发效率。重点解析了Gitea与Jenkins的Webhook集成方法及常见问题解决方案。
Gitea 仓库事件触发Jenkins远程构建
专注于计算机研发知识和资讯分享
07-13 2841
高版本Jenkins需要关闭跨域限制和开启匿名用户访问。Gitea支持用于仓库事件的Webhooks。2. 设置匿名用户可访问。
用Docker玩转Gitea+Jenkins联动：Webhook自动部署的完整配置流程
weixin_28347369的博客
03-07 288
本文详细介绍了在Docker环境下配置Gitea与Jenkins实现Webhook自动部署的完整流程。重点解决了容器化部署中网络互通、SSH密钥管理、数据持久化权限等核心难题，并提供了生产环境下的安全加固与故障排查指南，帮助开发者构建稳定高效的自动化CI/CD流水线。
配置自动化部署Jenkins和Gitea
Bunny的博客
11-29 3991
先说下自己的情况，因为自己服务器原因，使用的服务器内存太小只有4g，如果这时候再使用进行打包时会出现卡死，因为占用内存会比较多所以会很卡，导致访问服务器时卡顿非常严重，比如有些服务无法访问等。在下面的介绍中，我将使用本地打包的方式，打包完成后在推送到服务器上，如果你的服务器性能出色可以我也将在这里介绍如何在服务器中线上打包。除此之外线下打包之后推送好处是，节省了服务器的内存消耗，因为打包所以要下载相关的包。
Gitea提交代码自动触发Jenkins构建版本
laziji的专栏
02-22 1331
http://192.168.0.136:8090 为jenkisn地址，/generic-webhook-trigger/invoke?token= 固定不变，ruoyi-ui-8978456465 这个Jenkins中配置的token 值。获取到WebHooks 地址，git服务器（gitlab,gitee,gitea,）添加webhook，,这个时候提交代码可以触发自动构建完成。
使用Gitea和Jenkins实现代码管理和自动化部署
waitting_in_love的博客
11-18 6055
许多个人开发者或者小型公司会有小型的代码管理和自动化部署的需求，今天给大家带来一套代码管理和自动化部署体系的搭建教程，希望能对大家有所帮助。
Gitea和Jenkins安装
Bunny的博客
11-27 1797
可以参考官方文档-https://docs.gitea.cn/1.20/installation/database-prep，这里以MySQL作为讲解。下载Gitea二进制文件：从Gitea的官方网站（https://gitea.io/）下载适用于CentOS 7的二进制文件。如果这种方式下载速度太慢，建议直接去下载官网下载：https://dl.gitea.com/gitea/创建一个将被 Gitea 使用的数据库用户，并使用密码进行身份验证。将数据库上的所有权限授予上述创建的数据库用户。
Gitea+Jenkins自动化构建实战：5分钟搞定Webhook配置（附Azure避坑指南）
weixin_29215815的博客
03-08 55
本文详细介绍了在Azure环境中部署Gitea与Jenkins自动化构建流水线的实战指南。重点解析了Webhook配置的核心步骤，并针对Azure云服务器常见的容器网络隔离问题，提供了关键的防火墙配置解决方案，确保代码提交后能可靠触发Jenkins自动构建。
小内存服务器的福音：用Gitea替代GitLab，搭配Jenkins打造轻量级CI/CD（附避坑指南）
最新发布
weixin_31714129的博客
06-13 252
本文详细介绍了如何在小内存服务器上使用Gitea替代GitLab，并结合Jenkins构建轻量级CI/CD系统。通过资源消耗对比、系统优化、安装配置实战及自动化部署方案，帮助开发者在有限资源下实现高效的代码管理和自动化部署，特别适合个人开发者和小团队使用。
Kubernetes原生CI/CD栈部署实践：Jenkins+Gitea+Registry一体化方案
weixin_30542079的博客
05-02 634
持续集成与持续部署（CI/CD）是现代软件工程的核心实践，旨在通过自动化流程提升软件交付效率与质量。其核心原理在于将代码提交、构建、测试、打包和部署等环节串联为自动化流水线，从而减少人工干预，实现快速、可靠的软件发布。在云原生时代，容器化和Kubernetes编排技术为CI/CD提供了理想的运行环境，使得构建代理可以动态创建、资源得以高效利用。Jenkins作为老牌自动化服务器，凭借其强大的插件生态和流水线即代码能力，依然是许多团队构建CI/CD系统的首选。通过将其与轻量级Git服务（如Gitea）、私有镜
告别Jenkins臃肿配置，1Panel+Node轻量化前端自动化实战指南
weixin_28831461的博客
01-29 569
本文详细介绍了如何利用1Panel+Node替代Jenkins实现轻量化前端自动化部署。通过对比Jenkins的高资源占用和复杂配置，展示了1Panel+Node方案在内存占用（<100MB）、配置简化和环境灵活性方面的优势，并提供了从环境准备、Webhook服务搭建到安全加固的完整实战指南，帮助开发者高效实现自动化部署流程。
30分钟快速1:1 复刻企业级 DevOps 架构实战（八）k8s内部安装Prometheus
echo的博客
06-11 228
本文提供k3s环境下Prometheus+Grafana监控系统的快速部署方案。通过Helm一键安装（1分钟完成），包含Grafana看板自动配置（推荐编号15760、16240等6个常用看板）和钉钉/企业微信告警集成。详细步骤包括：创建监控命名空间、Helm安装、获取访问地址（默认账号admin/prom-operator）、导入预置看板、配置钉钉机器人告警。同时提供Jenkins、Gitea、Nexus等常用服务的监控配置方法，形成完整的CI/CD监控链路。所有看板导入即用，告警自动包含关键异常信息。
Gitea+Jenkins+webhooks-多分支触发+备份构建前端资源
mingqing的博客
06-29 3359
Jenkins的插件安装，在插件管理中安装Generic Webhook Trigger用于gitea构建触发器，Blue Ocean可以理解为Jenkins的一个皮肤（个人感觉界面看起来和操作使用很舒服）安装插件 关于Jenkins准备工作，已经基本做完，下一步将使用gitea中的webhooks与Jenkins进行联系，达到代码自动部署的效果首先，我们先点新建任务，进入到任务列表，接下来，我将分享两种构建的方式，分别是批处理命令构建和pipeline流水线语法的方式构建在任务配置中输入gitea clo
getea上代码提交后通过webhook触发jenkins进行构建
10-15 4629
1. 环境 azure centos 8 、gitea， jenkins 2.创建gitea代码项目 3.创建jenkins任务 a. 配置gitea代码仓库，就是刚才的gitea项目的地址，然后创建访问的账号，用户名和密码方式。 b.勾选触发器的第一项“”触发远程构建“”，在输入框里输入安全点的密码。然后把红框中的url复制到gitea的web hook的界面 注意jenkins_url和token_name要分别替换成真实的ip或者域名和刚才输入的安全字符串。 4.配置git..
CentOS+Jenkins+Gitea+宝塔环境搭建 实现自动化部署
A1311878170的博客
03-18 2777
CentOS+Jenkins + Gitea+宝塔 实现CI/CD 一、安装最新版 Jenkins 1、安装 JAVA JDK yum -y install java [root@ecs-487c-0002 ~]# java -version openjdk version "1.8.0_302" OpenJDK Runtime Environment (build 1.8.0_302-b08) OpenJDK 64-Bit Server VM (build 25.302-b08, mixed mod
前端项目搭建部署全流程（五）：基于Jenkins与gitea的自动化部署
huhaiqing106的博客
02-20 1146
1. 前言 继上一篇文章之后，我们可以基于写的脚手架工程初始化一个项目工程，然后基于这个工程提交搞Gitea服务，实现基于Jenkins的自动化部署与Gitea的webhook钩子，以便在执行git push的时候，自动构建项目。 2. 搭建Gitea托管服务器 下载Gitea安装文件 https://dl.gitea.io/gitea， 我下载的是gitea-1.13.1-windows-4.0-amd64.exe版本 下载完成后，在本地磁盘建立一个Gitea目录，然后在该目录下执行安装文件 然后打开l
Gitea+Jenkins能碰撞出怎样的火花？浅谈前端自动化部署
00后|互联网💻|办公室🍵茶农，希望通过技术改变生活|爱折腾💪|收集各类📚网络资源，好物不私藏，点点关注，不迷路。 全网搜：阿宇的编程之旅 or 阿宇的宝库
11-28 3006
​前言： 一个好的部署工具能帮助开发者提升效率，节省时间，本文将与大家分享私有化Git仓库搭建与Jenkins操作项目部署 准备工作： Java环境 Node环境 Gitea Jenkins Nginx(部署前端页面) 服务器或者电脑（我这里是window系统+公网映射搭建的本地服务器） 首先是搭建一个本地Git代码仓库 下载gitea并在需要安装的文件夹下打开，默认访问地址是127.0.0.1:3000 打开后选择一下数据库，并在对应文件夹下生成db文件（新建空白txt文件，改后缀名为db）
Jenkins 与 Gitea 的集成插件
gitblog_00110的博客
01-14 571
Jenkins 与 Gitea 的集成插件 1. 项目基础介绍 Jenkins Gitea 插件 是一个开源项目，旨在为 Jenkins 提供与 Gitea 的集成功能。该项目使用 Java 作为主要的编程语言，同时也包含了少量的 HTML 和 Shell 代码。 2. 核心功能 该插件的核心功能是使 Jenkins 能够与 Gitea 版本控制系统进行无缝集成。以下是其主要功能： 代码质量检查...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值