7.3 CI/CD实训一:让提交触发构建

本节目标

在之前的学习中,你已经习惯了每次修改代码后手动执行 docker builddocker push,但这在企业高频发布中容易引发操作遗漏和版本混乱。

本实训将带你跨入自动化交付的大门!我们将打通代码仓库(原料库)与Drone平台(自动生产线),学习只需执行一次“代码提交”,就能让系统自动触发环境拉取、镜像构建的完整 CI (持续集成) 基础流程。

在开启自动化构建前,我们首先要做好准备工作。这就如同接手企业的一个新项目,需要先把代码“搬”到自己的工作区,并在自动化生产线中将该项目“激活”。

在团队协作中,我们常常需要在现有项目的基础上进行二次开发。第一步,就是将项目迁移到自己的代码仓库,这样可以自由修改,而不影响原始项目。

现在,打开你的 Gitea 平台,将 https://git.seahi.me/docker/pacman 这个项目迁移到你自己的账户下。

什么是项目迁移?
项目迁移就像是给别人的代码仓库拍了张完整的“快照”,不仅复制了所有文件,还保留了完整的提交历史。迁移后,你就拥有了一个完全独立的副本作为“原材料”,可以随心所欲地进行实验。

原材料有了,我们需要告诉 Drone 这条“自动生产线”开始关注该项目。一旦激活,每当代码仓库发生变动,Drone 就能敏锐地捕捉到信号并准备工作。

  1. 打开 Drone 平台。
  2. 在项目列表中找到你刚刚迁移的 pacman 项目。
  3. 点击 ACTIVATE (激活) 按钮。
在 Drone 中找不到项目?
如果在列表中没有看到 pacman 项目,别担心。点击页面右上角的 SYNC (同步) 按钮,Drone 就会重新从 Gitea 获取最新的仓库列表。

要在本地修改代码,必须先把它从 Gitea 服务器上拉取到本地进行“加工”。这个过程叫做“克隆 (Clone)”。这里我们使用图形化 Git 工具 Sublime Merge 来完成操作。

  1. 在 Gitea 的 pacman 项目页面,复制项目的 URL 地址。
  2. 打开 Sublime Merge,在 Source URL (源地址) 栏中粘贴你复制的 URL。

复制这个网址填写到 Seblime Merge 中

将项目克隆到本地

技巧
Destination Path (目标路径) 是指项目文件夹在你电脑上的存放位置。建议选择一个方便查找的目录,比如桌面 (Desktop) 或专门的代码工作区文件夹。

克隆完成后,Sublime Merge 会自动打开项目。你可以清晰地看到每一次历史提交记录、代码分支等信息——这是保证版本可追溯的重要前提。

pacman 项目

现在代码到达了本地。原始的 pacman 只是一个前端游戏源码,我们的任务是容器化它。这就需要明确构建镜像的规则。

在 Sublime Text 编辑器中,选择 File > Open Folder,然后找到并打开刚才克隆的 pacman 项目文件夹。

Dockerfile 是构建镜像的配方。在项目根目录创建一个名为 Dockerfile 的文件。

Dockerfile文件

一切就绪后,我们需要将这个新增配方上传回 Gitea。在传统的开发模式中,提交完接下来你就该手工敲构建命令了,但今天我们将它们全部上传。

在 Sublime Merge 中执行标准三步曲:

  1. Stage (暂存):点击 Dockerfile 文件旁的 Stage 按钮。
  2. Commit (提交):在下方填写符合规范的说明,例如 feat: 添加 Dockerfile,点击 Commit 按钮。
  3. Push (推送):点击工具栏的 Push,将改动上传到 Gitea 服务器。

为什么代码推送了,系统却没有动静?
在 Gitea 中能看到新代码,但 Drone 并没有自动开始构建任务。 原因很简单:我们只是准备了配方,但没有给 Drone 下达“生产指令”。 想要让 Drone 工作,我们需要一份专属的自动化流水线“任务清单”。

这一步是自动化的核心!我们要通过配置文件告诉 Drone:在代码提交后什么时候做?做什么事?以什么环境做?

在项目根目录(与 Dockerfile 同级)创建一个名为 .drone.yml 的文件(注意文件名以 . 开头)。将以下内容复制进去:

yaml

kind: pipeline # 定义这是一个流水线任务
type: docker   # 指定流水线在一个干净的 Docker 容器环境中执行
name: build    # 给这条流水线起个名字,比如 'build'

steps: # 定义流水线的具体工序(步骤)
  # 步骤 1: 构建 Docker 镜像
  - name: 构建镜像
    image: plugins/docker # 指定处理该任务的“工人模型”(官方的docker构建插件)
    settings:
      dockerfile: Dockerfile  # 告诉插件去哪里找构建配方
      repo: stu/pacman        # 定义最终镜像的名称
      tags: latest            # 为镜像打上版本标签
      # 开启 dry_run (演习) 模式,只进行构建动作,暂不推送到最终的镜像仓库
      dry_run: true
配置文件解读:不背语法,理清逻辑

这份文件就像说明书:

  • 主体定义 (kind/type/name):搭建了一条专用的 Docker 生产测试线。
  • 具体步骤 (steps):当前只需要完成一件事——构建镜像。
  • 参数配置 (settings):传递必要的参数。这里开启了 dry_run: true,意味着这是一次排练,我们在确保构建全流程无误前,先不向“成品库”推送冗余的测试镜像。

使用 Sublime Merge,将新创建的 .drone.yml 通过 StageCommitPush 上传到 Gitea。这一次,好戏正式上演!

当你把 .drone.yml 推送后,切换到 Drone 的网页,你会发现任务立刻被触发执行。但很大概率,你会看到一个无情的红色交叉(Failed)。

构建状态

故障驱动:如何根据日志排错?

在企业实操中,配置报错是常态! 遇到红色报错不要气馁。

  1. 点击报红的步骤块展开日志窗口。
  2. 往下滚动,寻找包含 errortimeout 的关键行。
  3. 原因分析:这里报错通常是因为 Drone 在构建时需要拉取基础镜像,受限网络环境拉取超时。我们需要主动告知 Drone 去哪里找离咱们更近的“货源”。

既然找到原因是网络未走内网加速通道,我们回到代码编辑器,修改 .drone.yml 文件,在 settings 下添加 mirror 配置:

yaml

kind: pipeline
type: docker
name: build

steps: 
  - name: 构建镜像
    image: plugins/docker 
    settings:
      dockerfile: Dockerfile
      repo: stu/pacman 
      tags: latest
      mirror: https://docker.seahi.me # [新增] 指定使用内部高速镜像加速器
      dry_run: true

保存后,再次执行完整的 Stage -> Commit (“fix: 添加镜像加速站”) -> Push

此时回到 Drone 平台,最新一次的提交会自动触发一条全新的流水线。稍等片刻,看到日志滚动完毕并弹出绿色的 Success 时,意味着你的修复生效了!

构建成功

实训总结

恭喜你!虽然我们在本任务中只开启了 dry_run(并没有把最终镜像推送到远端仓库),但你已经亲手完成了 CI (持续集成) 开发的核心闭环: 修改推送代码 -> 触发自动构建 -> 查看日志排错 -> 修复再次验证。

下一次,我们只需更改标签规则并将 dry_run 去掉,就能将打上专属动态标签的优质镜像,全自动地送往成品仓库中了!